CosmWasm / CosmWasm/cw-plus

Consider Handling of Updating Expired Allowances in CW20 Contract

Open
#909 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
527
Forks
362
PR merge metrics
No merged PRs in 30d

Description

Hi Team,

I've encountered an issue when working with the `IncreaseAllowance` and `DecreaseAllowance` message and updating expired allowances.

Currently, if I assign an allowance to a spender with an expiration(i.e, valid for 10 blocks), and the spender does not use up this allowance by the time it expires, the expired amount of tokens is still considered when I increase the allowance for the same spender later on. The same is true for decreasing the allowance of the spender with a valid expiration. This results in **the spender having a higher amount of valid tokens than intended**.

Illustrative example:
1. Owner A assigns an allowance of 100 tokens to Spender B, valid for 10 blocks.
2. Spender B does not use the allowance, and it expires.
3. Owner A then need to assign an additional allowance of 100 tokens to Spender B
4. Therefore, Owner A uses IncreaseAllowance message and assigns the second allowance of 100 tokens.
5. However, Spender B now has access to 200 tokens, not 100. The expired allowance has been effectively revived.

I understand that owner can query the actual allowance before increasing or decreasing it to decide the proper amount. However, from my opinion, it would be more logical and intuitive for the expired allowance to be discarded.

One possible solution might be having default allowance if the allowance is expired.

I would love to hear your thoughts on this. Would you consider this as a viable improvement for the CW20 contract?

Contributor guide

Open the contributing guide

Research direction

Start by reviewing the CW20 contract's IncreaseAllowance and DecreaseAllowance handling and how expired allowances are represented. Compare the current behavior with the stated 10-block example, then determine the expected treatment of expired amounts before either update. The issue names no files or tests, so completion depends on agreeing on behavior and defining the affected scope.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
blockchain
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.