Update contract and package dependencies:

• cw721: 0.8.0 -> 0.9.1
• cw-storage-plus: 0.8.0 -> 0.9.1

Description

The majority of our ADOs do not currently make use of "actions" for permissioning and economic incentives.

Implementation

Generate a call_action style method that should both check permissioning and call the economics contract as required:

fn call_action(ctx: ExecuteContext, action: &str) -> Result<Response, ContractError> {
    ensure!(
        is_context_permissioned(ctx.deps.storage, &ctx.info, &ctx.env, &ctx.amp_ctx, action)?,
        ContractError::Unauthorized {}
    );

    let payee = if let Some(amp_ctx) = ctx.amp_ctx.clone() {
        ctx.deps
            .api
            .addr_validate(amp_ctx.ctx.get_origin().as_str())?
    } else {
        ctx.info.sender.clone()
    };

    let fee_msg =
        ADOContract::default().pay_fee(ctx.deps.storage, &ctx.deps.querier, action, payee)?;

    Ok(Response::default().add_submessage(fee_msg))
}

Add this call to each contract that does not currently this it.

Acceptance Criteria

Actions implemented in all 1.0 contracts:

• Splitter
• Crowdfund
• CW721
• Auction
• Marketplace
• Timelock
• Lockdrop
• Merkle Airdrop
• CW20
• CW20 Staking
• CW20 Exchange
• Rate Limiting Withdrawals

Describe the bug
If trying to issue a CancelSale() call to a CW20-Exchange which still has a balance remaining (unsold tokens). There appears to be a 0 balance check failing in the call that prevents the ability to cancel the sale.

If the exchange has been completed (all tokens sold), then CancelSale will execute as anticipated.

This is an indication that the 0 balance check is being preventative to actions anticipated.

This reported issue has only been reviewed (and reported) from a native based sale, and a cw20 based sale setup has not been tested for these faults.

Error Code
code: 5: execute wasm contract failed

To Reproduce
Steps to reproduce the behavior:

1. Establish an active cw20-exchange native sale with a balance of non-0 cw20s available for purchase.
2. Attempt to cancel the sale (watch for authorization conflicts)

Expected behavior
Sales should be able to be canceled/ended even if there are purchasable cw20 tokens available for purchase.

Environment (please complete the following information):

• Tested on Galileo-3
• Against [email protected]
• With [email protected]

Additional context
Bug finding credits include Anshu & Dany W.

Adding any component to the App contract seems to return an error: Query failed with (6): rpc error: code = Unknown desc = failed to execute message; message index: 0: dispatch: submessages: reply: dispatch: submessages: reply: Generic error: codespace: wasm, code: 5: execute wasm contract failed [andromedaprotocol/andromedad/x/wasm/keeper/keeper.go:517] With gas wanted: '0' and gas used: '638197' : unknown request

Issue

It appears that the amount allowed to be declared in the release_amount field of the Vesting ADO (https://docs.andromedaprotocol.io/andromeda/andromeda-digital-objects/vesting#createbatch) can be declared as a value higher than the funds provided in the batch. It is unclear if this is intentional.

Review note from Dany W.:

In the case provided, the total amount is released in one go. My theory on it working this way, is that for the last batch, the amount that is left is always less than the release amount so the amount to release can be greater than the available funds. Did not test this on chain, can do so if needed.

Comment from Connor:

It seems that Dany's review is likely correct, but we may want to review the code to confirm and see if we may need to add a check.

Version

[email protected]

Credits

Discovery credits to @cowboy0015 who noted issue during unit testing.

Andr query is failing for cw20 exchange ado. Related screenshots, erros and addresses have been attached to the issue.

ADO Addresses

cw20 exchange - andr12yvzsqpm474hhum9a9lh0tcsfdfty3kshxtvq2dj8l47uv0gascqgun5x4
cw20 - andr1p660t3n6gxkez5uqluhj7swuduug9yt8y55jqvn3f5gprd3rsnnqt4nxyf
app - andr1fz4gwrjc5p6lwmfp0ql6w8tl0xczn5xdln523ujtcvpua4gtcz3qh3hlt7

Sale Query for cw20 exchange - WORKING

Screenshot:

Findings:
Sale query doesn't throw any error.
Note - This doesn't cover testing related to sale, this is done to confirm if error is present for only andr_query query messages or all query messages

ANDR Query for cw20 exchange - ERROR

Screenshot:

Error Message:

Query failed with (18): Error parsing into type andromeda_fungible_tokens::cw20_exchange::QueryMsg: unknown variant `owner`, expected one of `Get`, `Owner`, `Operators`, `Type`, `OriginalPublisher`, `BlockHeightUponCreation`, `IsOperator`, `Module`, `ModuleIds`, `Version`: query wasm contract failed: invalid request
Use the --help flag for help

Findings:
Unknown variant error is thrown for andr query msgs.

Extra Notes

• Tested andr_query on other ados in the same app and they are working as expected so this is probably a cw20-exchange ado specific error
• Andr query failure is probably also affecting gql queries for cw20 exchange. Further testing in gql will be done once wasm query is resolved.

One of the testers pointed out that you can run a batch mint without adding any NFTs to mint. I think it makes sense to restrict executing the message if 0 tokens are added.

Could we maybe zoom out a bit (making boxes smaller) for the initial view? Right now the boxes are a bit large.

Issue

Within the Auction ADO

Provided that subsequent bids are of greater value, regardless of the increase in value amount, the latest bid is accepted as the highest bid. This could result in micro-denominational raising, say .0004uANDR, which could easily create a nuisance of bid maintenance for the user, as well as other avoidable administrator and participant problems that could negatively impact user experiences.

Possible Resolution

It seems that adding a field to specify a threshold that must be met between bid raises would resolve this issue. I would suggest adding this as a min_raise field to the start_auction struct. New bids that did not increase by the declared min_raise, from the amount of the last accepted bid, would be rejected.

Additional Notes

min_raise could be set as an optional field allowing for micro-raising by default, as chains with extremely high native token values would be operationally hampered by not using micro-fractional bid increases. This would also keep from any conflicts arising from using start_auction structs which were already established with previous versions of the auction ADO.

Response Consistency

Issue
Query response / reply structures are not consistent across the OS and ADO queries. Some are returned directly as values while others are returned as a key/value pair. This is easily observable when reviewing boolean based results. Trying to handle results with different response structures can create development difficulties for support and use.

This can be observed in the mismatched results between queries such as:

• adoBase/isOperator()
• CW721/isArchived()
• Crowdfund/IsTokenAvailable()

This direct value return (undeclared key) can also be seen in other query responses such as crowdfund/avilable_tokens(limit, start_after) query and is not limited to booleans (they are simply the example type that I am using).

Recommendation
It would be advisable to keep response structures consistent. As query response integration support continues, then inconsistency may show to be more problematic for using responses with structural variances.

Declarative key/value pairing is likely to be the best option as currently defined single-value responses may potentially have additionally returned fields in future versions. Using a key/value structure should allow for easier code reuse without adjustment, even if queries are adjusted in future with optional parameters or additional results.

Based on discussions regarding sales structs in Issue #268

Request

It would be a nice addition to add a few start and end declarations to the startSale struct similar to what is found in auction. These could be optional fields (start-time = "now" if undeclared) which would maintain validity of previous structs config values currently in use.

Version being requested

[email protected]

Fields Recommended

• start-time (in milliseconds/blockheight)
• duration or end-time (in milliseconds/blockheight)

Primitives current do not have a way to declare and transfer ownership.

Primitives should:

• Accept an UpdateOwner message to pass ownership
• Validate any UpdateOwner message is authorized

To allow for cross-chain instantiation we can write an instantiation message within the kernel to create an ADO

Issue

Right now, queries to primitive are inside Get query which requires some extra effort for creating query data.

Feature request:

Restructure primitive queries to directly access them instead of going through Get query. It will look similar to queries for other contracts, for example, num_tokens for cw721.

when I use "ado create app" then specify cw721 as the ADO type, I get the error:
Request failed with status code 404
Use the --help flag for help
This seems to be only occurring when adding a cw721.

Rename ADO type in App Contract to app-contract for consistency

Request

There does not currently appear to be a retained value for the starting value of a sale (native or cw20) or a query that would return such values. It would likely be valuable to a user to be able to determine how many assets were originally available (as this is easily different than max-supply of the cw20) as well as some other sale related information such as when the sale began.

Version

• Applies to [email protected]

Field Values Suggested

• sale-start-amount
• sale-start-time

Currently, addresses need to be added one by one to the address list. It would be more convenient if we would make it to add a vector of addresses. I also suggest that we would initialize this vector at instantiation.

The state query should return a field to specify if the auction has ended or not. This is not found currently.

Specifying the recipient of a rates module as an ADO was returning a subtraction error.

Description

As part of the module redesign we must remove all references to modules in our current contracts.

Implementation

Any references to modules, including calling module hooks must be removed.

Acceptance Criteria

• No remaining usage of module code within any contract.

1-In the audit fix, we made the auction contract require an authorized CW721 to be able to send and NFT to the auction to be sold. This was a needed change, but the ideal solution would be having this as an option and not required. This would allow for two types of auctions:

• A private auction: Here we would use authorization and the owner would be the one selling the NFT collection
  -An open auction: This option would be for a user that wants to make an auction house where anyone can sell their NFT (auction marketplace) and maybe the owner would charge a royalty or tax on the NFTs.

2- There is no query to get the authorized addresses for an auction.

Currently a user can have multiple usernames, this mapping must be 1 to 1

Default Behavior

The owner field is an optional declaration for the mint() function. Omission will assign the crowdfund as the owner.

Issue

If the field is declared with an undefined value ("") it will be rejected by the contract. Although empty value strings are not the equivalent of an omitted field, it might be good to apply empty field acceptance for the default action, or a rejection based on undeclared values.

Targeted ADOs

VFS

Use Case

User wants to know his username

Problem

There is no query where user can get his username

Possible Solution

Query to get username based on contract address

{
 "get_username":"andr123......232"
}

In the Timelock, the held funds can be released by any address(Both ReleaseFunds and ReleaseSpecificFunds). We should probably make it that only the owner of the locked funds can do so.

Currently permissions can not be queried.

In the App Builder, the rates module shows a checkbox with the text "Tax or Royalty", but it is unclear what checking it does. I'm thinking we should have a widget that looks like this:

Tax O== Royalty
Tax ==O Royalty

So you know which you're selecting.

When an NFT is sent to another contract, we need to remove any transferagreements attached to the NFT.

Current the IBC message bridge sends an AMP packet, instead it should send an AMP message to the kernel.

In the Hotfix branch, some of the cases for handling cw20 and cw721 messages are missing. For cw721 queries, the case to handle the rest of the cw721 queries such as NumTokens, AllTokens ect..
For cw20 execute, the case to handle the base executes is missing. For cw20 query messages the case to handle the queries (other than the base ones) is missing.

The ExecuteMsg::UpdateAddress method needs reimplemented for Columbus-5 reply architecture.

• Register token owner in ExecuteMsg::Create message
• Allow token owner or contract owner to update a symbol's address

Some execute handlers do not have relevant attributes attached to the response.

• Add attributes to all Token responses
• Add attributes to all Splitter responses
• Add attributes to all Timelock responses
• Add attributes to all Receipt responses
• Add attributes to all Factory responses
• Add attributes to all Address list responses

Currently the Kernel is sending a direct execute message. This needs updated to send the packet instead.

Currently the cw20-staking contract does not validate the staking token address upon instantiation.

Description

Following #274 as no contracts reference module code we can remove the module feature from the std crate.

Implementation

Remove all references to modules and remove the module feature from all contract imports and the Cargo.toml for the std crate.

Dependencies

• #274

Acceptance Criteria

• Complete removal of all module related references, features and code.

A couple of requests for the crowdfund ADO (these are just improvements and nothing critical):
-The default for the amount of NFTs allowed per user is 1. We think it should be open unless specified by the creator.
-Burning tokens at the endsale when the goal is not reached should be discussed if needed or not.
-Endsale needs to be called twice, once for transferring NFTs and once for transferring the funds, not sure if we can make it work in one message.
-The current limit for the mint is 100. The CW721 does not seem to have a limit in batch mint. Do we need to start testing some benchmarks or raise the limit.
-In endsale there is a default which is 50 and a max of 100. Should the default be the max unless specified otherwise as we dont see anyone wanting to do it in more than one go
-The crowdfund uses expiration in nanoseconds, for consistency we may want to change all nanoseconds to work in milliseconds

• Add the ability to have no expiration on timelocked funds (can be released immediately)

Request

It would be a nice addition to add a few start and end declarations to the startSale struct similar to what is found in auction and marketplace. These could be optional fields (start-time = "now" if undeclared) which would maintain validity of previous structs config values currently in use.

Version being requested

[email protected]

Fields Recommended

• start-time (in milliseconds/blockheight)
• duration or end-time (in milliseconds/blockheight)

Currently there is no way to publicly list a token for sale without having communication between the buyer and seller.

• Add a * listing option to a transfer agreement to allow anyone to purchase the token for the set price

Currently there is no query to list all the keys for a primitive. There have been few usecases where the requirement to list all the keys currently present in the primitive is required, an example will be to list all the embeddables config we have stored in primitive, list all the denoms we have stored in primitive.

Some tests, particularly those related to whitelist and blacklist events, do not currently function as they rely on the cosmwasm_std::Querier struct. These tests need updated with a custom MockQuerier.

• Create a common MockQuerier
• Fix the related tests using the new MockQuerier

Reference

• Add the ability to update the address list for the timelock contract

The latest version of the splitter (AMP) sends funds to the last recipient in the list only and none of the others. Have tested this multiple times with the same result (From CLI and web-app).

The auction ADO currently accepts NFTs from any address. We think it would make sense in some cases that a project wants to do a private auction where only their NFTs are accepted by the ADO. We could add a toggle in instantiation to specify if the contract accepts any NFT or only NFTs sent by the owner.

• Add a new ExecuteMsg to allow updating of Code IDs by the factory contract owner

When you create a CW20 exchange in an App and reference the token address by the component name, it breaks the exchange ADO. Trying to query the token address using the TokenAddress query returns the following error:
Query failed with (18): Generic error: Querier contract error: codespace: wasm, code: 9: query wasm contract failed: invalid request
Due to this, you cannot start a sale or work with the ADO.
If the token address is referenced by contract address and not component name ( instantiated separately) then it works fine (you can query it and start sales ect ...)

The splitter contract does not instantiate an address list contract when the ExecuteMsg::UpdateAddressList message is received with the appropriate settings.

The same message does not allow the removal of the address list (swap the field to optional).

• Add appropriate InstantiateMsg to the ExecuteMsg::UpdateAddressList method
• Make the address_list field of the ExecuteMsg::UpdateAddressList message optional and remove the address list if it is None

Description

As part of the redesign we decided to move the rates module to be a core part of the std crate that can be optionally implemented using Rust's feature mechanism. An ADO may implement rates by adding the "rates" feature as part of their Cargo.toml addition of the andromeda-std crate.

Implementation

Create a new rates module in the std crate under the ADO Contract directory (/ado_contract/rates.rs) and expose its contents under a "rates" feature.

Acceptance Criteria

• New "rates" feature exposed by std crate