Handle ERC20 and Bank Token State

[vladjdk]

Overview

We need to determine the optimal strategy for representing and storing state for two types of tokens onchain:

1. ERC20 tokens created on the EVM layer
2. Bank tokens originating at the module level (IBC tokens, gas tokens, denoms)

Problem Statement

We currently lack a clear architecture for how tokens should be represented across the system. This creates several challenges:

• Potential inconsistencies in token representation
• Unclear paths for IBC transfers
• Potential confusion for developers building on our platform
• Potential inefficiencies in token management

Token Representation Matrix

Below is a table describing each method of representing tokens and how they are structured in the current version of Cosmos EVM.

Token Type	Current State	Current Representation	EVM Access Pattern	Module Access Pattern	External Access Pattern
ERC20 (EVM-native)	Exists within EVM state	EVM state only.	EVM contracts access the state regularly.	ABI calls into EVM via evmKeeper.CallEVM	EVM queries via JSON-RPC.
Bank (Cosmos-native)	Exists within module state	Module state only.	EVM contracts access the state regularly.	Bank module keeper storage	EVM queries via JSON-RPC and Cosmos gRPC.

ERC20 (EVM-native) Tokens

These tokens originate within the EVM environment:

• Current State: ERC20 tokens exist within the EVM state storage. Their balances, allowances, and other properties are managed by the EVM.
• Current Representation: These tokens are represented in the EVM state only, with no representation at the Cosmos module level.
• EVM Access Pattern: EVM contracts access these tokens through normal ERC20 interface calls.
• Module Access Pattern: Cosmos modules access ERC20 tokens through ABI calls into the EVM via the evmKeeper.Call method.
• External Access Pattern: External systems (like wallets or explorers) interact with these tokens through JSON-RPC queries to the EVM, using standard Ethereum interfaces.

Bank (Cosmos-native) Tokens

These tokens originate within the Cosmos SDK’s bank module:

• Current State: Bank tokens exist within the Cosmos module state, managed by the bank module keeper.
• Current Representation: These tokens are represented at the module state level only.
• EVM Access Pattern: EVM contracts access bank tokens through an ERC20 precompile that serves as a translation layer. The precompile maps ERC20 interface calls to bank module operations without duplicating state.
• Module Access Pattern: Cosmos modules access bank tokens directly through the bank module keeper storage.
• External Access Pattern: External systems can access bank tokens through both JSON-RPC queries to the EVM and by querying bank module state through the Cosmos gRPC. The ERC20 precompile enables dual access by exposing bank tokens as ERC20-compatible tokens while maintaining the state in the bank module.

Key Observations

1. Single Source of Truth: Each token type has a single source of truth for its state—ERC20 tokens in the EVM state and bank tokens in the module state.
2. Translation Layer: The ERC20 precompile serves as a translation layer for bank tokens, exposing them to the EVM context without duplicating state.
3. Token Pairs: The system uses token pairs that map Cosmos denoms to ERC20 contract addresses, enabling the precompile to represent bank tokens as ERC20 tokens.
4. Different Access Patterns: EVM-native tokens require module-level ABI calls for Cosmos module to access them, while Cosmos-native tokens are made available to EVM contracts through the precompile interface.

Current Architecture Limitations

1. Limited Permissionless Creation of ERC20 Precompiles
   • There is no way to permissionlessly create instances of the ERC20 precompile for tokens to be mirrored from EVM into bank module state
   • Only IBC tokens are automatically converted into ERC20 precompiles via the IBC middleware OnRecvPacket function
   • Architectural asymmetry, where incoming tokens are represented, but EVM-native tokens lack equivalent representation in module state
   • The only way to represent ERC20s as a bank token is via the conversion method, but even that requires registration via a governance proposal
2. Lack of Extensibility for ERC20 Precompiles
   • Current ERC20 precompile implementation cannot be extended to support advanced ERC20 functionalities
   • Missing support for important ERC20 extensions that applications
     • Examples:
       • ERC20Permit (ERC2612): Gasless approval of tokens
       • ERC20Burnable: Token destruction capabilities
       • ERC20Capped: Supply cap enforcement
       • ERC20Pausable: Circuit breaker functionality
       • ERC20Snapshot: Historical balance tracking
       • ERC20FlashMint (ERC3156): Flash loan support
       • ERC20Votes: Governance capabilities
       • ERC20Wrapper: Token wrapping functionality
       • ERC4626: Tokenized vault standard
3. Limited Interoperability for EVM-Native Tokens
   • ERC20 tokens originating on the EVM have no pathway to be used in Cosmos modules apart from conversion between the two states
   • Particularly problematic for IBC transfers, as EVM-native tokens cannot be directly sent via IBC
   • Two potential approaches:
     • Represent these as bank tokens
     • Rewrite ICS20 and extend escrow functionality to tap straight into the EVM
4. Incomplete State Mirroring
   • Current system implements one-way mirroring (bank tokens → EVM) through precompiles
   • No equivalent system for mirroring EVM tokens to module state, only conversions between the two

[vladjdk]

My personal take:

For ERC20 tokens

I strongly believe the most important usecase for ERC20s needing module state is transferring them via IBC-Go to other chains. We should implement an improved version of the ICS20 precompile that would efficiently escrow tokens on the EVM side and use IBC-Go to handle the connection to other chains. This would solve one of our biggest interoperability issues while maintaining proper state separation. This approach requires minimal changes to our existing IBC codebase since we're simply creating a precompile that interfaces with our already robust IBC infrastructure.

I imagine the flow for outgoing EVM-originating ERC20 tokens is something along the lines of this:

1. User escrows their assets in the ICS20 precompile
2. Precompile calls the IBC-Go module
3. IBC-Go handles sending the packet to another chain

For the incoming flow, it would be the opposite:

1. IBC packet arrives at our chain with tokens destined for an Ethereum address
2. IBC module processes the packet and mints/unlocks the tokens in bank state
3. The tokens are automatically converted to ERC20 tokens through the precompile
4. User receives ERC20 tokens at their Ethereum address

Although these flows are technically already possible with the existing ICS20 precompile, it requires a user to manually escrow and migrate the coins to bank state before initiating the transfer. This process should change to be automatic such that ERC20s can just be transferred by calling a single transaction in the precompile. Again, the only thing that needs changing here is the fact that token conversion should become automatic.

For Bank tokens

The process for bank tokens should be automatic. We should automatically assign every bank token as an ERC20 precompile upon migration when we add the EVM module into an existing chain. This would include every existing denom, as well as any new IBC token coming in. This is already automatic for IBC tokens coming in, so we'd only need to extend it to every other denom when we upgrade an existing chain to represent every existing token as an ERC20. This creates a consistent experience for users and developers regardless of token origin. This approach requires minimal code changes since we're extending existing functionality that's already working well for IBC tokens.

The flow for IBC receipts would be exactly how it's implemented now:

1. Other Chain Sends packet to our chain
2. Our IBC-Go module handles packet
3. Packet gets routed to the handler: If the precompile exists for the token, unescrow or mint the balance to the recipient. If the precompile does not exist for the token yet, create a new one and assign the balance to the user.

Conversely, outgoing IBC packets would look the same as it is right now:

1. User calls the IBC transfer functionality through the precompile or natively
2. If the call came through the precompile, it's converted to a native bank operation
3. IBC module creates and sends the packet to the destination chain

For new bank tokens that don't come from IBC, we should look into making an ERC20 factory, which the Ripple team is already making strides on in this PR: xrplevm/node#59. Regarding extending the ERC20 precompile to seamlessly be extended to support extra functionality. I haven't spent too much time thinking about how to do this, so I'm very open to hearing any ideas.

This approach gives us maximum interoperability while ensuring that minimal changes are made to the existing codebase and external modules like ICS20. Bank tokens remain uniquely represented in the bank module, and ERC20 tokens are enabled to use existing IBC patterns that are already proven to work.

[Hyung-bharvest]

Thank you for triggering this discussion with detailed context and also personal thoughts. I personally believe your suggestion makes sense and is practical as well.

Purpose of this comment

I want to add some colors to this discussion by providing little bit different viewpoints so that this discussion can become more diversified and bring more variety of reasonings.

First of all, I think there can be several solutions making sense. The decision making will be based on what value we prioritize, so the decision making process requires the general purpose and direction of future of IBC and Cosmos EVM.

My personal view on value prioritization

I personally think for IBC to be successful, EVM compatibility should be most prioritized. EVM compatibility means, for L1 builders, multi-chain dapps and asset issuance protocols, interoperability protocols, centralized finance entities like CEX, data service protocols, regulatory authorities, partnership and onboarding to Cosmos EVM chains and its ecosystem should be as seamless as possible, to become fully inclusive for the mainstream blockchain ecosystem.

One of the biggest obstacle they have is the Cosmos stack context and its dependencies. Independency of CometBFT from novel modular design of consensus layer and app layer separation made CometBFT the most popular consensus algorithm used in the world. However, Cosmos-SDK and IBC were less successful because of the complexity it brings to EVM-familiar ecosystem where people has no prior knowledge or enough bandwidth or willingness to fully understand, research, and review such dependencies.

So, in order for Cosmos stack to be more successful, abstraction of these layers as far as possible is the way to allow them flowing into the Cosmos ecosystem. Making them no need to care about those layers so that they can only think about EVM contracts and its environments.

Case Study: USDT0 on Cosmos EVM chain

USDT0 is strongly trending new multi-token standard for USDT. Because of current multi-chain environment, Tether is pushing this modularization of rapid multi-chain expansion of USDT via USDT0. Having them seamlessly on Cosmos ecosystem will be one of the core primitive for us to become more compatible with the mainstream blockchain ecosystem.

As a multi-chain stablecoin provider, USDT0 team will strongly prioritize immutability and security of their deployed contracts. In many EVM chains, this is quite straightforward because their EVM has almost no dependency with their underlying tech stacks. (for example, Berachain) Therefore, onboarding is easy, simple, effortless so they prioritize adoption to those chains.

Obviously it will be very challenging for them to have USDT0 naturally on non-EVM Cosmos chains, so let's consider onboarding USDT0 on a Cosmos EVM chain. At first, they will figure out that there exists whole new app layer which is controlling USDT0 on bank module, if precompile is used on their asset. Whether it is converted or single represented on bank module, it is a huge complexity and unknown risk factor for them. The Cosmos-SDK can be upgraded without under their control, sent to other Cosmos chains via IBC, having different representation as Cosmos-SDK coins or different ERC20 contracts in other chains. Note that Cosmos EVM chains "disabling IBC" do not have this problem. (Sei, Berachain, etc)

Coming back to the EVM ecosystem, they usually prefer controlling interoperability themselves via Layerzero tech stack. They handle cross-chain transfer of the asset from/to the exact same ERC20 contracts for compatibility and security. Comparing this experience with Cosmos case, everything seems too much and headache, so they naturally decide to focus on expansion to chains with having less problems like this.

Alternative Solution Brainstorming

I think the best way to maximize EVM compatibility, the developer experience should be as similar as connecting among non-Cosmos EVM chains such as Ethereum, Arbitrum, or Berachain. How we can provide such environment while still using IBC, which provides better security compared to Layerzero bridge?

My thought led to the "IBC as basic infrastructure layer for ERC20 token transfer". It means that IBC just relaying general message packets to EVM on another Cosmos EVM chain without creating Cosmos coins on bank modules in origin nor destination chain. Then, the IBC experience is abstracted away, and the onboarding developer experience will be very similar to connecting EVM chains via Layerzero. They will own the control of ERC20 contract on the destination chain as well for the sake of regulatory risk management. In conclusion, less effort to onboard assets on Cosmos EVM chains meaning better chance to create such partnerships with EVM originated protocols.

The advantage of this approach is that any ERC20 created has no state dependency with Cosmos-SDK at all. EVM states will be the single source of truth, and it solely control the cross-chain transfer activities. No need to consider the raised issue here at all. But still we use IBC, better option with less security assumptions compared to Layerzero. And, actually cross-chain token transfer is not the only usecase of this. As Layerzero enables, via IBC, we can send any arbitrary EVM messages to other Cosmos EVM chains, exactly same developer experience in EVM ecosystem with Layerzero. For example, "burn-mint" method is possible for cross-chain transfer, which is recently becoming standard in EVM ecosystem.

This approach might have limitations. It doesn't solve the compatibility problem for non-EVM Cosmos chains. But this problem is not because of this new suggested solution, but fundamentally because they don't have EVM. It brings more reasoning for the Cosmos ecosystem to adopt EVM, resulting in better EVM compatibility of whole Cosmos ecosystem.

[nooomski]

Thanks for this @vladjdk , and also for your take @Hyung-bharvest!

Fundamentally the challenge we face is because of the needs of two different user groups that we're struggling to simultaneously meet:

• AppChains: they want to have the EVM and their modules be integrated with each other. EVM devs should be able to call into chain module from the VM, so core business logic can be executed from within the EVM, this includes IBC & Staking, but also their custom modules.
• EVM devs: they need to have a predictable environment that functions as they expect it would on other non-Cosmos EVM-based networks. To them, interfacing with the protocol layer (the SDK) needs to look and feel like it was a regular contract. Contracts cannot break when the underlying protocol is upgraded.

With that in mind, I agree with Hyung that a clean separation between VM and protocol state is desirable. Specifically, all variations and extensions of ERC20 need to be supported, something for which we have no solution for. Moreover, there will be other standards and deviations on them (ERC721, and potentially new ones in the future), and we cannot end up in a situation where we constantly have to create custom solutions to support them.

That being said, I do not think the solution is moving IBC to the EVM level because this would likely lead to performance degradation. It is also an arbitrary approach, as other critical modules like x/staking will remain a module and will need to remain accessible on the VM. There is a way to get the EVM to seamlessly interact with IBC without moving it to the EVM.

As such, I would suggest us looking into the following separation of state between VM and protocol:

• Protocol tokens are tokens that are needed for gas, staking, gov. Similar to ETH. They exist in x/bank and have a wrapped version that is using the current ERC20 precompile to be reflected in the VM.
• All other non-protocol tokens, including those currently existing in bank, exist purely in the VM alone.
• x/bank is only used in two scenarios:
  • Interacting with protocol tokens
  • When the VM needs to interact with a module that requires bank, such as IBC, Staking, etc.
• The VM interacts with modules by sending assets to a generalizable escrow contract which is the only one authorized to leverage the bank module to mint and send tokens. E.g. when a user wants to IBC, the ERC20 is locked in an escrow contract on the EVM, it's equivalent is then minted in x/bank and a standard ibc-transfer call is made to transfer the asset.

The benefits to this are:

• All app developers using the VM can do so without having to interact with the protocol level. This means writing and reading occurs in a single environment, exactly how you'd expect from any other EVM (this would require you to be able to query EVM endpoints for protocol level state tho).
• We can support any type of ERC20 extension
• This system can be leveraged to support any other token standard (e.g. ERC721)

I'd love to hear objections and feedback to this thinking.

[Hyung-bharvest]

Thanks for your thoughts @nooomski !

I completely agree with your definition on the challenge. Maybe I can add some more thoughts on the reasonings on disagreement for "EVM general message passing" feature for IBC here:

• on performance degradation: from our R&D experience, Cosmos stack's performance bottlenecks are mostly from CometBFT and disk storage. we researched that by solving some problems on those two, the performance can be increased 10 times from 500 TPS to 5000 TPS. also, for cross-chain communication, relayer performance is the additional major bottleneck. so, I think EVM executions for handling general message passing is not a performance bottleneck here. could you elaborate why do you think the suggested IBC-GMP solution might cause performance degradation?

• about dependency with x/staking and VM, I think the EVM developer's UX is mostly related to "cross-chain communication". hence, I think the categorization of dependency problems can be classified as whether it is local feature or global standard among other chains. in this approach, I think x/staking is a local chain feature, hence it doesn't require global standard. meanwhile, because cross-chain feature should be replicated to hundreds of chains, standardization and EVM compability is relatively very important.

about generalizable escrow contract:

• i think it is just a minor expansion of ICS20. it even cannot handle "mint-burn" cross-chain transfer, which is recent standard for multi-chain existing asset classes. but the potential of general message passing allowed by permissionless EVM contract is limitless. IBC's way to allow cross-chain communication is very manually defined with narrow freedom, hence always strongly limiting ecosystem's imagination of cross-chain communication in design. we will end up adding more and more features to follow up EVM ecosystem's expanded general message passing usecases.

below will be a modified version of your suggested solution by adopting above two reasonings:

• protocol tokens exist in x/bank, and can be wrapped as ERC20 and can be transferred to other Cosmos EVM chains via IBC's EVM general message passing
• all other non-protocol tokens only exist in EVM, and can be transferred to other Cosmos EVM chains via IBC's EVM general message passing
• x/bank is only used in two scenarios:
  • interacting with protocol tokens for non-IBC(local feature) modules
  • when the VM needs to interact with a "local" module that requires Staking, etc. (but not bank nor IBC)

IBC GMP has all the benefit you described, and even more for every cross-chain communications EVM ecosystem will develop in the future.

[zsystm]

My personal take:

For ERC20 tokens

I strongly believe the most important usecase for ERC20s needing module state is transferring them via IBC-Go to other chains. We should implement an improved version of the ICS20 precompile that would efficiently escrow tokens on the EVM side and use IBC-Go to handle the connection to other chains. This would solve one of our biggest interoperability issues while maintaining proper state separation. This approach requires minimal changes to our existing IBC codebase since we're simply creating a precompile that interfaces with our already robust IBC infrastructure.

I imagine the flow for outgoing EVM-originating ERC20 tokens is something along the lines of this:

1. User escrows their assets in the ICS20 precompile
2. Precompile calls the IBC-Go module
3. IBC-Go handles sending the packet to another chain

For the incoming flow, it would be the opposite:

1. IBC packet arrives at our chain with tokens destined for an Ethereum address
2. IBC module processes the packet and mints/unlocks the tokens in bank state
3. The tokens are automatically converted to ERC20 tokens through the precompile
4. User receives ERC20 tokens at their Ethereum address

Although these flows are technically already possible with the existing ICS20 precompile, it requires a user to manually escrow and migrate the coins to bank state before initiating the transfer. This process should change to be automatic such that ERC20s can just be transferred by calling a single transaction in the precompile. Again, the only thing that needs changing here is the fact that token conversion should become automatic.
...

@vladjdk
Thanks for the thoughtful write-up — overall, I think the direction you're proposing makes a lot of sense given the current architecture and codebase (though of course, the broader architecture could evolve as the discussion progresses).

I just wanted to point out one small correction regarding this part:

“it requires a user to manually escrow and migrate the coins to bank state before initiating the transfer.”

In the current code, if the ERC20 token is already registered as a token pair, the conversion to a bank coin and the escrow process happen automatically when the user calls the ICS20 precompile — no manual migration step is needed.

evm/x/ibc/transfer/keeper/msg_server.go

Lines 94 to 105 in 77e425e

	msgConvertERC20 := erc20types.NewMsgConvertERC20(
	difference,
	sender,
	pair.GetERC20Contract(),
	common.BytesToAddress(sender.Bytes()),
	)
	// Use MsgConvertERC20 to convert the ERC20 to a Cosmos IBC Coin
	if _, err := k.erc20Keeper.ConvertERC20(ctx, msgConvertERC20); err != nil {
	return nil, err
	}

So I don’t think the current implementation requires users to manually convert anything — in fact, even attempting to do so manually wouldn't work unless the token is already registered.

evm/x/erc20/keeper/msg_server.go

Lines 36 to 55 in 08eb3b7

	pair, err := k.MintingEnabled(ctx, sender.Bytes(), receiver, msg.ContractAddress)
	if err != nil {
	return nil, err
	}
	// Check ownership and execute conversion
	if pair.IsNativeERC20() {
	// Remove token pair if contract is suicided
	acc := k.evmKeeper.GetAccountWithoutBalance(ctx, pair.GetERC20Contract())
	if acc == nil || !acc.IsContract() {
	k.DeleteTokenPair(ctx, pair)
	k.Logger(ctx).Debug(
	"deleting selfdestructed token pair from state",
	"contract", pair.Erc20Address,
	)
	// NOTE: return nil error to persist the changes from the deletion
	return nil, nil
	}
	return k.convertERC20IntoCoinsForNativeToken(ctx, pair, msg, receiver, sender) // case 2.1

In my view, the real usability bottleneck is the governance dependency for registering ERC20 token pairs. If we want to allow users to seamlessly transfer any EVM-native token via IBC, this registration process likely needs to be opened up or automated.

Curious to hear your thoughts — and happy to be corrected if I’ve misunderstood anything.

[zsystm]

Thanks for sharing these detailed perspectives, @vladjdk and @nooomski! I noticed both of you assume we’ll always rely on ICS20 (the transfer keeper and bank-backed conversion) to move ERC20 tokens cross-chain. That definitely works for minimal code changes, but I wonder if it’s necessary at all for EVM-native tokens.

Instead, what if we skip ICS20 entirely and support a general IBC precompile for EVM-based assets? Contract developers who want to implement cross-chain token transfers could leverage this general IBC precompile to send packets directly, without relying on the bank module or token pair registration via governance. I haven’t explored this deeply yet, but conceptually it feels closer to how ecosystems like LayerZero handle bridging—while still preserving the trust assumptions of IBC.

I know this may not be practical in the short term given timeline constraints, but I'm curious: aside from implementation time, do you see any fundamental blockers to introducing a non-ICS20 path for EVM-native assets?

It might be a good time to step back and ask whether ICS20 needs to be the default assumption for every asset class. There may be technically sound alternatives that provide a better experience for EVM devs while still keeping the IBC security model. Would love to hear your thoughts.

[vladjdk]

In the current code, if the ERC20 token is already registered as a token pair, the conversion to a bank coin and the escrow process happen automatically when the user calls the ICS20 precompile — no manual migration step is needed.

@zsystm good shout! I completely missed this.

Do you think it would be useful to disable manual conversions? Is it ever even useful to manually convert tokens using the message? Seems like a recipe for confusion to even have that enabled.

In my view, the real usability bottleneck is the governance dependency for registering ERC20 token pairs. If we want to allow users to seamlessly transfer any EVM-native token via IBC, this registration process likely needs to be opened up or automated.

Is there a downside to removing the governance restriction? Why was it there in the first place? If someone wants to create a malicious ERC20 contract, they could do that anyways. It's not like it affects other tokens in a fundamental way.

I know this may not be practical in the short term given timeline constraints, but I'm curious: aside from implementation time, do you see any fundamental blockers to introducing a non-ICS20 path for EVM-native assets?

I actually do like the fundamental idea of bypassing the hop through the bank module - especially if we discover that there are no downsides to just using EVM state rather than bank state for tokens. I'm not sure that we'll never want to use bank though, and I need to hear more opinions about what the consequences of moving off of it are.

It might be a good time to step back and ask whether ICS20 needs to be the default assumption for every asset class. There may be technically sound alternatives that provide a better experience for EVM devs while still keeping the IBC security model. Would love to hear your thoughts.

I think that ICS20 is a great and well-tested default standard, and I'm wondering if we could rewrite it for Cosmos EVM to cover basic cases. I do also think that it falls short for token extensibility as bank tokens aren't very extensible by default. Maybe this is time to look into ICS20-v2?

My main concern is timelines and I'm reluctant to rewrite the existing logic for the V1 of the EVM, but I do agree that we should look at this shortly after we release.

We should make as little changes as possible right now to the way that tokens are represented, but make sure that there's a viable path for migrating state onto the EVM in the future. There are already chains that use STRv2 and have bank tokens that they'll want to represent in the EVM if we choose to go that way. i.e. If someone has a precompile already, we should make sure that we can transition the precompile to an ERC20 contract in the future. Not sure if this is possible today, but I don't think it should be that difficult to make sure of.

[vladjdk]

I also want to mention that @reecepbcups opened an issue for permissionless ERC20 registrations in #17. If we're all aligned on going forward with minimal changes for our V1, then I'm open to merging in his original PR.

Edit: I also think that merging in #36 would be non-controversial since ConvertERC20 already exists to convert ERC20 into a bank token, but you can't convert back into an ERC20 from there.

[nowooj]

I'm joining this discussion because it's an interesting topic.
Everyone seems to have good ideas.

I'd like to share an idea for a new approach.

Extending the Bank Module

The bank module operates according to the implementation of the SendKeeper and ViewKeeper interfaces based on BaseKeeper. If we implement the abi call for ERC20 operation in BaseKeeper, we can use all the interfaces of the bank module for erc20 on evm. For example, we can query the transfer and balance information of erc20 through the cli and grpc of the bank module, and if we wrap MsgSend in the precompile bank module, we can transfer all denoms of the bank module through evm rpc.

Required Implementations

• erc20 interface call of the bank module
  (Here's some code that I've been running a poc on. https://github.com/xpladev/xpla/blob/release/v1.8.x/x/bank/keeper/evm_keeper.go)
• Wrapping MsgSend in precompile bank
  (Here's some code that I've been running a poc on. https://github.com/xpladev/xpla/blob/release/v1.8.x/precompile/bank/bank.go)

Advantages

• Cosmos engineers can easily manipulate evm's erc20 through the interface of the bank module.
• Evm engineers can easily transfer cosmos denoms through existing evm rpc.
• Token liquidity is not divided into cosmos and evm.
• We can use all cosmos functions that use the bank module, including ibc.
• We can use the denom address of erc20 as the hex representation of the erc20 contract address. For example, if an erc20 contract has the address 0xbf6Bc6782f7EB580312CC09B976e9329f3e027B3 on the evm, we can represent its denom as erc20/bf6Bc6782f7EB580312CC09B976e9329f3e027B3.

[zsystm]

@vladjdk

Is there a downside to removing the governance restriction? Why was it there in the first place? If someone wants to create a malicious ERC20 contract, they could do that anyways. It's not like it affects other tokens in a fundamental way.

While ERC20 tokens maintain their own independent balance states within each contract, the Cosmos SDK’s bank module manages a global balance mapping for all accounts and all denoms, structured as [account][denom] = amount.

In this context, if junk denoms accumulate on a particular account, it can lead to performance bottlenecks during balance iterations in certain modules or EndBlock logic, potentially resulting in DoS vulnerabilities. One of the worst-case scenarios would involve modules like distribution, which iterate over all denoms held by all accounts to perform operations like rewards distribution.

If users are allowed to freely register token pairs and convert between ERC20 tokens and SDK-native coins, it becomes significantly easier to carry out such attacks. The Cosmos SDK, by default, restricts the arbitrary creation of new denoms. However, if a malicious actor could mint native coins directly via transactions (without governance), it would lower the bar for spamming the chain with junk assets—far easier than launching an entire new chain.

Moreover, once these junk native coins are in circulation, they could potentially propagate to other chains via IBC, amplifying the problem across ecosystems.

This is likely why governance was originally required for such conversions—to prevent abuse scenarios like these.

cc. @dongsam

[nooomski]

I'll leave the topic for where IBC should be going to product manager @womensrights.

Suffice to say, we are not a stage yet where we have good visibility on what IBC will look like 6-12 months yet, so designing a system to support this is too early right now. What we do know is that users are in need of mint-burn functionality, but support for this is not required in v1, so it's safe to postpone that decision.

In other words, IBC design comes first, EVM adapts to that later.

Let's approach this iteratively. For v1, we need:

• The ability to send and receive ERC20 & ERC721 tokens. Extensions & variations of them do not necessarily need to be supported in v1, but considered for a later version.
• For this to require no additional user steps
• Tokens need to be visible on your EVM and Cosmos wallets like you would expect from any other chain, including send functionality.

A nice to have would be a great developer experience where:

• Developers and integrators can do all they need while accessing the chain purely via the EVM
• This is not P0 and can be left out of v1

After this, we can start thinking about broader separation of state between EVM and protocol layer, and a more generalizable way to support IBC.

I would like the engineering teams to think strictly within this requirements framework to come up with a solution that we can ship in a month, with minimal breakage.