Would be useful to have implementation of:

• Receive message
• RegisterReceive message
• (Maybe other SNIP-20 messages?)

This is a great reference for this
This would lower the learning curve around writing contracts that use SNIP-20 tokens and save some code lines 😄

When add_attribute_plaintext is called on a Response, it adds an Attribute with encrypted: false:
https://github.com/scrtlabs/cosmwasm/blob/6c639b5a85ef66f87d72284dc68ae051eab09007/packages/std/src/results/response.rs#L112-L122

but when pad_handle_result is called on the Response, it pads all attributes (both plaintext and encrypted), causing problems for plaintext ones since a bunch of spaces are appended to the plaintext attribute key, preventing clients from accessing the key in the response JSON (without resorting to matching by pattern - which is obviously not desired nor intended).

Extend the methods available under secret_toolkit::snip20 to also include the new interface specified in:
SNIP-21, SNIP-22, and SNIP-23.

Alternatively, implement new modules called snip21, snip22, and snip23 which include versions of the modified interfaces that are aware of the new features, as well as support for the new message types.

NOTE: at the time of writing SNIP-23 is not finalized yet so it's a lower priority.

UPDATE 2022-01-19:

We ended up including all new SNIP-2x functionality in the snip20 module. As far as I'm concerned we can still reshuffle this as discussed in this thread and release a new version, but for now let's experiment with it and see what feedback we get.

Example:
A very common way to answer a handle message is simply { "status": "success" } or { "status": "failure" }.
Every time we do that we have to write something along the lines of:

Ok(HandleResponse {
        messages,
        log: vec![],
        data: Some(to_binary(&HandleAnswer::Send { status: Success })?),
    })

For this we of course have to declare:

#[derive(Serialize, Deserialize, Clone, PartialEq, JsonSchema, Debug)]
#[serde(rename_all = "snake_case")]
pub enum ResponseStatus {
    Success,
    Failure,
}

#[derive(Serialize, Deserialize, JsonSchema, Debug)]
#[serde(rename_all = "snake_case")]
pub enum HandleAnswer {
    Send {
        status: ResponseStatus,
    },
    ...
}

This is a lot of code and it's kind of annoying.
We should provide a standard implementation for common use cases that coders can use as a one-liner.

We can move permit validation to a service outside the contracts - should improve performance and gas usage, which will help standardize and prevent mistakes

secp256k1 depends on secp256k1-sys a c wrapper. It has caused me build issues like having to update clang on my mac as well as being incompatible with rust-optimizer. Is there any reason to not use a pure rust implementation like k256? Plus it would be one less dependency since k256 is already a dependency of secret-cosmwasm-crypto

See secretSCRT for reference

Secret-toolkit's(Branch = cosmwasm-v1.0) revoke-permit functions panics because apparently, you cannot store an empty value in the storage.
Here's the revoke_permit function that is trying to store an empty value.
Cw-0.10 doesn't have this condition before. Seems like it was added after version 0.10. This check here is causing this error.

I suggest we store permit name or any random value to avoid this error.

it would be great if the snip-20 package supported queries with permits as defined in snip-24

The current implementation of the snip20 and snip721 modules fails to parse the query response if it was an error.
This isn't great. The library should know how to handle those cases. This came up while playing around with queries that require a VK, and providing the wrong VK.

I ran into this issue because I was trying to unit test my own functions which rely on secp256k1. It looks like the sign and verify functions need deps.api to be given as input. But even after I gave it as input it still fails during runtime because the mock version of dependencies spits out an empty array when you sign something which secp256k1 doesn't like at all. Is there any workaround for this? Or a simple fix?

Provide a safe integer type for messing with tokens (prevent overflows, negatives, etc..)

Implementation of common actions an admin can do in a contract:

• Stop
• Resume
• Change admin
• ..

Ideally this would also implement the underlying action of these messages - e.g. encapsulate saving to storage, etc..