Overview

Wormhole’s Native Token Transfers (NTT) is an open-source development framework that allows projects to define a canonical multichain deployment for their tokens. NTT builds upon Wormhole Messaging to embed multichain interoperability at the token layer, and it is open and flexible to accommodate additional verification frameworks. Projects that integrate with NTT (“Integrators”) maintain control and flexibility over their multichain deployments, offering a future-proofed framework to accommodate subsequent changes or upgrades. For users who transfer their tokens crosschain, the NTT workflow eliminates risks of slippage, LP fees, or MEV, resulting in better execution. NTT allows for a globally synchronized token state across multiple blockchains.

How It Works

NTT builds on top of Wormhole’s messaging protocol through the addition of an NTT Manager contract. This NTT Manager contract is owned by the integrator, it defines the canonical token on the chains where it is deployed, and it implements the associated logic. This includes the management of the minting, burning, and locking of tokens in response to instructions passed through the messaging protocol. It is broadly extensible and composable with other token frameworks, like SPL or ERC-20. 

Projects with existing tokens can integrate NTT for lock-and-mint transfers, while new tokens can utilize NTT for burn-and-mint transfers. Integrators can utilize NTT’s command line interface (CLI), which simplifies the entire deployment process into calling a few functions. With coming upgrades, the CLI will soon allow for automatic configuration of the contracts, deployments to new chains, and robust verification and status checks. The CLI will eventually support functionality to upgrade contracts and configure custom transceivers. While Wormhole Contributors have built a reference implementation for the standard NTT framework that integrators can use off-the-shelf, the framework is entirely open source and can be customized for integrators that have more specific needs. The standard workflow is as follows:

Standard NTT Framework

1. On a source chain, a user wants to perform an action that requires a native token transfer, such as transferring from Solana to Base. The user signs a transaction that grants approval to burn a token in order to receive a transfer of the token on some destination chain. 
2. This message is received on the source chain by the NTT Manager contract, which is owned by the integrator. The NTT Manager notifies a Wormhole Transceiver of a token burn, which passes the message to the Wormhole Core contract.
3. The Wormhole Core contract, which is deployed on every supported chain, is responsible for receiving the onchain messages from Transceivers and emitting the message to the Wormhole Guardian network as an event. The Core contracts maintain a record of these messages in a transaction log.
4. The Wormhole Guardian network is a distributed set of 19 institutionally-run nodes that monitor the states of all supported blockchains. The Guardians monitor these Core contracts across the supported chains and listen for events emitted by the contracts that contain messages. 
5. The Guardians independently observe these messages and produce a signature for the corresponding data payloads. Signatures for these payloads are aggregated as a multi-signature to reach the 13/19 supermajority consensus on the payloads. Once consensus has been reached on a particular payload, the messages and Guardian attestations are packaged into a data structure called a Verified Action Approval (VAA). The VAA functions as a proof of a message upon which the Guardians have reached consensus.
6. Relayers monitor the Guardian network for completed VAAs and submit them in a transaction to a Wormhole Transceiver on the destination chain. 
7. The Transceiver queries the Core contract to perform a verification of the VAA. The Core contract parses the VAA to verify the signatures for the corresponding payload, or rejects the VAA if it fails signature verification. 
8. Upon verification of the VAA by the Core contract, the Transceiver passes the attestation containing instructions to the NTT Manager contract on the destination chain. 
9. With receipt of this attestation, the NTT Manager can mint and transfer tokens to the recipient on the destination chain. The lifecycle of a standard native token transfer is now complete.

Source: Wormhole

Custom NTT Framework

The Native Token Transfer framework gives integrators the ability to customize and parameterize various aspects of the NTT workflow. With customizable attestation, integrators can articulate a desired workflow for verifying and signing message payloads that is independent of the Guardian network. This customization allows the integrator to utilize the NTT framework while improving on the redundancy of the system. NTT integrators can implement their own distributed node set, with arbitrary constraints that define consensus on an attestation. This could be any desired permutation of a multi-signature scheme, or alternative verification models. Following a custom workflow, the attestation would be relayed to an integrator-owned Transceiver on the destination chain, which would pass this attestation to the NTT Manager contract. The NTT Manager contract can define the threshold for the set of valid attestations that would initiate a token mint and transfer. For example, 1 attestation from the Guardian network, +1 matching attestation from the customized node-set, to equal 2/2 consensus on the token transfer. 

1. A user signs a transaction requesting a token transfer and grants approval for a burn. This message is received by the integrator-owned NTT Manager contract on the source chain.
2. The NTT Manager shares this message with the Wormhole Transceiver, which then proceeds to execute the standard NTT workflow, described in steps 3-8 above. 
3. Concurrently, the NTT Manager shares this message with an integrator-owned Transceiver. The Transceiver emits a message that contains the chain ID of the destination chain, the address of the destination NTT Manager, the recipient address, and additional instructions to be executed on the destination chain. The transceiver fetches and returns the price for a transfer to the destination chain, providing a quote for the necessary fee. The Transceiver’s messages are picked up by the nodes defined in a custom attestation framework. 
4. The integrator can define and implement an arbitrary offchain verification and attestation scheme for messages emitted by the integrator’s transceiver. This could involve proprietary nodes run by integrator, or incorporate an additional 3rd party, such as Axelar messaging, as evidenced in the Lido case study below.
5. The custom attestation route performs verification and attestation of the messages, independent from the verification being performed by the Guardian network. These attestations are then passed to an integrator-owned transceiver on the destination chain.
6. The NTT Manager on the destination chain receives and aggregates the attestations from the custom verifier set and the Guardian network. The integrator can define the NTT Manager’s requirements for what constitutes the set of valid attestations that would initiate a mint and transfer. E.g. 1/2 , or 2/2.
7. If the NTT Manager’s threshold is satisfied, the contract mints and transfers the token to the recipient, completing the lifecycle of a custom NTT workflow.

Source: Wormhole

Security Features

As a security measure, integrators can configure the NTT Manager contract to administer rate-limits on inbound and outbound transfers. The integrator can implement access controls to delineate the owner of the NTT Manager address from the address of the pauser role. Integrators can lean on Wormhole’s Global Accountant for additional security measures. The accountant monitors the total circulating supply of a token legitimately minted on a chain and ensures that transfers out of that chain can never exceed the legitimate supply figure.

Relayers

Relayers are generally permissionless entities responsible for picking up VAAs from the Guardian network and delivering them to the destination chain Transceivers. Given their responsibility in the message-passing workflow, they are a necessary dependency to maintain liveness and fulfill a crosschain transfer. To pick up VAAs, relayers often run a Spy, which is an innocuous, listen-only local daemon to monitor VAAs from Wormhole Guardians. Given that a relayer must pay gas to submit a VAA in a transaction on a destination chain, they must be incentivized and compensated for this. As such, NTT exposes the capability for users to pay relayers a fee in order to have their NTT transfers automatically delivered. 

The majority of messages passed through Wormhole are delivered by automatic relayers, a number of which are operated by core-contributor xLabs. Application developers have the ability to purpose-build specialized relayers to fill transfers related to their applications. With a specialized relayer, the application developer can configure and customize the parameters to optimize their implementation. This can include offchain computation, message batching, fee structures, gas drop-offs, or other instructions. Additionally, an integrator can whitelist or permission the set of relayers that can submit VAAs to the Transceiver, which further defines trust assumptions. 

NTT Case Studies

Lido

Lido is currently moving forward with a custom NTT workflow to deploy a canonical version of wstETH on BNB chain. Following controversy over LayerZero’s deployment of wstETH on BNB as an Omnichain Fungible Token (OFT), the Lido DAO published a Request for Proposals (RFP) to bring wstETH to BNB chain. Several projects, including LayerZero, Chainlink, and Hyperlane shared their respective proposals for this scope. Wormhole collaborated with Axelar to propose a BNB deployment of wstETH leveraging NTT, which was ultimately selected as the winning proposal following a snapshot vote. 

The proposal architects a customized NTT workflow to bring wstETH to BNB chain. Given that wstETH is live on Ethereum, the implementation would run a hub-and-spoke workflow, where wstETH can be locked on Ethereum to mint a burnable ERC-20 token on BNB. In reverse, wstETH on BNB could be burnt to unlock wstETH on Ethereum. In this custom workflow, Axelar messaging will be added as an additional verifier for crosschain messages, via an Axelar Transceiver contract. Both the Wormhole Guardian network and Axelar validators would independently monitor and verify messages from the NTT Manager contracts, and pass their attestations to endpoints on the destination chain. 

Source: Wormhole Foundation

An NTT Manager contract on the destination chain would aggregate the verifications from Wormhole and Axelar, and if the 2/2 threshold is met, perform the mint or unlock of the wstETH token. By customizing the NTT workflow to add Axelar as an additional verifier, security is improved, as both Wormhole and Axelar must independently verify and agree on a message to initiate a token transfer. However, this does present a liveness constraint, as the workflow can only function with the uptime of both messaging networks. With the flexibility of NTT, the Lido DAO could change the attestation threshold or the enabled Transceiver contracts at any time if they wish to adjust their deployment.

The NTT Manager contract will ultimately be controlled by Lido governance. The Lido DAO will maintain control of the verification scheme and retain the flexibility to add or remove additional verifiers. Currently, deployment of the Wormhole-Axelar solution for wstETH is expected to go live on BNB mainnet on July 1st. It is intended that this NTT workflow will define the canonical wstETH on BNB chain, and following deployment, Lido will take a snapshot vote to formally acknowledge this. 

Fantom

The Fantom Foundation, too, has leveraged NTT to transfer canonical USDC from Ethereum into the Fantom ecosystem as USDC.e. Given that Circle’s Cross-Chain Transfer Protocol (CCTP) does not yet support Fantom as a route, NTT can be leveraged in its place. Here, NTT is used to lock canonical USDC on Ethereum and mint USDC.e into Fantom. Deployed less than a month ago, about 4.4M USDC.e now exists on Fantom. The Fantom Foundation recognizes USDC.e as the canonical USDC on Fantom and seeks to ultimately collaborate with Circle to upgrade it to native USDC.

W

Wormhole’s governance token, W, is another case study on the implementation of NTT for a multichain token and represents the largest in-production utilization of NTT. W initially launched as an SPL on Solana and an ERC-20 on EVM chains. W currently has deployments across Solana, Ethereum, Arbitrum, Base, and Optimism. Wormhole recently announced staking for governance, which is initially only supported on EVM chains until the DAO’s MultiGov system extends to Solana. Wormhole built MultiGov in collaboration with Tally and Scopelift, and it will support several EVM chains, Solana, and other chains or runtimes in the future. For the initial EVM-based governance delegations, NTT data shows over 100M W tokens have been locked on Solana and released on EVM chains through NTT. This scenario presents a perfect use case for a multichain token deployment utilizing NTT.

Risks

Wormhole’s NTT gives integrators a high degree of flexibility to append additional verification schemes, which reduces the reliance on Wormhole Guardians and the Wormhole relayer network for settling crosschain token transfers. While expanding the requirements for attestation schemes can improve security, it can also raise the operational threshold to maintain liveness.

Wormhole’s Guardian network is operated by publicly-identified, professional entities with their reputation at stake. While Guardians could theoretically censor transactions, 7 Guardians would need to collude to inhibit reaching the quorum, which is a difficult threshold to reach. As such, Guardian misbehavior to reduce users’ welfare is negligible. Additionally, all Guardians are operated by a legal entity, which may face repercussions for malicious behavior. The liveness of standard NTT workflows relies on the uptime of Guardians, and, aside from receiving the W token airdrop, there are no in-protocol mechanisms (e.g. fees, emissions, bonding, or slashing) to enforce or incentivize Guardian performance. While users and integrators make this trust assumption, Guardians have maintained the necessary 13/19 uptime threshold consistently over the past 4 years.

While standard NTT workflows require Guardian network uptime, here introduces an advantage of custom NTT workflows. Integrators can articulate and define their own custom attestation schemes, independent of the Guardian network, to eliminate this dependency. An additional risk, though, is that the customization of NTT workflows can open up complexity to integrators. For custom workflows, the integrator may configure deployments of the NTT Manager, Transceiver, or any custom verification schemes outside of Wormhole’s audited standard implementations. Integrator deployments of these custom components may contain vulnerabilities. To address this, the Wormhole Contributors proactively collaborate with integrators on their configurations and work to have custom transceivers safely audited for the use of other protocols. 

Uniswap’s Bridge Assessment Report found Wormhole superior to the several other interoperability competitors examined, and amongst this cohort, Wormhole and Axelar were the only two protocols approved for use by the Uniswap DAO. The assessment noted the “significant improvements made to their DevSecOps practices” following the 2022 exploit of 120k WETH. Wormhole has one of the most generous bug bounty programs, offering white hats 10% of the extractable value, up to $5M, for identifying potential vulnerabilities. Wormhole is entirely open sourced and has undergone 21 audits, with more underway.

Regarding the proliferation of NTT, while there is substantial evidence to support the outlook of a multichain future, not all tokens may have a requirement to become multichain. While there is clear evidence to support the multichain proliferation of assets like stablecoins, LSTs, and LRTs, there may be less of a need to integrate NTT functions for single-chain application tokens. Additionally, utilization of Wormhole’s NTT may face competition from alternatives like LayerZero’s Omnichain Fungible Token (OFT) standard.

Final Thoughts

The NTT framework offers integrators a leading solution to deploy canonical versions of their tokens across multiple differentiated blockchains, while simultaneously allowing for a high degree of native interoperability between those deployments. This framework further deprecates the need for legacy lock-and-mint token transfer models. The standard and custom workflows allow integrators to maintain control and authority over their multichain token deployments. 

While the standard NTT workflows may introduce dependencies on Guardians and relayers, custom workflows allow integrators to configure verification and attestation schemes that eliminate these constraints, add security, and improve redundancy. In production, the W token represents a great case study on the use cases of a multichain token deployment with NTT. Broadly, NTT offers integrators with a viable framework for the multichain expansion and utilization of their native tokens.

This research report has been funded by the Wormhole Foundation. By providing this disclosure, we aim to ensure that the research reported in this document is conducted with objectivity and transparency. Blockworks Research makes the following disclosures: 1) Research Funding: The research reported in this document has been funded by Wormhole Foundation. The sponsor may have input on the content of the report, but Blockworks Research maintains editorial control over the final report to retain data accuracy and objectivity. All published reports by Blockworks Research are reviewed by internal independent parties to prevent bias. 2) Researchers submit financial conflict of interest (FCOI) disclosures on a monthly basis that are reviewed by appropriate internal parties. Readers are advised to conduct their own independent research and seek the advice of a qualified financial advisor before making any investment decisions.