Immutable is pleased to introduce Arch v1.0

Immutable is pleased to introduce Arch v1.0, an NFT bridging protocol between L1 Ethereum and L2 StarkNet. We’re excited to be working with the community by making our contracts open source, and we invite everyone to try our deployed contracts.

Why bridge?

StarkNet is a general-purpose Layer 2 rollup, extending Ethereum and inheriting its security benefits. Trustless bridging of assets between layers is an important piece of the puzzle for L2s to facilitate the interoperable future of blockchain applications.

While fungible token (e.g. ERC20) bridges are a common way for users to move their capital between layers, there are fewer bridges for non-fungible tokens. NFT projects that require assets to be moved across layers often end up having to build their own bespoke bridging solutions with varying levels of security guarantees. We believe that as the NFT-Fi and cross-chain Web3 gaming ecosystems mature, demand for NFT bridging will rise.

NFTs that are native to a single ecosystem like StarkNet will also benefit from the guarantee of an off-ramp to Ethereum. Every rollup or chain has different tradeoffs including scalability, decentralization, etc, and a trustless bridge aims to close this gap by offering seamless interoperability and freedom of choice for users. We present Arch v1.0, an ERC721 bridging protocol, to support our vision of making digital worlds real and giving the ownership of digital assets to users.

Design

This is an initial design of an NFT bridging protocol from L1 Ethereum to L2 StarkNet with room for iteration and improvement. The bridge is initially designed for the most simple use case of projects wishing to bridge their L1 Ethereum NFT collections to L2 StarkNet. In the future, we may explore additional primitives and extensions such as bridging L2 native assets to L1 or supporting more networks.

The design aims to be generalized and contract-agnostic, to provide a simple building block for developers to integrate their new or existing projects. It was primarily developed for use with ERC721 tokens but the design is extensible to other NFT standards like ERC1155.

The ERC721 bridge comprises four main contracts:

• Bridge Registry (L1)
• ERC721 Escrow (L1)
• ERC721 Bridge (L1)
• ERC721 Bridge (L2)

The bridge registry contract stores L1<>L2 token contract mappings and acts as the source of truth for the ERC721 Bridge. The initial implementation will be a permissioned approach on the mainnet (permissionless on Goerli) where Immutable will control the registration of token contract pairs, as to ensure the security of the bridge whilst still in the ‘alpha’ stage. This permissioned registration process will be removed when we are confident there are minimal security risks involved with permissionless registration going forwards.

The ERC721 escrow contract manages the locking and release of ERC721s bridged to L2. This lockbox contract holds NFTs in escrow whilst they exist and transact on L2, and will be released when withdrawn back to L1. This functionality was decoupled from the main bridge into its own contract to allow for extensibility and asset management. Only the bridge contract will be granted permission to be able to transfer ERC721s to and from the escrow contract.

The ERC721 Bridge contracts (L1 and L2) are the main bridging contracts that handle the sending and receipt of messages between L1 Ethereum and L2 StarkNet. The bridge contracts are the primary interface for end-users to interact with the bridge, and expose external functions like deposit and withdraw to initiate or complete bridging actions. The L2 ERC721 bridge contract is written in Cairo and acts as the counterpart to the L1 bridge on StarkNet.

IERC721_Bridgeable

For StarkNet token contracts to be compatible with the ERC721 bridge, they must implement IERC721_Bridgeable in their ERC721 contracts. The interface specifies permissionedMint and permissionedBurn functions, which should be access limited to only the bridge and can control the supply (minting and burning) of the tokens on StarkNet. Upon depositing tokens from L1, the bridge will mint tokens to the recipient on L2, and similarly burn tokens upon withdrawing tokens to L1 from L2. The interface is inspired by StarkWare’s fungible token bridge StarkGate and its interfaces for L2 bridgeable (fungible) tokens.

User flows

Registration

When the token bridge is deployed, project owners will be able to register their L1 and L2 token contract pairs to make their assets bridgeable by reaching out to Immutable for manual contract registration. On our Goerli testnet deployment, users can register their contracts permissionlessly. We will be looking into ways to make the entire mainnet registration process permissionless and frictionless in the future.

After registering the L1 and L2 contract pair in the bridge registry, users will be able to deposit and withdraw the corresponding ERC721 tokens freely between Ethereum/StarkNet.

Deposits from L1 to L2

NFT deposits from Ethereum to StarkNet follow a standard ‘lockbox’ system where the deposited assets are held in an escrow contract (ERC721 Escrow) on L1 while being minted and used on L2. This can be framed as a ‘wrapping’ operation where the wrapped asset is freely tradable and can be redeemed for the base asset at any time. Deposits require that the L1 <> L2 token contract pair has already been registered in the bridge registry as above, and also require an additional step from users to approve the bridge address for transferring the tokens they wish to deposit. After token approval, only one transaction on L1 is required to deposit, which automatically triggers the handler on the L2 bridge to mint the corresponding NFT(s) when the L1 message is received.

There is also a mechanism for canceling deposits in the unlikely event that the deposit message was not sent to StarkNet successfully. This is a two-step process: the first transaction will initiate the message cancellation request. Then after a waiting period (5 days) to ensure there are no race conditions or otherwise, the user can complete the message cancellation and transfer the deposited NFTs back to their wallet.

Withdrawals

Only the owner of the L2 equivalent asset will be able to initiate the withdrawal and retrieve the NFT from escrow, at which point the token will be burned on L2 and the details of the withdrawal will be sent in a message to the L1 bridge contract. Unlike in the L1->L2 flow, we can’t automatically trigger transactions upon the receipt of L2 messages so the withdrawal process requires a second step from the user to complete the withdrawal on L1. The initial implementation of the bridge only supports withdrawals of L1-deposited tokens, not L2-native tokens, but this is also a use case we are exploring.

What’s next?

Feel free to experiment with bridging your assets through our Goerli testnet deployment now! Visit our Github for information on our contract deployments and how you can get started.

This is just the first iteration of our StarkNet NFT bridge, and we will be looking into extending this design with new features to support more use cases. Some extensions and areas of improvement we may explore include:

• Decentralization — let projects or users permissionlessly bridge their assets without the need for a trusted third party to register with the bridge
• Automatic StarkNet contract deployments — reduce bridging friction for developers and users by auto-deploying a standard ERC721 contract upon bridging an asset for the first time
• Support withdrawal of L2 native assets — providing an off-ramp to Ethereum for StarkNet native projects gives users more flexibility and a stronger guarantee for their assets
• Multi-chain — the bridge design can be extended to include multiple chains and rollups, including our existing Immutable X StarkEx ecosystem, to facilitate more StarkNet interoperability

‍