feat(x/erc20): add allowance state

[cloudgray]

Description

• Add Allowance state in x/erc20 module

Closes: #70

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• tackled an existing issue or discussed with a team member
• left instructions on how to review the changes
• targeted the main branch

Reviewers Checklist

All items are required.
Please add a note if the item is not applicable
and please add your handle next to the items reviewed
if you only reviewed selected items.

I have...

• added a relevant changelog entry to the Unreleased section in CHANGELOG.md
• confirmed all author checklist items have been addressed
• confirmed that this PR does not change production code
• reviewed content
• tested instructions (if applicable)
• confirmed all CI checks have passed

[zsystm]

@cloudgray
Thanks for the draft — I’ve left a few comments that might be helpful as you continue working on this.

[zsystm]

@cloudgray
Could you add error handling here? If SetAllowance returns an error, we should panic to prevent inconsistent state.

[cloudgray]

applied in 80036a6

[zsystm]

@cloudgray
It looks like disabled token pairs never get their allowances stored during InitGenesis, because SetAllowance calls checkTokenPair and returns an error if the token is disabled. However, InitGenesis is supposed to restore all state from the genesis file — including allowances for disabled pairs.

Right now, we simply continue when types.ErrERC20TokenPairDisabled is encountered, so those allowances don’t actually get written to the KVStore. If the module logic requires that disabled pairs still have their allowances recorded at genesis (so they might be re-enabled later or at least remain consistent with the imported state), we’ll need to revise this flow. One potential fix is to skip the checkTokenPair check during genesis, or handle the “disabled” error as a non-fatal condition that still writes the allowance. Otherwise, we lose a piece of state that was originally present in the genesis file.

[cloudgray]

applied in fcae5bb and 80036a6

[cloudgray]

@zsystm I added deleteAllowances method and let it called by DeleteTokenPair method.

It is not likely to happen that TokenPair for erc20 precompile is deleted and it really does not happen in cosmos/evm.
However, because DeleteTokenPair method is public method, appchain that imports cosmos/evm can call it in somewhere.
Then, when that appchain import genesis, the situation where TokenPair does not exists but allowances exist can happen.

So, I thought that all allowances that share same erc20 address are deleted when TokenPair is deleted.

I applied this change in 80036a6.
Could you check this change?

[zsystm]

@zsystm I added deleteAllowances method and let it called by DeleteTokenPair method.

It is not likely to happen that TokenPair for erc20 precompile is deleted and it really does not happen in cosmos/evm. However, because DeleteTokenPair method is public method, appchain that imports cosmos/evm can call it in somewhere. Then, when that appchain import genesis, the situation where TokenPair does not exists but allowances exist can happen.

So, I thought that all allowances that share same erc20 address are deleted when TokenPair is deleted.

I applied this change in 80036a6. Could you check this change?

@cloudgray
I agree that allowances should be removed when a token pair is deleted — especially since the deletion happens when the paired ERC20 contract is self-destructed. In that case, keeping the allowance data serves no real purpose, so cleaning it up makes sense.

[zsystm]

@cloudgray
I have one last comment from my side — please take a look when you get a chance: #90 (comment)

[zsystm]

Final review from my side. Let's quickly resolve this and merge it.
Thanks!

[zsystm]

LGTM. Let's squash & merge it.
For lint failures, we can handle this when open PR for merging feat into main.