Enable EVM Mapping for $SHROOM Token
Injective proposal #693: This proposal creates an ERC20 token pair mapping for the $SHROOM token (factory/inj14ejqjyq8um4p3xfqj74yld5waqljf88f9eneuk/inj1300x...
Yes
33%
No
0%
Abstain
67%
Veto
0%
Original Proposal Text
This proposal creates an ERC20 token pair mapping for the $SHROOM token (factory/inj14ejqjyq8um4p3xfqj74yld5waqljf88f9eneuk/inj1300xcg9naqy00fujsr9r8alwk7dh65uqu87xm8), enabling seamless interoperability between the Cosmos bank module and the EVM environment. $SHROOM is the bank-denom representation of the shroomin CW20 (inj1300xcg9naqy00fujsr9r8alwk7dh65uqu87xm8), wrapped 1:1 by the standard Injective CW20 Adapter (inj14ejqjyq8um4p3xfqj74yld5waqljf88f9eneuk). It has 18 decimals and a fixed supply of 1,000,000,000 SHROOM. No minter is set on the CW20, so no additional tokens can ever be issued. Because the tokenfactory admin for this denom is the CW20 Adapter contract itself, and that contract is immutable and cannot submit MsgCreateTokenPair, the x/erc20 module's governance-authority path is the only on-chain mechanism that can register this pair. If passed, this would be the first CW20-adapter-wrapped bank denom on Injective to receive an ERC20 pair. There are currently 825 token pairs registered in x/erc20, and not one of them is an adapter-wrapped CW20. That is not for lack of demand: the path was blocked chain-side. The x/wasmbinding SetTokenMetadata translation did not populate the top-level Metadata.Decimals field that the bank precompile reads when serving decimals() to an auto-deployed wrapper, so any pair created for an adapter-wrapped denom would have produced an ERC20 reporting decimals() == 0, breaking pricing and balance display everywhere on the EVM side. We reported that bug upstream and contributed the one-line fix, which is live on mainnet as of the v1.20 release. The adapter metadata for $SHROOM has since been refreshed, and the denom now correctly reports 18 decimals on-chain. The scale of what this unblocks is worth stating plainly. 197 CW20 contracts are registered on the standard adapter, and until this week every single one of them still reported decimals == 0. The chain fix repairs the code path but does not rewrite metadata already in state, so each affected denom needs its adapter UpdateMetadata re-run exactly once. That call is permissionless, so rather than repair only our own token we have re-run it across the entire adapter. 195 of the 197 registered CW20s now report correct decimals on-chain. The two remaining cannot be fixed by anyone: one CW20 has an empty symbol and another uses "$WIF", and the bank module rejects both as invalid display denoms. This cost a fraction of an INJ in gas, we hold no position in the overwhelming majority of those tokens, and we are not asking for anything in return for it. The adapter cohort is simply ready now, and we would rather it were ready for everyone than only for us. $NONJA (factory/inj14ejqjyq8um4p3xfqj74yld5waqljf88f9eneuk/inj1fu5u29slsg2xtsj7v5la22vl4mr4ywl7wlqeck) illustrates what is now waiting behind this proposal: 18 decimals, a fixed supply of 1,000,000,000, over 144 million already wrapped into its bank denom, and metadata that is finally correct. A pair is all it lacks. Approving this pair therefore does more than serve a single token. It walks the repaired path end to end for the first time and sets the precedent for the rest of Injective's CW20 ecosystem to follow, turning a category of tokens that is currently unreachable from Injective's EVM into one that can be onboarded through ordinary governance. This mapping will allow $SHROOM holders to utilize the token across both native Injective and EVM-compatible applications.