Inspiration
In the past, I have worked on an NFT project on the Ethereum mainnet, and I hope to provide more diverse NFT application scenarios within the layer 2 or other cheap EVM blockchains. At this point, I ran into cross-chain issues with NFTs.
Traditional cross-chain assets have the following two forms:
- Use a lock and release mechanism. That is, the NFT is locked on the mainnet and a new NFT is released on the layer 2 at the same time. However, due to the equity attributes of NFT, using this mechanism may result in the loss of users’ NFT equity.
- Synchronously discover new NFTs on the layer 2. This mechanism may cause the connection between the layer 1 and layer 2 NFTs to break, causing the second-layer NFT to actually become an independent project.
Based on the above thinking, I hope to realize the multi-chain application scenario of NFT based on the ERC6551 account of NFT.
What it does
Users can use any NFT to create an ERC6551 account in the ERC6551 factory contract of the first layer; and call the bridge contract to create an ERC6551 account in L2.
How we built it
I created an ERC6551 factory contract on L1 to create an ERC6551 account for each NFT, and deployed the CCIP cross-chain bridge contract. Users can use the CCIP bridge contract to call L2's ERC6551 cross-chain acceptance contract to create an ERC6551 account in L2 or modify the owner of an ERC6551 account in L2
Challenges we ran into
CCIP usage and testing
Accomplishments that we're proud of
- A complete example of CCIP testing in Foundry is given
- Modify the creation of ERC6551 accounts by the ERC6551 factory contract in L2 to be idempotent. If the factory contract discovers that an ERC6551 account has been created, its creation behavior will be modified to set the owner.
What we learned
How CCIP works and local testing methods.
Built With
- ccip
- solidity
Log in or sign up for Devpost to join the conversation.