You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This checks is valid but we should think about going further: this is an invariant that should never occur, if it occur it mean something wrong is with the blockchain like ability to mint the ZRC20 in the module
In the future we should look into adding an invariant: https://docs.cosmos.network/v0.46/building-modules/invariants.html
erc20Balance >= minted ZRC20 Cosmos coin
With the introduction of the bank precompile now an arbitrary EOA has the ability to mint cosmos coins by depositting ZRC20 into the bank precompile. There are multiple checks that prevent infinite minting/deposits/withdraw, and in order to extend the security mechanism this is a good use case to introduce invariants.
Goal
Introduce invariants in the fungible module to prevent from attacks and issues related to minting and burning cosmos coins.
An obvious check would be ZRC20 balance >= cosmos coins minted, as if there are more cosmos coin minted than the entire ZRC20 supply there's a problem that would require to stop minting tokens and revert the problem.
The text was updated successfully, but these errors were encountered:
fbac
changed the title
This is the balanceOf for the ERC20 zrc20 balance in the contract address?
Introduce invariants in the fungible module
Sep 19, 2024
Consider initially adding a notification through an event or a simple logline before adding the invariant.
Invariant, when broken, might lead to a chain halt. We can easily more the logic into an invarient check after a few iterations
Original
Originally posted by @lumtis in #2860 (comment)
Context
With the introduction of the bank precompile now an arbitrary EOA has the ability to mint cosmos coins by depositting ZRC20 into the bank precompile. There are multiple checks that prevent infinite minting/deposits/withdraw, and in order to extend the security mechanism this is a good use case to introduce invariants.
Goal
Introduce invariants in the fungible module to prevent from attacks and issues related to minting and burning cosmos coins.
An obvious check would be
ZRC20 balance >= cosmos coins minted
, as if there are more cosmos coin minted than the entire ZRC20 supply there's a problem that would require to stop minting tokens and revert the problem.The text was updated successfully, but these errors were encountered: