Skip to content

Instantly share code, notes, and snippets.

@jcnelson

jcnelson/ethereum-nft-bridge-to-stacks.md

Last active December 31, 2021 07:03
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save jcnelson/2dcc1b912aa6ec39db008d53beea35d6 to your computer and use it in GitHub Desktop.
Save jcnelson/2dcc1b912aa6ec39db008d53beea35d6 to your computer and use it in GitHub Desktop.
Download ZIP
ethereum-nft-bridge-to-stacks.md
Raw
ethereum-nft-bridge-to-stacks.md

Problem

NFTs exist on Ethereum, and we want to "port" them to Stacks. To avoid duplicity, any mechanism that does this will necessary need to do two things:

  • Burn the NFT on Ethereum, thereby rendering it un-transferable
  • Instantiate the NFT on Stacks

This document sketches a "NFT bridge" system that allows a trusted intermediary to gather burned NFTs on Ethereum and instantiate them on Stacks. The intermediary can grant the NFTs to the original Ethereum owner by sending them to a Stacks address of their choosing (that they would specify as part of burning the NFT), or it can hold on to the newly-ported NFTs and auction them off.

Design Sketch

There are two principal components to this system:

  • An off-chain bridge program that interfaces with an Ethereum block explorer to verify that an NFT is actually burned.
  • A Clarity contract that allows the bridge program to instantiate a burnt NFT on Stacks.

Burning NFTs

To burn an NFT, the user simply needs to send a transaction to invoke the transferFrom or safeTransferFrom methods on the NFT's corresponding ERC721 contract to send the NFT to a burn address (such as 0x0000000000000000000000000000000000000000). The user then submits the transaction ID to the bridge program, in order to prove to the bridge program that the NFT was indeed burnt. This could be handled by an Ethereum web app with Metamask -- once the transaction is sent, the web app submits the transaction ID to the bridge program automatically.

Instantiating NFTs

Once the bridge program has received a transaction ID and verified that it is (1) sufficiently confirmed on the Ethereum chain and (2) corresponds to an Ethereum transaction that burnt a particular NFT, it can proceed to create that same NFT on Clarity. To do so, the bridge program would be paired with a Clarity smart contract with the following features:

  • The Clarity contract would implement its NFT via the native define-nonfungible-token built-in.
  • The Clarity contract would have a data-map that linked each NFT it minted with the Ethereum transaction ID that corresponds to the burnt NFT on the Ethereum chain.
  • The Clarity contract would implement the NFT trait described in the forthcoming NFT SIP by Friedger: https://github.com/stacksgov/sips/pull/3/files. This would make it compatible with future NFT exchanges on Clarity.
  • The Clarity contract would only allow the bridge program (or an authorized entity) to mint the NFTs. For example, it might require that tx-sender is the bridge program's address.

Limitations

The bridge program is trusted to carry out the NFT instantiation on Clarity in a timely manner. We're assuming that it will remain online indefinitely in order to do so. We're also assuming that the bridge program's private keys don't get lost.

If we're assuming that a particular 3rd party entity like Daemon Technologies will be responsible both running the bridge program and for buying and then burning NFTs, then this largely de-risks the bridge misbehaving. If the bridge does indeed break, then Daemon Technolgies could simply re-instantiate it with a different Clarity smart contract that mints the NFTs. It would need to be understood by exchanges, then, that Daemon Technologies was responsible for creating multiple Clarity contracts that minted multiple batches of NFTs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment