[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