Skip to main content

Porting Hedera NFTs

Overview​

The page describes the steps and standards needed to transfer Hedera-based NFTs to an EVM chain on hashport.

Steps​

1. Deposit transaction​

Alice uses the hashport client (a UI interface) to transfer the Hedera-based NFT she wants to port. She uses a software crypto wallet (e.g. MetaMask) or wallet directly loaded into hashport to send the NFT to the Portal Account. Similar to fungible tokens, the memo of the transaction contains a {targetChainId}-{receiverAddress}, which will receive the projected NFT on the EVM chain.

note

Only a single NFT can be ported at any given time.

Example of how to submit a Deposit transaction to the Bridge account in Go using Hedera Go SDK:

nftID, _ := hedera.NftIDFromString("11@0.0.15633470") // 11 - Hedera Token serial number, 0.0.15633470 - tokenID of the Hedera token
response, _ := hedera.NewTransferTransaction().
    SetTransactionMemo("80001-0x0000000000000000000000000000000000000002"). // 80001 - chainId of Polygon Mumbai Testnet, 0x0000000000000000000000000000000000000002 - receiver address
    AddNftTransfer(nftID, client.GetOperatorAccountID(), bridgeAccount). // Send the NFT to the bridge account
    AddHbarTransfer(bridgeAccount, hedera.HbarFrom(1, "hbar")). // Send the NFT bridge transfer fee to the bridge account
    Execute(client)

2. Picking up the transaction​

Validator nodes listen for new incoming transactions to the Portal Account. After receiving Alice's transaction, the nodes verify the state proof and validate the memo.

3. Paying out fees​

3.1 Each validator node creates a Schedule Transaction (ScheduleCreate) that transfers the service fee amount from the Fee Account to the list of validators equally.

3.2 Only one of these schedule transactions will be successfully submitted, creating a schedule entity. All other scheduled transactions will fail with IDENTICAL_SCHEDULE_ALREADY_CREATED error, and the transaction receipt will include the ScheduleID of the successfully submitted transaction.

3.3 All validators, except for the one that successfully submitted the transaction, will need to submit a ScheduleSign transaction. Once n out of m validators have signed the scheduled transaction, the scheduled transaction will be executed and the service fee will be sent out of the Fee Account.

tip

You can learn more about Scheduled Transactions here.

4. Providing authorization signatures​

Each validator node will need to sign the following authorization message: {hedera-tx-id}{router-address}{projected-token}{receiver}{amount} using their EVM-compatible private key. The message is then submitted to a topic in the Hedera Consensus Service.

5. Waiting for supermajority​

Alice's hashport Portal waits for a supermajority of signatures, which is checked by watching the topic messages stream or fetched directly from the validator nodes.

6. Submitting the EVM transaction​

Once a supermajority is reached, Alice submits a transaction to the EVM chain to claim her projected NFT. The transaction contains the raw data signed in the message: {hedera-tx-id}.

7. Verifying the transaction​

The EVM chain smart contract verifies that no replay attack is being executed by checking the hedera-tx-id and verifies the provided signatures against the raw data that was signed.

tip

You can learn more about replay attacks here.

8. Receiving the projected NFT​

If consensus is reached, the Router contract mints the projected token to Alice's EVM address.