Consider Handling of Updating Expired Allowances in CW20 Contract
- 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
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