Teleporter ERC721 Bridge

[vikinatora]

🧍Introduction

The Teleporter protocol is implemented at the smart contract level and serves as a user-friendly interface to AWM, targeting dapp developers. Each dapp protocol can decide for itself how to leverage Teleporter and AWM to enable cross-subnet functionality. Among the common use cases well-known in the blockchain space are ERC20 and ERC721 bridging. This discussion aims to outline the implementation of an ERC721 bridging dApp.

🗺️ Development Roadmap

1. ERC721 Bridge Contract & Permissioned ERC721 Contract

The ERC721 Bridge Contract will enable users to transfer their NFTs from one subnet to another. A key piece of the contract's logic will be to track the other bridge addresses, create a clone of the ERC721 contracts on non-native subnets, as well as mint or burn the tokens depending on the situation. It's going to have the following functionality:

• Execute three different cases inside bridgeNFT:

  Each outbound message type will have a corresponding inbound message handler inside receiveTeleporterMessage:

  • Send a message to create a clone of the ERC721 contract.

    • The contract will send a message with a create action to the destination subnet.

  • Send a message to mint the user’s token.

    This action will be executed if the token exists only on its native subnet.

    • The contract will send a message with a mint action to the destination subnet.
    • The contract will lock the user’s NFT until released by a transfer message.

  • Send a message to transfer the user’s token to a different subnet.

    This action will be executed if the token already exists on a subnet and the owner wants it to be transferred to another subnet. A critical requirement of the bridge is to allow a specific token to exist on only one non-native subnet. That's the reason why in non-native to non-native subnet transfer cases, the “two hops” approach must be implemented.

    • The contract will send a message with a transfer action to the native chain.
    • In all cases, the token on the current subnet is going to be burned.
    • The logic executed on the native subnet inside receiveTeleporterMessage is explained below.

• Execute three different cases inside receiveTeleporterMessage:

  • Create a clone of the ERC721 contract.

    • Create a new ERC721 contract with the same name, symbol, and tokenURI as on the native subnet.

  • Mint a specific token.

    • Mint a specific token to the user’s address.

  • Transfer token to another subnet.

    This case can be triggered only on the token’s native subnet. Depending on the destinationSubnet message payload, the contract will either:

    • If the destinationSubnet is the token’s native subnet, then the bridge contract will transfer the token back to its owner.
    • If the destinationSubnet isn’t the token’s native subnet, then the bridge contract will update its mapping that tracks the NFT’s whereabouts and send a mint message to the destination chain.

Additionally, the bridge is going to use an ERC721 contract. Only the bridge contract is going to be authorized to mint tokens.

• Create an ERC721 contract that allows only the bridge contract on each subnet to mint tokens.
• A new instance of the contract is going to be created for each NFT collection.

2. Contract Tests

The contract swill have unit tests validating the correct behaviour of the bridge contract:

• Unit test(s) to validate outbound create message sending.
• Unit test(s) to validate outbound mint message sending.
• Unit test(s) to validate outbound transfer message sending.
• Unit test(s) to validate inbound create message processing.
• Unit test(s) to validate inbound mint message processing.
• Unit test(s) to validate inbound transfer message processing.

3. Integration Tests

The contract will have set of integrations tests to validate the end-to-end behavior of the contract:

• Test(s) to validate create message use case.
• Test(s) to validate mint message use case.
• Test(s) to validate transfer message use case.

4. Documentation

LimeChain recognizes that documentation is a critical component of open-source software. As such, we are committed to providing comprehensive developer documentation.

• Include inline documentation for the bridge contract. This includes NatSpec documentation, as well as in-function documentation explaining key moments.
• Include a README file that describes the high-level design of the contract.

Note: The contracts shall be implemented in LimeChain’s fork of Teleporter repository. This is due to the fact that all upstream contracts are audited, while the scope outlined above doesn’t include external audits. Nevertheless, the contracts will be audited internally at LimeChain before releasing them.