# Deep EVM integration **URL:** \ **Category:** Community Huddle\ **Created:** [March 8, 2024, 1:13am UTC](https://forum.dymension.xyz/t/deep-evm-integration/1912 "2024-03-08T01:13:06Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![sdbs](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.dymension.xyz/sdbs/32/639_2.png) [@sdbs](https://forum.dymension.xyz/u/sdbs)\ **Post date:** [March 8, 2024, 1:13am UTC](https://forum.dymension.xyz/t/deep-evm-integration/1912/1 "2024-03-08T01:13:06Z")
Hi all, I’d like to invite the technically experienced part of the community to discuss a problem I voiced to the DeBank team. I’ve made some suggestions for integrating different types of Dymension transactions into DeBank EVM portfolio and Rabby EVM wallet. The dev team sent me the following response: “We have only integrated the EVM chain, and the staking function is on the Native chain (like Cosmos), so we cannot obtain the results and cannot integrate it.” After discussing my idea again with the dev team, they confirmed that they can’t read transaction type information from Dymension EVM explorer, so they can’t display tokens that are delegated to the validator and passed to staking, and they can’t display transactions with different types, including stake, gov vote re-delegate etc. The Dymension team in the discord also confirmed the existence of this kind of difficulty in transferring information to the EVM chain. One of the moderators suggested me to create a topic on the forum, and here I am. I’d like to thank Yishay for participating in the discord discussion and hope to hear your ideas. Perhaps discussing this problem here will help find a solution and thus integrate Dymension (and possibly future rollapps) into the EVM infrastructure, thus opening up huge new opportunities (including financial) for this blockchain. ---
**Author:** ![Yishay](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.dymension.xyz/yishay/32/2240_2.png) [@Yishay](https://forum.dymension.xyz/u/Yishay)\ **Post date:** [March 8, 2024, 8:12am UTC](https://forum.dymension.xyz/t/deep-evm-integration/1912/2 "2024-03-08T08:12:43Z")
Hey @sdbs thank you again for the valuable input. We’re highly prioritizing fluent EVM support as we understand the importance of UX and EVM user tooling which increases user confidence in the Dymension protocol. The following PR is a great step forward towards accomplishing this: > > > Virtual Frontier Contract is > \- A new type of smart contract in Ethermint fork v…ersion of Dymension. > \- A contract that can be interacted directly via Metamask or other Ethereum wallets. > \- A contract that is virtualized and does not exist on the blockchain. > \- Open ways to interact with Cosmos blockchain business logic via MM or other Ethereum wallets. > > Sub-types: > \- Virtual Frontier Bank Contract > > Technical notes: > \- Standing in front of EVM, doing stuffs instead of actually interacting EVM. > \- Prohibit to communicated within EVM. > \- Should not receive funds. If received, it results lost forever. Currently, when an Ethereum tx, with value != 0 (direct transfer or payable method call), are aborted. Not yet any implementation to prevent from Cosmos side. > \- New module store: Contract and meta corresponds to the sub-type. > > \# Virtual Frontier Bank Contract > > Virtual Frontier Bank Contract is > \- Virtual Frontier Contract. > \- A contract, simulated ERC-20 spec, allowed user to import to MM or other Ethereum wallets and can be used to transfer Cosmos bank assets via the wallets. > \- Automatically deployed when there is a new denom metadata created in bank module. > > Technical notes: > \- New module store: Mapping from denom to contract address. > \- Check bank denom metadata in begin block and deploy the valid ones. > \- Can be switch activation state via gov: \`ethermintd tx gov submit-legacy-proposal update-vfc-bank proposal\_file.json\`. > \- ERC-20 compatible: > - Support: > - \`name()\` > - \`symbol()\` > - \`decimals()\` > - \`totalSupply()\` > - \`balanceOf(address)\` > - \`transfer(address, uint256)\` > - event \`Transfer(address, address, uint256)\` > - Not yet support (due to security concern and not necessary for the purpose of this contract): > - \`transferFrom(address, address, uint256)\` > - \`approve(address, uint256)\` > - \`allowance(address, address)\` > - event \`Approval(address, address, uint256)\` > \- How to deploy: > - New contracts for new bank denom metadata records: > \`\`\`golang > if err := k.DeployVirtualFrontierBankContractForAllBankDenomMetadataRecords(ctx, nil); err != nil { > panic(errors.Wrap(err, "failed to deploy virtual frontier bank contract for new bank denom metadata records")) > } > \`\`\` > - New contract for a specific bank denom metadata record: > \`\`\`golang > err := k.DeployNewVirtualFrontierBankContract(ctx, &types.VirtualFrontierContract{ > Active: true, > }, &types.VFBankContractMetadata{ > MinDenom: ..., > }, &banktypes.Metadata{ > ... > }) > \`\`\` > > \# Review guide: > 1. Ignore review all files and dirs in sub folder \`integration\_test\_util\`, it is the skeleton, no need to review > 2. Can review actual implementation and some of the test in this Shorter \[PR\](https://github.com/VictorTrustyDev/fork-dym-ethermint/pull/1/files) (the same, before merge) > > Also closes #8 With the upcoming upgrade to the 2D codebase and thanks to the valuable contribution of **Victor** (co founder of [https://dym.fyi](https://dym.fyi)), we will support virtual ERC-20 representation of IBC tokens, **a novel feature**. This means you will be able to see all non-DYM tokens as if they are ERC-20 tokens while they retain their IBC capability (previous implementation was either ibc **or** erc). This is a first step towards many other “evm virtualization” of various native aspects of the cosmos sdk which will enable simple usage and representation on the evm tooling realms. TL;DR Cosmos underlying core tech is superior. EVM UX and tooling is widespread, easy and standardized. We’re working on connecting both seamlessly while retaining the best of both worlds.