[Feature]: permissionless erc20 <-> cosmos coin

[reecepbcups]

Summary

Currently only IBC coins and governance proposals set ERC20->Cosmos bank native pairs.

1. Functionality should be added to allow permissionless conversion of an ERC20 to a new (namespaced) bank pair.
   • 0x5FbDB... becomes erc20-0x5FbDB... for example
2. A user should be able to convert that cosmos bank pair back to the ERC20 (if required, evm prank as the contract/Ownable admin to mint?)

Problem Definition

IBC and gov only ERC20s is far too limiting. Cosmos bank tokens are superior and being able to convert to and from an ERC20<>bank is ideal. This way a user can:

eth mainnet -> LZ/IBC -> Chain WTOKEN -> ConvertERC20ToCosmosToken -> perform actions with it (staking, other) -> RedeemERC20FromCosmosToken -> LZ/IBC back out

This Chain WTOKEN is not the native token (the native_precompile), it is some new token.

Proposed Feature

Rough POC I put together. This assumes the codebase stays close to its current form and just appends on features.

• Ideally LinkERC20 isn't required and you can just ConvertERC20 to the cosmos coin for mint/redemption. Then remove IBC/Gov requirements for this
• The bank denom should match the erc20 denom name since the focus is EVM.
• If the linking nature persists, I do not see why we could not allow anyone to link, linking is sandboxed to its own namespace. Maybe a param for an optional fee cost here, similarly like token factory.

Script

# deploy some standard `contract MyERC20 is ERC20, ERC20Burnable`
forge script ./contracts/script/DeployERC20.s.sol --rpc-url http://localhost:8545 -vvvv --broadcast --base-fee 0 --gas-price 0 --priority-gas-price 0 --legacy

CONTRACT=0x5FbDB2315678afecb367f032d93F642f64180aa3

# this is what is being created
ondod tx controlpanel link-erc20 ${CONTRACT} --from=acc0 --yes
ondod q erc20 token-pairs # validate it is a new pair


# redeem ERC20 -> native token
printf "12345678\n" | ondod keys unsafe-import-eth-key my-account 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 --keyring-backend=test
ondod tx erc20 convert-erc20 ${CONTRACT} 100 --from=my-account --keyring-backend=test --yes --gas=2500000

# verify redemption took place
ondod q bank balances my-account
cast balance --erc20 ${CONTRACT} 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266

# TODO: I want to convert back to the ERC20 from my native bank balance plz

Permissionless Link Idea

// LinkERC20 implements types.MsgServer.
func (ms msgServer) LinkERC20(ctx context.Context, msg *types.MsgLinkERC20) (*types.MsgMsgLinkERC20Response, error) {
        // probably put this function call behind some param.AllowPemrissionlessLinks in x/erc20
	sdkCtx := sdk.UnwrapSDKContext(ctx)

	// the sdk denom will be the same as the erc20 address
	// TODO: verify this address does not already have a token linked with GetTokenPair
	if !strings.HasPrefix(msg.Erc20Address, "0x") {
		return nil, fmt.Errorf("invalid erc20 address: %s. Must start with 0x", denom)
	}

	// TODO: we can either: modify the SetCoinDenomRegex in the SDK config to allow denoms with 0x prefix, or prefix like this. i kind of prefer this & safer
	sdkdenom := strings.ReplaceAll(msg.Erc20Address, "0x", "erc20-0x")

	ms.k.erc20Keeper.SetToken(sdkCtx, erc20types.NewTokenPair(common.Address(common.FromHex(denom)), sdkdenom, erc20types.OWNER_EXTERNAL))

	return &types.MsgMsgLinkERC20Response{}, nil
}

[joelsmith-2019]

PR adds support for sending Cosmos Coins back to a Native ERC20 contract within Evmos: strangelove-ventures/os#4

[reecepbcups]

permissionless ERC20 registration as well from Joel -- strangelove-ventures/os#5

We'll be moving over the cosmos/evm fork soon so we can push to upstream as well as our own

[vladjdk]

@reecepbcups your PR makes converting between ERC20 and Bank tokens permissionless, but I personally think we should move off of the bank<>erc20 conversion behaviour and transition into having balances mirrored between the two.

Personally a fan of keeping this governance gated for now (and just not using it) and working on fully moving over to a mirrored mechanic for this.

This seems like legacy code before STRv2 was released, and would be more of a pain to migrate over to mirrored balances if chains used it.

Lmk what you think

[vladjdk]

Reopening this issue for more discussion.

Looking at this again, I'm actually more in favour of automatically registering tokens to be able to use precompiles (in particular, IBC).

Curious about opening up messages for conversion. Is there any place where you'd want a user to be able to convert into a bank token rather than build precompiles that automatically convert (like ICS20) for your applications? I think that best case, this would be a feature seldom used, and worst case it could cause some confusion if someone actually calls the message and their assets disappear from their wallet.

Have you seen anyone who wants to use this? I see you included an Ondo script here. What's their usecase?

Edit: Reading more into it, I'm seeing that converting back into an ERC20 is impossible unless you add the message back in. I don't think #36 should be controversial to merge in. My original point warrants a bigger discussion on whether this is the best way to manage token coexistence, which we're discussing in #65.

[reecepbcups]

Have you seen anyone who wants to use this? I see you included an Ondo script here. What's their usecase?

We have ERC20 tokens launched. They can be launched at any time from tools like Forge, Hardhat, etc. These ERC20s may be brand new or already have actions taken placed on them. They may include other interfaces than just standard ERC20.

Users will convert their ERC20 to the Cosmos asset when they are ready to:

• multi-stake said ERC20 (cosmos token) to a validator or
• use the tokens for gas (another custom module, out of scope of this) on the EVM layer
• or other cosmos specific logic with tokens

We will call in the UI to 'unwrap' the ERC20 -> Cosmos, then custom multi-stake precompile call at once for the user. Unsure if we will multicall or just make it a UI thing. It would be the same process as wrapping/unwrapping tokens. ETH users are aware of this.

Users HAVE to be able to return to the original ERC20 as these assets are not redeemable on the Cosmos side, only the EVM ERC20.

We are not comfortable using a pointer contract between an ERC20<>Bank. We want a clear 1 for 1 transfer to simplify complexity and avoid accounting issues for these RWAs.

We discount that ERC20s could be malicious and affect Cosmos tokens, but this is out of scope because ERC20s are permissionless. What they decided to do with the Cosmos coin is their admin's business and a feature, not a bug. it does not add any new security issues, rather just extends the nature of permissionless risks to the Cosmos side.

[zsystm]

@vladjdk @reecepbcups

Edit: Reading more into it, I'm seeing that converting back into an ERC20 is impossible unless you add the message back in. I don't think #36 should be controversial to merge in. My original point warrants a bigger discussion on whether this is the best way to manage token coexistence, which we're discussing in #65.

In the current cosmos/evm design, there really isn’t a scenario where an ERC20 token permanently resides in the bank state. The only time an ERC20 is converted to a bank coin is during an IBC transfer, and in that process, it’s immediately escrowed and forwarded—not held by a user in the bank module. (code reference)

If we start allowing a user-initiated conversion from ERC20 to bank coin (outside of IBC flows), then naturally we’d need a corresponding message to convert it back to ERC20. That’s why the current PR makes sense if certain use cases—like Ondo’s idea of staking an RWA ERC20 in the Cosmos staking module—require explicitly turning an ERC20 into a bank coin.

Overall, since cosmos/evm isn’t purely a standalone EVM but also ties into Cosmos functionality, exposing convert/unconvert features could be beneficial for future client chains. I don’t see a strong reason to oppose it if there’s clear demand.

By the way, permissionless conversion for already-registered token pairs is fine, but allowing permissionless registration of new token pairs is a separate issue and should be approached with caution. (#65 (comment))
cc. @dongsam