-
-
Creation of crossChain linked nameServiceBoundAccounts.
-
Graphic explication:
Inspiration
My inspiration for this project came from 3 things:
- Wanting to use the erc6551 tokenBoundAccount standard
- Loving crossChain stuff
- A past experience trying to attach an ENS domain to an abstractedAccount / smartAcocunt.
This is how I came up with this "./crossChainNameServiceBoundAccount".
What it does
It creates a resolver of a domain of a nameService in the format of a erc721 nonFungibleToken, then creates a erc6551 abstracted account that is controled by that nftFormatResolver and gives it the capacity to do crossChainTxs thanks to CCIP infrastructure.
This erc6551Accounts are also created multichain, so if I create my nameServiceBoundAccount "mySampleAccount" on polygon, another version of "mySampleAccount" is created on ethereumMainnet and theyre linked. This means that with my polygonVersion of "mySampleAccount", I can control my ethereumMainnetVersion and this enables two important things for the whole evmEcosystem:
- evmUxUnification:
With this arquitecture of crossChain linked nameServiceBoundAccounts, the average user doesnt has to worry about the average hassle of the EOAs; he can move freely and transact across ethereumMainnet and all layerTwos from a single evmChain without worrying about changing RPCs or switching networks by ordering the otherChainsVersions of the accounts what to do. An example of this is using a polygonAccount to control their otherChainsVersions of base, arbitrum, etc and viceversa, the base and arbitrum can also control the polygonVersion since theyre all linked and have permission.
- gasAbstraction:
This lets any user pay any Tx on any chain with any nativeAsset of any evmChain, for example; I can pay Txs on arbitrum, base, optimism and linea with matic, this is up to the user so if he just has mainnetEth, he pays with that any Tx on any layerTwo. Just to be clear; this enables that the user can execute any tx on anyEvm chain as long as he has any nativeAsset of layerTwos or mainnet available.
Is important to note that the nameServices works in the chain is implemented but also as crossChain, so it can be used on multiples chains, aside from.
How we built it
I build a customErc721 contract that mints just one id (just one NFT), a customErc6551AccountImplementatation and a crossChainVersion of the erc6551Account that is linked to the anotherChainAccount and the erc6551Registry which in combination with CCIP infrastructure creates the ccNameServiceBoundAccounts and links them across chains so they can be controled. Aside from the contracts I used the regular fullStackDapp stack; ethersJs, reactJs, tenderly, metamask.
Challenges we ran into
Manipulating the gas limit of CCIP arbitrage data, it always gave error due to not enough gas, but when I used more it also gave the error of excessive gas.
Accomplishments that we're proud of
What this arquitecture enables; unifying the evmEcosystem by letting users move freely on any layerTwo and evmCompatible chain from a single account that can be in the chain that the user decides and making the process simlpe for the user by also giving his accounts a humanReadableName.
What we learned
Correct gas usage and how to estimate it.
What's next for "./crossChain6551NameService"
Once CCIP adds more available chains, deploy the protocol / project there so that the user have more options to use and, in the case that CCIP starts being used on nonEvmCompatibleChains, develop that specific blockchain version of the crossChainNameServiceBoundAccount.
Working Deployed addresses:
- Sepolia 0x1b5362c8fac73f0e04dcb274d7f64e5bc3923ce1
- Mumbai 0xb43cc083DD0c07eE43a4Af5542979E4ea642ffBB
- Fuji 0x5154440E0c8711264F543A4431C8657fF44A7C40
Log in or sign up for Devpost to join the conversation.