Permissioned Teleporter ERC721 Bridge

[vikinatora]

👋 Introduction

The purpose of this page is to outline the current key design characteristics of the Teleporter ERC721 Bridge, as well as propose a new design that is tailored for a different subset of use cases. We believe that depending on the users’ needs, both designs have a lot to offer across a broad range of use cases.

📔 Problem Statement

The current design of the ERC721 Bridge (ERC20 Bridge as well because the former is based on it) is pretty flexible, permissive, and generalized which has been brought up by members of the Interoperability. The primary functionality of the bridge is to track token’s status and burn/mint/deploy based on that. That in of itself is great, however there are multiple use cases in which it doesn’t suffice. For the most part they demand antagonistic design characteristics to the ones mentioned above i.e permissioned and use-case specific.

✅ Proposed Solution

Key characteristics

Permissioned (two-way binding): Only a specific (set) of contracts can utilize the bridge. This is in contrast with the existing design where the bridge can be used to move tokens from any subnet contract to any subnet contract, as long as there’s a bridge contract deployed that can relay the message. Note: permissioned bridging to multiple subnets is possible, but it has to be configured by the bridge operator.

Use-case specific: Avoiding coupling can result in hard-to-understand abstractions. Fortunately, this isn’t an issue with the bridge. Coupling Teleporter protocol logic with dapp logic isn’t a code smell anymore. It’s how it should be since only the dapp will be able to use it. The dapp developer is free to implement bridge and dapp specific logic without worrying about unnecessary abstractions.

Design

ERC721 deployment: Deploy NFT contract separately and configure the Bridge(Teleporter) contract. Set permission for minting in the NFT contract to the Bridge contract.

Minting/Buy NFT: Minting NFT from ERC721Bridge will lock the NFT on the other network. This will prevent NFT being minted on the other chain as well from another address. NFT can be minted on either side and transferred

Transfers: Transfers happen through NFT contract - Bridge is unaware of owner changes

Bridging: ERC721 is minted on subnet A. Bridge A locks the NFT and sends a warp message to Bridge B on destination chain. Bridge B mints/unlocks NFT on destination chain and transfers it to recipient. Optional: Bridge could directly bridge and transfer NFT to another address. For example user had multiple addresses and wants to transfer the NFT on chain B to another address he/she owns.

🪴 Example Use Case

Subnet A has a game specific hypervm with f.e in-game logic, nearly gas-free transactions and ERC721s items. Subnet B has a heavily optimized hypervm for trading ERC721s and ERC20s. Additionally, it also has a lot of users and liquidity, making trades fast and easy. Subnet A operator is presented with the problem of facilitating trades of in-game items. Instead of creating an ERC721 Marketplace that’s tied to trading the in-game items and trying to teach users how to use it, the owners can use the permissioned ERC721 Bridge contracts on both subnets. This allows users to trade on subnet A using a familiar interface and play the game on subnet B. The approach enables users to harness the powers of each subnet, while having minimal discomfort when wanting to trade the NFTs.

[minghinmatthewlam]

@vikinatora thanks for putting this together! I was a bit confused by the use of "bridge", referring to ERC20Bridge, ERC721Bridge, and Teleporter, but the writeup was helpful to understand use cases, especially like the diagram.

Does "permissioned (two way bindings)" mean that users with permission need to whitelist the ERC721Bridge contracts on both contracts to successfully bridge? If so, what are the trust assumptions shared amongst the subnets that use the ERC721Bridge?

[vikinatora]

Thanks for the feedback @minghinmatthewlam! I apologize if there are some hard to understand parts. If you specify them, I will improve them.

Does "permissioned (two way bindings)" mean that users with permission need to whitelist the ERC721Bridge contracts on both contracts to successfully bridge? If so, what are the trust assumptions shared amongst the subnets that use the ERC721Bridge?

I'll assume that by "users with permissions" you mean dapp(protocol) admins that want to use cross-subnet messaging. Since they will be deploying the bridge on both subnets, there are little trust assumptions in that regard. Of course, dapp contracts should have the bridge address whitelisted, since we don't want a malicious bridge to be able to send a message to the dapp contract.