Index

General Information
Part A: Information about the offeror or the person seeking admission to trading
Part B: Information about the issuer, if different from the offeror or person seeking admission to trading
Part C: Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
Part D: Information about the crypto-asset project
Part E: Information about the offer to the public of crypto-assets or their admission to trading
Part F: Information about the crypto-assets
Part G: Information on the rights and obligations attached to the crypto-assets
Part H: Information on the underlying technology
Part I: Information on the risks
Part J: Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts

2026-06-01

This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union.
The operator of the trading platform of the crypto-asset is solely responsible for the content of this crypto-asset white paper.

This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 of the European Parliament and of the Council and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import.

The crypto-asset referred to in this crypto-asset white paper may lose its value in part or in full, may not always be transferable and may not be liquid.

False

The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council or the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council.

Warning
This summary should be read as an introduction to the crypto-asset white paper. The prospective holder should base any decision to purchase this crypto-asset on the content of the crypto-asset white paper as a whole and not on the summary alone. The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments and any such offer or solicitation can be made only by means of a prospectus or other documents pursuant to the applicable national law.
This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council or any other offer document pursuant to Union or national law.

W is the native crypto-asset of the Wormhole platform. Wormhole is an open-source message-passing protocol and interoperability platform that enables communication between blockchains and supports the transfer of assets, data and governance actions across supported networks. W has a capped maximum supply of 10,000,000,000, and native ERC-20 and Solana SPL formats using Wormhole’s Native Token Transfers standard.

W holders may hold and transfer W where technically supported and may participate in staking for governance and delegating voting power. Wormhole’s token-based governance may influence matters including adding or removing blockchain connections, smart-contract upgrades, fee adjustments, Guardian expansion, rate limits, and token utility and design. Staking for governance is managed on-chain using smart contracts.

Holders may delegate voting power to delegates, change their delegate at any time, and unstake by choosing themselves as delegate. Staking for governance does not transfer ownership of the W tokens, subject to any applicable contractual lock-up periods.

Not applicable

The token has been admitted to trading to the trading platform operated by Bitstamp Europe S.A. on its own initiative.

TRUE

Wormhole Foundation

Based on publicly available official materials, the Wormhole Foundation appears to be the entity associated with the governance, treasury and ecosystem functions of the W crypto-asset and the Wormhole ecosystem. However, a legal identifiable issuer for W token has not been expressly identified in official public sources relating to the W.

K575

C/O Highvern Cayman Limited, Elgin Court, Elgin Avenue, PO Box 448, Grand Cayman, George Town

KY1-1106

2nd Floor, Elgin Court, Elgin Avenue, PO Box 448, Grand Cayman, George Town

KY1-1106

2019-01-10

2549004N48EJRKKH4724

BE-386067

Not applicable as LEI is provided in B.7.

The Wormhole Foundation supports the research, development and growth of open-source and decentralised blockchain interoperability technologies. The Foundation supports the development of Wormhole, an interoperability platform designed to enable secure communication, messaging and transfer functionality between supported blockchain networks.

The Foundation’s activities include supporting the development and maintenance of decentralised interoperability infrastructure and related open-source technologies; supporting teams building products and applications within the Wormhole ecosystem; administering grants, research initiatives and ecosystem programs; supporting community participation and ecosystem growth; and promoting the development of secure, open-source and decentralised technologies intended to facilitate interoperability across Web3 networks.

Not applicable

Bitstamp Europe S.A.

5GGB

40, avenue Monterey, L-2163, Grand Duchy of Luxembourg

LU-LU

40, avenue Monterey, L-2163, Grand Duchy of Luxembourg

LU-LU

2015-05-19

549300XIBGTJ0PLIEO72

Bitstamp Europe S.A. is registered with the Luxembourg Trade and Companies Register under the number B196856.

Robinhood Markets, Inc with its registered office at 85 Willow Road, Menlo Park, California 94025, USA.

Bitstamp Europe S.A., acting in its capacity as a crypto-asset service provider (CASP) and operator of a trading platform, has prepared this crypto-asset white paper to support the admission to trading of the crypto-asset on its platform and to provide users with the information required under Regulation (EU) 2023/1114 (MiCA).

Bitstamp Europe S.A. is a Crypto-Asset Service Provider authorised with the CSSF under the number N00000003 to provide the following crypto-asset services:

• providing custody and administration of crypto-assets on behalf of clients;
• operation of a trading platform for crypto-assets;
• exchange of crypto-assets for funds;
• exchange of crypto-assets for other crypto-assets;
• execution of orders for crypto-assets on behalf of clients;
• reception and transmission of orders for crypto-assets on behalf of clients; and
• providing transfer services for crypto-assets on behalf of clients.

Bitstamp Europe S.A. is a payment institution authorised by the CSSF under number Z00000012 to provide the following payment services:

3.a) execution of direct debits, including one-off direct debits,

3.b) execution of payment transactions through a payment card or a similar device,

3.c) execution of credit transfers, including standing orders and

6.) money remittance.

Bitstamp Europe S.A. has notified the cross-border provision of payment services and of crypto-asset services in all EU and EEA member states.

Bitstamp has admitted the asset to which this white paper relates to, to trading on its own initiative on its trading platform.

Robinhood Markets, Inc. is the parent holding company of the Robinhood group.

MiCA Crypto Alliance Limited

MiCA Crypto Alliance Limited was mandated to assist in the white paper preparation by Bitstamp Europe S.A. Bitstamp Europe S.A. retains the role of person seeking admission to trading.

Wormhole

W

W

Wormhole is an open-source blockchain interoperability project and protocol designed to enable communication, messaging, governance actions and transfer functionality across supported blockchain networks. Wormhole facilitates interoperability between blockchains by enabling applications, institutions and users to transmit data, assets and messages across multiple distributed ledger networks through a decentralised interoperability protocol.

The Wormhole ecosystem includes interoperability products and infrastructure such as cross-chain messaging, Native Token Transfers (NTT), Wrapped Token Transfers (WTT), Wormhole Connect, Queries, MultiGov, settlement infrastructure, software development kits (“SDKs”), APIs and developer tooling. Wormhole supports communication and interoperability across multiple blockchain networks, including Ethereum, Solana and various Layer 2 and other supported distributed ledger networks.

The Wormhole ecosystem consists of several core protocol and infrastructure components designed to support blockchain interoperability, cross-chain communication and multichain application development.

Wormhole Messaging is the core interoperability layer of the Wormhole protocol. It enables applications, smart contracts and protocols on one blockchain network to send verified messages, instructions and data to applications and smart contracts on other supported blockchain networks. Messages generated on a source blockchain are verified by the Guardian network and transmitted to destination blockchains through Wormhole interoperability infrastructure. Wormhole Messaging supports use cases including decentralised application interoperability, governance communication, token transfers, decentralised finance infrastructure and cross-chain data transmission.

The Guardian network is a decentralised network of independent node operators responsible for observing, validating and attesting to Wormhole messages and protocol events across supported blockchain networks. Guardians monitor source-chain events and collectively produce signed attestations known as Verifiable Action Approvals (“VAAs”). A VAA is accepted only after a required Guardian quorum signs the message. Destination-chain contracts may then verify the VAA and execute the corresponding action. The Guardian network forms a core security component of the Wormhole protocol and is intended to reduce the risk of invalid or unauthorised cross-chain message execution.

Wormhole Core Contracts are deployed smart contracts responsible for processing Wormhole messages and verifying Guardian attestations on supported blockchain networks. These contracts validate VAAs and enable applications and protocols to interact with Wormhole infrastructure across multiple distributed ledger technologies.

NTT enables supported assets to move between blockchain networks while preserving native token characteristics. The W crypto-asset itself uses Wormhole’s NTT framework to support multichain native functionality between Solana, Ethereum and supported Layer 2 networks.

WTT is Wormhole’s wrapped token transfer framework, designed to facilitate the transfer of assets across multiple blockchain networks. The mechanism operates by locking assets on one network and minting corresponding wrapped representations on another, thereby supporting cross-chain interoperability and multichain application functionality.

Wormhole Settlement is a multichain transfer and execution framework that enables users to define intended cross-chain actions, such as token transfers or swaps, while execution is performed by competing off-chain solvers. The framework is designed to support efficient and reliable execution, with the Mayan Swift routing mechanism utilising low-latency solver auctions to facilitate rapid asset transfers with reduced slippage, while maintaining on-chain verifiability through the Wormhole messaging infrastructure.

MultiGov enables governance-related instructions and proposals to be transmitted across supported blockchain networks using Wormhole interoperability infrastructure.

FALSE

Not applicable

Past milestones

Since its launch in 2020, the Wormhole ecosystem has undergone multiple stages of development and expansion across several product eras. During Era1 (2020–2021), Wormhole introduced an initial interoperability solution connecting Solana and Ethereum through a token bridge implementation. This initial launch included a user interface and an initial Guardian network composed of 19 members.

During Era2 (2021–2024), Wormhole expanded into a broader interoperability platform for developers and applications. The project introduced arbitrary message passing functionality to facilitate transmission of data across more than 30 blockchain networks, together with additional infrastructure including NTT, Wormhole Connect and Portal. During this period, the Guardian network continued to develop and major blockchain protocols and decentralised applications integrated Wormhole infrastructure for governance, oracle and asset-transfer use cases.

In September 2024, Wormhole announced Era3 of the project roadmap during Solana Breakpoint. Wormhole describes this phase as introducing significant user experience and infrastructure upgrades, including native swaps, fast transfers, SDK, and updated versions of Portal, Wormhole Connect and Wormholescan. Wormhole contributors also launched “Wormhole for Institutions”, an interoperability offering intended for institutional and enterprise users.

Institutional participants including Securitise, BlackRock and Apollo adopted Wormhole interoperability infrastructure in connection with multichain tokenised asset and fund-related use cases. Additional ecosystem integrations referenced by Wormhole include collaborations with Flow Traders, Google Cloud, AMD and Borderless Capital.

Wormhole has also expanded interoperability infrastructure connected with stablecoins and tokenised assets. Projects including Sky (formerly MakerDAO), Agora, M^0, DeepBlue and Transfero integrated Wormhole’s Native Token Transfers framework to support multichain functionality and interoperability for digital assets and stablecoins across supported blockchain networks.

In February 2025, Wormhole launched Wormhole Settlement, described as interoperability infrastructure intended to facilitate fast multichain transfers and cross-chain settlement functionality.

In September 2025, “Wormhole 2.0” was announced; an upgrade described as a further stage in the development of the Wormhole ecosystem, governance infrastructure and W token framework. The announcement included plans relating to a strategic reserve mechanism, staking and governance incentives, and modifications to the token unlock schedule.

The upgrade proposed “Wormhole Reserve” as a strategic reserve of W intended to support the long-term growth of the Wormhole ecosystem. The materials state that on-chain and off-chain protocol value and revenues generated across Wormhole infrastructure, including Wormhole, Portal and ecosystem applications, are intended to contribute to the reserve. The announcement further states that increasing adoption and ecosystem activity may result in additional W being accumulated and locked within the reserve framework.

The Wormhole 2.0 announcement also describes planned governance staking incentives for W holders participating in governance activities. Staking rewards are intended to be variable and connected to governance participation and ecosystem activity. Wormhole states that rewards may derive from existing token supply allocations and protocol revenues and that no additional inflation is being introduced to W, with the total token supply remaining capped at 10,000,000,000 W. The rewards are variable, not guaranteed, may change or cease at any time, are emissions rather than interest, and do not confer rights to revenues or payments.

The release schedule was designed during an earlier period of market practice and that the revised schedule is intended to support greater long-term alignment and a more gradual token release structure. The revised framework replaces certain annual cliff unlocks with bi-weekly unlock schedules beginning in October 2025 for several allocation categories, including Guardian Nodes, Community and Launch, Ecosystem and Incubation, and Strategic Network Participants.

The Foundation Treasury allocation will continue to follow its original release framework and that Core Contributor allocations remain subject to contractual restrictions and time-lock arrangements notwithstanding technical release adjustments within the revised unlocking structure. The revised schedule is described as intended to reduce concentrated market release events and support a more gradual and predictable token distribution process over time.

Future milestones

The next stage of the Wormhole roadmap, referred to in official materials as Era4, is intended to further expand decentralisation, governance infrastructure and interoperability functionality. Planned developments include MultiGov, a multichain governance system intended to support governance proposal creation, voting and execution across Ethereum, Solana and supported Layer 2 networks.

Additional planned developments described by Wormhole include upgrades to the Portal user interface and user experience, expansion of ecosystem incentive programs and continued development of interoperability infrastructure and multichain application tooling.

The W crypto-asset has the ticker symbol “W” and a capped maximum supply of 10,000,000,000 W. The initial circulating supply at the TGE was 1,800,000,000 W.

82% of the total W supply was initially locked and is scheduled to unlock over a 4-year period in accordance with the applicable token release schedule.

The W supply is allocated across 6 principal categories. Guardian nodes were allocated 5.1% of the total supply, representing 510,000,000 W. Wormhole states that the Guardian Network provides the primary verification mechanism for messages transmitted through the Wormhole protocol and that Guardians operate full nodes for supported blockchain networks connected to Wormhole. None of the Guardian allocation was unlocked at the TGE and such tokens remain subject to the token release schedule.

The community and launch allocation represents 17% of the total supply, corresponding to 1,700,000,000 W. 11% of the total supply was unlocked at the TGE for distribution during the initial launch phases, including the airdrop and related launch activities, while the remaining portion unlocks in accordance with the release schedule.

Core contributors were allocated 12% of the total supply, corresponding to 1,200,000,000 W. Wormhole describes this allocation as reserved for contributing organisations involved in security, engineering, infrastructure, operations, growth and development activities connected with the Wormhole ecosystem. None of this allocation was unlocked at the TGE.

The ecosystem and incubation allocation represents 31% of the total supply, corresponding to 3,100,000,000 W. Wormhole states that this allocation supports strategic contributors, ecosystem organisations, developer initiatives and ecosystem growth activities. A portion of this allocation was unlocked at the TGE, while the remainder is subject to the release schedule.

Strategic network participants were allocated 11.6% of the supply, corresponding to 1,160,000,000 W. According to Wormhole, this allocation supports long-term participation in the network by strategic participants, including builders, technical partners and other ecosystem participants. None of these tokens were unlocked at the TGE.

The Wormhole Foundation treasury allocation represents 23.3% of the total supply, corresponding to 2,330,000,000 W. The reserves are intended to support interoperability research, grants, ecosystem development, developer support, operational expenses and continued network development. A limited portion of this allocation was unlocked at the TGE, while the remaining tokens are subject to linear unlocking under the token release schedule.

Not applicable

By admitting the W asset to trading, holders of the token will gain transparent price discovery and improved liquidity. This enables the project’s community and ecosystem participants to more easily enter and exit positions, supporting a dynamic and efficient market.

When a client purchases a token on the Bitstamp Europe S.A.'s trading platform, the crypto-asset will be credited to their Bitstamp account. If a client wants to hold the token in their own wallet, they will need to (i) provide an external blockchain wallet address, where the crypto-assets will be sent if a withdrawal is initiated and (ii) satisfy all other requirements applicable to a withdrawal in line with the Regulation (EU) 2023/1113 of the European Parliament and of the Council of 31 May 2023 on information accompanying transfers of funds and certain crypto-assets.

When a client purchases a token on the Bitstamp Europe S.A.'s trading platform, the crypto-asset will be credited to their Bitstamp account and a client does not need to fulfill any other technical requirement to hold the crypto-assets on their Bitstamp account, apart from have either a computer or phone with an internet connection and appropriate software in order to interact with the Bitstamp services.

Bitstamp Europe S.A.

BESA

Investors can access the trading platform through https://www.bitstamp.net or via the Bitstamp applications.

There are no costs involved in creating an account on the trading platform, however trading fees and other costs apply in accordance with the fee schedule available at https://www.bitstamp.net/fee-schedule.

Not applicable

There are no conflicts of interest arising at the moment of writing the white paper in relation to the offer or admission to trading. Bitstamp Group has a strict Code of Conduct and Trading Policy in place. They both mitigate the possibility of conflicts of interest.

In accordance with the Code of Conduct all officers, directors, employees, agents, representatives, contractors and consultants (and other persons, regardless of job or position), are required to report any situation where there is the potential for conflict of interest between their interests and interests of Bitstamp. The Trading Policy that is in place within the Bitstamp Group prohibits all forms of market manipulation and has been designed to prevent insider trading.

Not applicable, as this point pertains to an 'offer to the public', whereas this white paper relates to admission to trading.

Not applicable, as this point pertains to an 'offer to the public', whereas this white paper relates to admission to trading.

Crypto-assets other than asset-referenced tokens or e-money tokens

W is a crypto-asset designed to support governance participation, staking-related activities and ecosystem growth across supported blockchain networks. W is implemented as a native multichain asset using Wormhole’s NTT framework and exists in native ERC-20 and Solana SPL formats.

W may be used in connection with governance mechanisms within the Wormhole ecosystem. W holders may participate in governance processes through staking-for-governance arrangements and delegation mechanisms. Governance participation may include proposing, voting on or influencing matters relating to the Wormhole ecosystem, including supported blockchain connections, protocol upgrades, fee parameters, governance systems, Guardian-related matters, interoperability infrastructure and ecosystem development initiatives.

The Wormhole ecosystem also supports multichain governance functionality through MultiGov infrastructure, which is intended to enable governance proposal creation, voting and execution across multiple supported blockchain networks. Wormhole Governance infrastructure is intended to enable W holders to participate in governance decisions affecting the Wormhole ecosystem and related protocol infrastructure.

Not applicable

W is the native crypto-asset of the Wormhole platform. Wormhole is an open-source message-passing protocol and interoperability platform that enables communication between blockchains and supports the transfer of assets, data and governance actions across supported networks. W has a capped maximum supply of 10,000,000,000, and native ERC-20 and Solana SPL formats using Wormhole’s Native Token Transfers standard.

W holders may hold and transfer W where technically supported and may participate in staking for governance and delegating voting power. Wormhole’s token-based governance may influence matters including adding or removing blockchain connections, smart-contract upgrades, fee adjustments, Guardian expansion, rate limits, and token utility and design. Staking for governance is managed on-chain using smart contracts. Holders may delegate voting power to delegates, change their delegate at any time, and unstake by choosing themselves as delegate. Staking for governance does not transfer ownership of the W tokens, subject to any applicable contractual lock-up periods.

N/A as DTI is provided in F.13

https://wormhole.com

2026-07-02

2026-07-01

Not applicable

English

GDX74SST8, L2BKTJ5WW, XR2ZNHXH7, TDWLL16VZ

25J14XV4F

FALSE

TRUE

TRUE

Not applicable as the W crypto-asset holders do not acquire any ownership, equity, profit participation, repayment, or redemption rights against any natural or legal person associated with the Wormhole project. Holding W does not give rise to contractual claims or entitlements against any natural or legal person.

As reflected in the official Wormhole governance materials and documentation available through the Wormhole ecosystem websites and governance interfaces, including https://wormhole.com/blog/stake-for-governance-is-now-live-for-w-token-holders and https://www.tally.xyz/gov/wormhole, at the time of this white paper, W holders are granted governance-related functionalities within the Wormhole ecosystem, which are further described as crypto-asset functionalities in Section F.2.

Not applicable as the asset confers no ownership or financial claims and does not impose any legal obligations.

Not applicable as the asset confers no ownership or financial claims and does not impose any legal obligations.

Not applicable

FALSE

Not applicable

Not applicable

TRUE

Not applicable

Not applicable

FALSE

Not applicable

FALSE

Not applicable

FALSE

Not applicable

There is no written legal agreement between the issuer and the crypto asset-holder that sets out the laws that govern the legal relationship between those two parties. In the absence of such an agreement, the laws that govern that relationship will depend on the location of the issuer and the given crypto asset-holder and characteristic performance of the legal relationship, and any agreed intention of the issuer and crypto asset-holder.

There is no written legal agreement between the issuer and the crypto asset-holder that sets out which jurisdiction's courts will have authority to deal with a dispute between the crypto asset-holder and the issuer. In the absence of such an agreement, the laws of the competent court will depend on the location of the issuer and the given crypto asset-holder and characteristic performance of the legal relationship, and any agreed intention of the issuer and crypto asset-holder.

Not applicable as DTI is provided in F.13

Networking and message transport

Wormhole's cross-chain messaging infrastructure underpins all multichain W transfers. When a transfer is initiated, the source-chain NTT Manager publishes a message through the on-chain Wormhole Core Contract, which emits the message in transaction logs. The Guardian Network — a peer-to-peer network of 19 validator nodes — independently observes these logs. Each Guardian runs a full node on every blockchain connected to Wormhole rather than a light node, ensuring direct and independent observation of source-chain state. Once 13 of the 19 Guardians have independently signed the same message, a VAA is produced.

Wormhole supports a Delegated Guardian Set model for certain chains, under which a designated subset of Guardians performs direct on-chain observation. For delegated chains, the delegate quorum threshold must be reached before canonical Guardians contribute their signatures; the final VAA signing requirement of 13 of 19 canonical Guardians is preserved in all cases. A Spy service can subscribe to messages within the Guardian Network and forward them. Verified VAAs reach the destination chain either through off-chain relayers or through the Executor framework — an open marketplace in which relay providers compete on a request-and-quote basis for permissionless message delivery.

Users on EVM chains sign transactions and submit them via the standard Ethereum JSON-RPC method. On Base, a Reth-based sequencer accepts transactions from its mempool, orders them into Layer 2 blocks, and posts sufficient batch data to Ethereum to allow independent reconstruction of those blocks. Batches are posted to Ethereum as calldata or EIP-4844 blobs depending on network conditions; the sequencer dynamically selects the more cost-effective method. On Arbitrum One, the Nitro sequencer broadcasts an ordered real-time feed providing soft finality and groups transactions into batches compressed using the Brotli algorithm, posting them to the parent chain via blob transactions under EIP-4844 or calldata as a fallback. On OP Mainnet, transaction progression moves from Flashblock preconfirmation (~250 ms) through Layer 2 block inclusion (~2 s), Layer 1 batch inclusion (~7 min), and Layer 1 batch finality (~20 min). These chain-level propagation and ordering mechanisms govern how ERC-20 W transactions are sequenced and finalised on each EVM network.

Serialisation

On Solana, transactions are atomic and include one or more instructions, account signatures, and a recent blockhash. Each signer provides a single 64-byte Ed25519 signature; the maximum transaction size is 1,232 bytes. All instructions in a transaction either succeed together or the transaction fails, with all state changes reverted and the fee still charged.

On Ethereum and EVM networks, W conforms to the ERC-20 token standard, which defines a smart-contract API covering token transfers, balance queries, total supply queries, and third-party spending approvals. Transfer and Approval events are emitted on state changes. Base and OP Stack transaction data additionally use RLP-encoded Ethereum-style serialisation in the Layer 1 fee calculation context.

Within the NTT framework, cross-chain transfers produce structured messages containing transfer details: recipient chain identifier, recipient address, and transfer amount. The source NTT Manager creates this message and forwards it to enabled transceivers. The destination NTT Manager waits until the configured attestation threshold is met before executing the destination transfer.

Cryptography and key formats

W transactions on EVM chains rely on ECDSA signatures over the secp256k1 curve. Ethereum-style account addresses are derived from secp256k1 public keys through Keccak-256 hashing. On Solana, accounts use Ed25519 key pairs, and each transaction signature is 64 bytes.

Wormhole message validity rests on VAAs signed by a Guardian supermajority. A VAA is valid when 13 of the 19 canonical Guardians have independently signed the same message. Target-chain Core Contracts verify both the Guardian signatures and message format before permitting any cross-chain operation. Where Delegated Guardian Sets are active for a particular chain, the delegate quorum threshold is enforced before canonical Guardians sign, without reducing the canonical 13-of-19 requirement. Ethereum validators use BLS12-381 signatures for block attestations within the proof-of-stake consensus layer.

Solana's Proof of History is a high-frequency verifiable delay function that applies a sequential pre-image-resistant hash process — using each output as the next input — to produce a cryptographically verifiable time record that can be verified in parallel and establishes real-time ordering across the network.

Ledger

W is deployed as an SPL token on Solana and as an ERC-20 token on Ethereum mainnet, Arbitrum One, Optimism, and Base. On Solana, W is held in Associated Token Accounts at deterministic addresses derived from the wallet address and the W mint account. The mint account stores total supply, decimal precision, mint authority, and freeze authority; individual token accounts record per-holder balances. On Ethereum, Arbitrum One, Optimism, and Base, W balances are stored in ERC-20 smart-contract state, mapping holder addresses to balances and exposing standard transfer, approval, and supply query functions.

NTT contracts maintain minimal additional on-chain state to route cross-chain transfers safely and prevent replay. This state comprises: message attestations, recording which transceivers have confirmed each message and enforcing the configured M-of-N threshold; peer registrations, mapping each remote chain to its associated NTT Manager and token decimal configuration; rate-limiting data, covering inbound and outbound throughput caps and transfer queues; and a transceiver registry, maintaining the list and bitmap index of registered and enabled transceivers.

Execution

On Solana, W execution uses SPL token program instructions: minting tokens to a token account, transferring between accounts for the same mint, approving and revoking delegate authorities, and burning tokens to reduce total supply. On EVM chains, ERC-20 execution occurs through the standard smart-contract interface.

Cross-chain transfers execute through the NTT Manager and transceiver layer. On the source chain, the NTT Manager either locks tokens (locking mode) or burns them (burning mode). The manager applies outbound rate-limit checks, emits a transfer message to enabled transceivers, and transceivers carry the message to the destination chain. The destination NTT Manager collects attestations until the configured threshold is met, applies inbound rate-limit checks, and then either releases locked tokens or mints new tokens to the recipient.

Arbitrum One uses the Nitro technology stack. Transactions enter the Inbox, the State Transition Function processes them deterministically using a Geth-core EVM execution layer with ArbOS handling cross-chain messaging, fee management, and gas pricing above it. On Base, execution uses a Reth-based engine extending the EVM with rollup-specific predeploys and precompiles for fee distribution and L1 block attribute injection. On OP Mainnet, EVM-equivalent execution applies OP Stack fee mechanics.

Token standards

W uses the SPL token standard on Solana and ERC-20 on EVM chains. NTT supports ERC-20 tokens on EVM chains, including ERC-20 Burnable variants required in burning-mode deployments, and fungible SPL tokens on SVM chains. Non-fungible tokens and the ERC-1155 multi-token standard are not supported by NTT. The NTT Manager uses the IERC20 interface and OpenZeppelin's SafeERC20 library for ERC-20 interactions.

Approvals and access controls

ERC-20 approval functionality allows a W holder to authorise a third-party address to spend a defined amount from the holder's balance. SPL token functionality on Solana provides for the approval of a delegate authority to transfer or burn a limited amount and the revocation of that authority.

At the transfer layer, NTT provides configurable ownership and access controls, permissioned transceiver management, and per-chain rate limits. These controls determine which addresses may call protected functions, which transceivers are accepted as valid, and how much W may move through the system within any configured window.

External interfaces

W on EVM chains is accessible through standard Ethereum JSON-RPC interfaces. W on Solana is accessible through Solana RPC endpoints using SPL token instructions. Cross-chain transfer status and VAA data are retrievable through the Wormholescan API and explorer at wormholescan.io. Wormhole also provides a REST API for retrieving VAA details and Guardian Network status, and a Spy service for subscribing to messages within the Guardian Network.

Implementation and architecture

W launched as a native Solana SPL token; ERC-20 deployments on Ethereum, Arbitrum One, Optimism, and Base were subsequently enabled through Wormhole's Native Token Transfers framework. NTT is not a separate token standard; it is the transfer architecture that allows native token representations to move across supported chains without wrapped-asset intermediaries.

The NTT architecture comprises two core components. Managers oversee the transfer process: they lock or burn tokens on the source chain, apply rate-limit checks, create transfer messages and forward them to enabled transceivers, verify message authenticity through transceiver attestations, and release or mint tokens on the destination once the attestation threshold is met. Each NTT Manager is assigned to a specific token but can operate across multiple chains. Transceivers handle cross-chain messaging: they receive instructions from the manager, quote delivery fees, transmit messages to the destination, and verify delivery. The default Wormhole Transceiver uses Guardian VAA verification. Custom transceivers with alternative verification backends are also supported, and protocols may configure flexible attestation thresholds — for example, 2-of-3 or 3-of-5 — across verifier combinations.

The Wormhole protocol layer underlies all cross-chain messaging. The Core Contract logs each message with emitter and sequence identifiers. Guardians observe the log and produce a signed VAA once the 13-of-19 threshold is reached. The VAA is delivered to the destination chain by a relayer or through the Executor marketplace, and the destination Core Contract verifies it before any execution proceeds.

Runtime environments

W operates across five runtime environments. On Solana, SPL token instructions execute within the Solana token program. On Ethereum, W transactions execute through the EVM. On Arbitrum One, ERC-20 execution occurs within Nitro's State Transition Function, with Geth handling EVM execution and ArbOS managing Layer 2 specifics including cross-chain messaging and fee accounting. On Base, execution uses a Reth-based engine, exposing the standard Ethereum JSON-RPC API and extending the EVM with rollup-specific functionality through predeploys and precompiles. On OP Mainnet, EVM-equivalent execution applies OP Stack fee mechanics.

NTT deployments operate in either locking or burning mode, set at deployment and consistent per chain. In locking mode, tokens are locked on the source chain and released on the destination; in burning mode, tokens are burned on the source and minted on the destination.

Key management and wallet access

W on EVM chains is held in accounts derived from ECDSA secp256k1 key pairs. Private keys generate Ethereum addresses through secp256k1 public key derivation followed by Keccak-256 hashing. Standard EVM-compatible wallets supporting the ERC-20 interface provide W access on EVM chains. On Solana, W is held in SPL Associated Token Accounts controlled by Ed25519 key pairs. Standard Solana wallets provide access through the SPL token account model.

Dependencies

W depends on the ERC-20 and SPL token standards, the Wormhole NTT framework, Wormhole Core Contracts, and the Guardian Network. For ERC-20 interactions, NTT uses OpenZeppelin's SafeERC20 library through the IERC20 interface. For SPL interactions, the Solana SPL token program provides the underlying instruction set. The Guardian Network's security additionally relies on the Global Accountant, which tracks W's total circulating supply across all chains and prevents transfers that would violate the supply invariant, and the Governor, which monitors chain-level inflows and outflows and can delay suspicious transfers.

Deployment

W is deployed natively on Solana, Ethereum mainnet, Arbitrum One, Optimism, and Base. On Solana, W exists at a dedicated SPL mint account. On EVM chains, W is deployed as an ERC-20 contract at a corresponding address on each network. Token contract addresses are publicly verifiable on Wormholescan and the block explorers of each supported chain.

W does not have a standalone consensus mechanism. Transactions involving W obtain ordering, execution, and finality through the consensus mechanism of the underlying chain on which the transaction is submitted. Cross-chain transfers additionally require Wormhole's Guardian attestation: 13 of 19 canonical Guardians must independently sign the same VAA before the destination chain executes the transfer.

On Ethereum, consensus is proof of stake. Validators deposit 32 ETH into the staking contract and are responsible for attesting to proposed blocks and, when selected, proposing blocks. Time is divided into 12-second slots and 32-slot epochs. One validator is randomly selected as block proposer for each slot, and committees of validators provide attestations using BLS12-381 signatures. Finality is established through checkpoint links: once validators representing at least two-thirds of total staked ETH agree on a checkpoint-epoch pair, all blocks within the earlier epoch are finalised. Reverting a finalised block would require destroying at least one-third of all staked ETH through slashing.

On Solana, the consensus mechanism is Tower BFT, a variant of Practical Byzantine Fault Tolerance adapted for Solana's architecture. Tower BFT uses stake-weighted validator voting to achieve finality and leverages Proof of History as a cryptographic clock. Proof of History is a high-frequency verifiable delay function that produces a sequential, cryptographically verifiable time record by applying each output as the next input in a continuous hash chain. This allows Tower BFT to enforce timeouts and ordering constraints without requiring validators to exchange timestamps, significantly reducing messaging overhead. Finality on Solana is achieved when a supermajority of stake-weighted votes confirms a block, with validators committing to lockout periods that increase exponentially with each subsequent vote.

Arbitrum One is an Optimistic Rollup that settles to Ethereum using the Nitro technology stack. The sequencer provides soft finality immediately upon inclusion in its real-time feed; hard finality occurs when transaction batches are posted to and confirmed on the Ethereum parent chain, at which point Arbitrum inherits Ethereum's proof-of-stake security.

On OP Mainnet, transaction finality progresses through four stages: Flashblock preconfirmation (~250 ms), Layer 2 block inclusion (~2 s), Layer 1 batch inclusion (~7 min), and Layer 1 batch finality (~20 min), reached when the Ethereum batch containing the transaction is older than two epochs or 64 Layer 1 blocks. Withdrawals from OP Mainnet to Ethereum require a separate 7-day settlement period to allow the Fault Proof system to function.

Base is an Ethereum rollup using the OP Stack. A single active sequencer accepts transactions, orders them, produces Flashblocks every 200 ms, and posts batches to Ethereum. Finality progresses through the same four staged model: Flashblock inclusion (~200 ms), Layer 2 block inclusion (~2 s), Layer 1 batch inclusion (~2 min), and Layer 1 batch finality (~20 min). Withdrawals from Base to Ethereum similarly carry a 7-day challenge window.

Network-level fees

All W transactions pay the fees of the chain on which they are executed. On Ethereum, each transaction pays a gas fee equal to the gas used multiplied by the gas price, denominated in ETH (commonly quoted in gwei). The fee comprises a base fee and a priority fee: the base fee is set by the protocol, increases or decreases by a maximum of 12.5% per block based on block fullness, and is burned; the priority fee is an optional tip paid to the validator. On Solana, every transaction pays a base fee of 5,000 lamports per signature and an optional prioritisation fee, both denominated in SOL. The base fee is split 50% burned and 50% paid to the validator; the prioritisation fee is paid entirely to the validator.

On Arbitrum One, fees have two components. A child-chain component covers computation and storage within the Nitro execution environment, calculated using EVM-compatible gas mechanics. A parent-chain component accounts for the estimated cost of posting batch data to Ethereum; this is determined by approximating each transaction's compressed footprint in data units and applying an adaptive fee per data unit that adjusts over time to align collected fees with actual batch posting costs.

On OP Mainnet, the total transaction fee comprises an execution gas fee, a Layer 1 data fee, and, following the Isthmus upgrade, an operator fee. The execution gas fee follows the EIP-1559 model. The Layer 1 data fee accounts for publishing transaction data to Ethereum, ensuring it is available for independent node execution. The operator fee is added after Isthmus as a configurable per-transaction surcharge.

On Base, each transaction incurs a Layer 2 execution fee and a Layer 1 security fee. The Layer 2 fee uses the OP Stack implementation of EIP-1559 with an elasticity multiplier of 6 and a base fee change denominator of 125, allowing a maximum base fee change of 4% per block. A minimum base fee of 5,000,000 wei (0.005 gwei) was introduced with the Jovian upgrade. On Base, unlike Ethereum, the base fee is not burned but collected into a Base Fee Vault; priority fees flow to the Sequencer Fee Vault; and L1-cost fees flow to the L1 Fee Vault. The Layer 1 security fee estimates the cost of publishing transaction data to Ethereum and is calculated by the GasPriceOracle predeploy.

Protocol-level fees

No fixed transfer surcharge or percentage-based fee applies to W transfers through the NTT framework. Rate limits restrict throughput by chain and time period but do not constitute fees; transfers exceeding available capacity are queued or reverted depending on the deployment configuration.

Fee adjustment across Wormhole products is a governance domain of the Wormhole DAO. W holders may introduce or adjust protocol fees through governance proposals executed via MultiGov.

Validator and network incentives

Guardian nodes are allocated 5.1% of the total W supply (510,000,000 W) in recognition of their role as the primary message verification mechanism for all messages passing through Wormhole. None of this allocation is unlocked at the token generation event; it vests in accordance with the published Token Release Schedule. Guardians do not receive per-transaction fee revenue from W NTT transfers; that revenue flows to the chain-level validators of each underlying network.

Ethereum validators receive priority tips from ERC-20 W transactions included in their blocks; the base fee is burned. Solana validators receive prioritisation fees and 50% of the base fee from W transactions on Solana. Arbitrum One, Base, and OP Mainnet each have sequencer economics that compensate for Layer 2 execution and Layer 1 data posting costs, distributed via chain-specific fee vault and batch-posting-cost mechanisms.

Governance of parameters

W holders exercise governance through MultiGov, with Ethereum as the hub chain and spoke contracts on supported EVM chains and Solana. W is staked through the Tally Governance Portal to accrue voting power. Staking for governance carries no token lockup and does not affect ownership; W may be unstaked and re-staked to change the delegated voting address at any time. Proposals are created, voted on, and executed on-chain. Governance domains include chain connection management, contract upgrades, fee adjustment, Guardian set changes, rate limit configuration, and token utility design.

Contract upgrades require a two-thirds supermajority of canonical Guardians. Governance actions originate within the Guardian Network, are signed by the requisite supermajority, and are submitted to ecosystem contracts for execution.

FALSE

TRUE

The record below covers audits of the NTT EVM and Solana implementations, MultiGov, and core Wormhole protocol components. All reports are published pursuant to Wormhole's policy of release following issue resolution. Complete findings, severity classifications, and remediation status are available in the published reports.

Cyfrin | April 2024 — EVM NTT

• Object: Security review of the EVM Native Token Transfers implementation.
• Results: Findings documented; report published in the NTT EVM audit directory and the Wormhole audit archive.
• Actions: Published following issue resolution. Full findings and remediation details are available at https://github.com/wormhole-foundation/native-token-transfers/tree/main/audits/evm.

Cantina | April 2024 — EVM NTT

• Object: Independent security review of the EVM Native Token Transfers implementation.
• Results: Findings documented; report published in the NTT EVM audit directory and the Wormhole audit archive.
• Actions: Published following issue resolution. Full findings and remediation detail are available at https://github.com/wormhole-foundation/native-token-transfers/tree/main/audits/evm.

Cyfrin | July 2024 — EVM NTT v1.1.0 Differential

• Object: Differential security review of changes introduced in EVM NTT version 1.1.0.
• Results: Findings documented; report published in the NTT EVM audit directory and the Wormhole audit archive.
• Actions: Published following issue resolution. Full findings and remediation details are available at https://github.com/wormhole-foundation/native-token-transfers/tree/main/audits/evm.

OtterSec | March 2024 — Solana NTT

• Object: Security review of the Solana Native Token Transfers implementation.
• Results: Findings documented; report published in the NTT Solana audit directory and the Wormhole audit archive.
• Actions: Published following issue resolution. Full findings and remediation details are available at https://github.com/wormhole-foundation/native-token-transfers/tree/main/audits/solana.

Neodyme | April 2024 — Solana NTT

• Object: Independent security review of the Solana Native Token Transfers implementation.
• Results: Findings documented; report published in the NTT Solana audit directory and the Wormhole audit archive.
• Actions: Published following issue resolution. Full findings and remediation details are available at https://github.com/wormhole-foundation/native-token-transfers/tree/main/audits/solana.

OtterSec | August 2024 — Solana NTT Token Extensions

• Object: Security review of the Solana NTT Token Extensions variant.
• Results: Findings documented; report published in the NTT Solana audit directory and the Wormhole audit archive.
• Actions: Published following issue resolution. Full findings and remediation details are available at https://github.com/wormhole-foundation/native-token-transfers/tree/main/audits/solana.

OtterSec | April 2025 — NTT v3

• Object: Security review of NTT version 3.
• Results: Findings documented; report published in the NTT Solana audit directory and the Wormhole audit archive.
• Actions: Published following issue resolution. Full findings and remediation details are available at https://github.com/wormhole-foundation/native-token-transfers/tree/main/audits/solana.

OtterSec | May 2025 — Solana NTT v3

• Object: Security review of the Solana-specific NTT v3 implementation.
• Results: Findings documented; report published in the NTT Solana audit directory and the Wormhole audit archive.
• Actions: Published following issue resolution. Full findings and remediation details are available at https://github.com/wormhole-foundation/native-token-transfers/tree/main/audits/solana.

Cyfrin, Sec3, Zellic, Sherlock | October 2024 – March 2025 — MultiGov

• Object: Security reviews of EVM MultiGov, EVM MultiGov v2, Solana MultiGov, and associated components comprising the W governance system.
• Results: Findings documented across multiple reports published in the Wormhole audit archive.
• Actions: Published following issue resolution. Full findings and remediation details are available at https://github.com/wormhole-foundation/wormhole-audits.

Multiple firms | 2022–2023 — Core protocol and chain-specific components

• Object: Reviews of core Wormhole protocol components and chain-specific deployments, conducted by Neodyme, Kudelski, CertiK, Runtime Verification, Trail of Bits, OtterSec, Hacken, and Zellic, including chain-specific coverage for Algorand, Aptos, Near, and Sui.
• Results: Reports covering the core protocol and chain-specific integrations published in the Wormhole audit archive.
• Actions: Published following issue resolution. Full findings and remediation details are available at https://github.com/wormhole-foundation/wormhole-audits.

Market volatility and liquidity

The market price of W may fluctuate significantly due to broader crypto-asset market conditions, trading-venue depth, liquidity fragmentation and project-specific developments. W is traded natively across five chains; Solana, Ethereum, Arbitrum One, Optimism, and Base; which means available liquidity is distributed rather than concentrated at a single venue. Large or rapidly sequenced transactions may widen spreads, increase slippage or affect execution quality, particularly where cross-chain liquidity is thin or routing is constrained.

Market abuse and manipulation

W trades across centralised and decentralised venues without the benefit of a unified surveillance framework. Practices including wash trading, spoofing, and coordinated pump-and-dump activity may occur across platforms, and the fragmented, multichain nature of W's deployment makes it more difficult to detect or attribute such conduct. These risks are amplified where volume or liquidity is limited on any given venue or chain.

Listing, access and service-continuity risk

Access to W may be affected by jurisdictional restrictions, third-party interface outages or changes to supported networks. Wormhole has previously announced disconnections, Guardian withdrawals and portal delistings affecting certain chains, accompanied by grace periods, and further changes of this kind may occur. The Standard Relayer service was deprecated as of March 2026 and replaced by the Executor framework; applications and integrations that had not migrated were directly affected. Third-party services through which W is accessed operate under their own terms and conditions and may be modified or withdrawn at any time.

Irreversibility of transactions

W transfers and on-chain governance actions cannot be reversed at protocol level once confirmed. There is no mechanism within Wormhole or its underlying chains to recover assets transferred in error or as a result of fraudulent or coerced instruction. Recovery depends entirely on private-key control and off-chain legal remedies.

Cross-chain transfer delay and rate-limit risk

Completion of a cross-chain W transfer depends on source-chain finality, the Wormhole consistency level applied to that chain, the availability of relay providers and applicable NTT rate limits. Transfers that exceed configured outbound or inbound capacity are placed in a queue until the applicable rate-limit window clears. Across the five supported chains, finality parameters differ materially;from sub-second soft finality on Arbitrum One and Base to Ethereum's approximately 15-minute checkpoint finality; meaning that cross-chain transfer timing is not uniform and cannot be predicted with precision.

Key custody and operational security

Control over W and any associated governance functionalities depends entirely on secure management of wallet private keys and signing authority. Loss of private keys, custodial failure, phishing, social engineering, malicious smart-contract interaction or unauthorised access can result in permanent and irrecoverable loss of W or delegated voting power. No protocol-level recovery mechanism exists.

No statutory compensation

W is a crypto-asset. Holding or trading W does not create deposit-insurance coverage, investor-compensation scheme membership, or statutory recovery rights. Holders bear the risks associated with digital assets and remain responsible for assessing suitability, legal position and applicable tax treatment in their own circumstances.

Delisting Risks

Bitstamp Europe S.A. might remove the token from trading in line with Bitstamp Markets Trading Rules.

Foundation and treasury influence

The Wormhole Foundation, holds 23.3% of total W supply in its treasury and is responsible for deploying those resources towards research, grants, developer support and operational expenses. The scale of this allocation allows the Foundation to influence ecosystem priorities, grant decisions, governance transition pace and market dynamics as tokens are deployed. The tokenomics roadmap explicitly contemplates progressive decentralisation, but the extent and timeline of that transition remain at the Foundation's discretion during the current phase.

Regulatory and jurisdictional risk

The Foundation's Cayman Islands registration, the global user base for W, and multichain deployment across chains serving users in multiple legal jurisdictions expose the protocol and its participants to evolving regulation, sanctions requirements, data-protection obligations and tax treatment. Changes in applicable law, exchange licensing requirements or third-party compliance policies may restrict access, require disclosures, alter governance operations or affect W's availability on trading platforms.

Privacy and data-handling risk

Interaction with Wormhole interfaces may involve collection and processing of personal data, including wallet addresses and usage metadata. The Foundation applies technical and organisational safeguards, but data processing across international jurisdictions, the risk of breach and the exercise of data-subject rights depend on applicable law, which varies across users' locations. On-chain transaction data is permanently public and immutable regardless of any off-chain data-protection measures.

Native multichain token design and supply parity risk

W exists simultaneously as an SPL token on Solana and as an ERC-20 token on Ethereum, Arbitrum One, Optimism, and Base through the NTT framework. The consistency of cross-chain W representation depends on NTT Managers enforcing correct lock or burn logic, transceivers verifying messages accurately, and the Global Accountant correctly tracking total supply across all chains. A failure in any of these components could result in a temporary or persistent divergence between the aggregate supply reported across chains and the actual issued supply.

Supply, allocation and unlock risk

W has a maximum supply of 10,000,000,000 tokens, of which 1,800,000,000 were circulating at launch. 82% of the total supply was initially locked and scheduled to unlock over 4 years. Allocations include 31% to ecosystem and incubation, 23.3% to the Foundation treasury, 12% to core contributors, and 11.6% to strategic network participants. As these tokens unlock, circulating supply increases, which may exert downward price pressure depending on market conditions and holder behaviour. The unlock schedule is published but the on-chain vesting may not be directly auditable in all cases.

Governance staking and delegation risk

W staking for governance delegates voting power on-chain through MultiGov smart contracts but provides no yield, requires no lockup and does not affect token ownership. Delegation patterns can concentrate effective voting influence in a small number of delegates, and low overall staking or participation rates may allow governance outcomes to be determined by a minority of W holders. There is no minimum participation threshold at the token level; quorum requirements are set at the proposal level within MultiGov.

Network support and deprecation risk

W's multichain model depends on the continued connection, Guardian observation, and operational maintenance of each supported chain. Wormhole has previously announced the disconnection of certain chains from Guardian observation and the delisting of those chains from Portal, with defined grace periods for users to withdraw assets. Further deprecations of supported networks, changes to Guardian set coverage, or new chain-specific policy changes may impair W transfer routing, liquidity access or user continuity on affected chains.

Relayer and execution dependency risk

Delivery of signed VAAs to destination-chain contracts depends on relay providers or, since March 2026, exclusively on the Executor framework following the deprecation of the Standard Relayer. The Executor operates as an open marketplace in which providers compete to deliver messages, but delivery timing, fee availability and provider participation remain variable. Relayers and Executor providers cannot alter correctly verified VAA contents, but they can influence when a transfer is delivered, and operational gaps in relay provision could delay or stall cross-chain W transfers.

MultiGov execution risk

W governance operates through the MultiGov hub-and-spoke architecture, with Ethereum as the hub and spoke contracts on supported EVM chains and Solana. The proposal lifecycle includes vote aggregation from multiple chains, quorum checks, replay-guard verification, a timelock delay, and cross-chain execution via the Wormhole messaging layer. A failure or misconfiguration in any of these stages ,including vote-collection sequencing, checkpointing, cross-chain message delivery or spoke-chain execution, could delay, prevent or incorrectly execute governance outcomes.

Governance concentration and Guardian threshold risk

Wormhole's security model and on-chain governance currently depend on a 19-member Guardian set. A supermajority of 13 of the 19 Guardians is sufficient to sign messages, pass governance actions or upgrade ecosystem contracts. Conversely, 7 of the 19 Guardians acting in concert can censor messages or block governance by declining to sign. The current Guardian set is composed of prominent validator operators but represents a relatively small group whose collective behaviour determines both the security and the governance direction of the protocol.

Administrative upgrade and pause role risk

Guardian governance can change the Guardian set, upgrade ecosystem contract implementations and configure per-chain Delegated Guardian Set thresholds. Within NTT, the Owner role has full administrative control over NTT Manager contracts, including the ability to change transceivers, rate limits and peer configurations, while the Pauser role can immediately halt initiation of new W transfers on any supported chain. Compromise, misuse or misconfiguration of any of these roles could disrupt cross-chain W transfers, alter upgrade paths or affect user access without advance notice.

Incident response and emergency-control risk

Wormhole maintains an incident response program and relies on existing Guardian governance upgrade authority to patch affected contracts in the event of a critical vulnerability. An emergency shutdown mechanism covering the entire protocol was considered and deliberately not implemented. Emergency response therefore depends on Guardian consensus, monitoring speed and the governance upgrade process, which introduces latency and coordination risk in time-sensitive incidents.

Guardian monitoring and manual-response dependency

The Governor mechanism relies on each Guardian operator independently applying their locally held view of inbound and outbound transfer flows, monitoring activity against configured limits, and manually responding within the 24-hour delay window if a suspicious transfer is identified. Each Guardian may have a marginally different view of Governor state depending on message ordering and feed completeness. If a majority of Guardian operators do not detect or do not act on a suspicious transfer within the delay window, the Governor cannot prevent the transfer from completing.

Smart-contract and protocol defect risk

Wormhole relies on interconnected smart contracts across multiple chains and runtimes, Guardian software, NTT components, MultiGov contracts, and relay infrastructure. Third-party audits have identified issues in historically deployed components, including VAA handling hash-collision scenarios, proxy safeguard insufficiencies, NTT queued-transfer defects, rate-limit bypass conditions, and access-control gaps. Audits are point-in-time assessments and do not provide a continuous guarantee of correct operation. Undetected defects in any component could cause asset loss, transfer failures or incorrect governance execution.

Guardian network compromise risk

The core bridge, NTT transfers and governance all depend on the Guardian Network producing correctly signed VAAs. If compromised Guardian nodes reach the 13-of-19 signing threshold, the entire Wormhole messaging layer, including all W cross-chain transfers and governance actions, would be at risk of producing fraudulent or malicious VAAs. At that threshold, an attacker could fabricate supply, redirect transfers or execute unauthorised governance actions without a separate consensus breach on any individual underlying chain.

Cross-chain message and finality risk

VAAs are signed by Guardians based on observed source-chain events. Lower consistency settings allow Guardians to sign a VAA before the underlying source-chain transaction is fully finalised. If a source-chain block containing the originating W transfer is subsequently reorganised or reverted, the VAA may have already been used to release or mint tokens on the destination chain, creating a supply discrepancy. L2 sequencer failures, parent-chain reorganisations and challenge-period outcomes can all affect the validity of events that have already been observed and attested.

Transferability and rate-limit risk

NTT enforces configurable per-chain inbound and outbound rate limits on W transfers. Transfers exceeding current capacity are placed in a queue until the applicable rate-limit window refills. During periods of high demand or abnormal transfer activity, users may experience queued or reverted transfers and may not be able to move W across chains within their expected timeframe. Rate limit parameters are set by the NTT Owner role and may be changed through governance.

Inherited chain infrastructure risk

W's security on each chain inherits that chain's own infrastructure assumptions. Solana transactions are atomic and subject to a 1,232-byte size limit and a 150-slot blockhash validity window; expired blockhashes cause transaction failure. Ethereum finality requires a validator supermajority representing at least two-thirds of staked ETH; reverting a finalised block would require a slashing event destroying at least one-third of total staked ETH. Arbitrum One provides soft finality through the sequencer, with hard finality only after batches are confirmed on Ethereum. OP Mainnet and Base withdrawals to Ethereum carry a 7-day challenge window before finalisation, and proof-maturity delays must be satisfied before withdrawal execution. Failures, bugs or consensus changes on any of these underlying chains would directly affect the usability, safety and finality of W on that chain.

Cross-chain supply and bridge-integrity risk

The token bridge and NTT framework depend on correct message verification and supply accounting to maintain 1:1 parity across chains. The Governor whitepaper identifies three primary bridge failure modes: smart-contract bugs in Wormhole or connected chain contracts, Guardian software bugs, and Guardian key compromise. An unlimited, instantaneous cross-chain transfer could drain liquidity from a source chain if a connected chain is compromised or produces fraudulent messages. While the Governor and Global Accountant provide partial mitigations, they depend on timely Guardian response and correct configuration to be effective.

Quantum computing risk

All cryptographic authentication within W's infrastructure relies on elliptic-curve algorithms that are vulnerable to quantum attack. W transactions on EVM chains use ECDSA over the secp256k1 curve; W transactions on Solana use Ed25519; and Guardian VAA signatures use secp256k1-based signing. Shor's algorithm, running on a sufficiently capable quantum computer, could derive private keys from public keys or forge signatures across all of these schemes, enabling an attacker to impersonate account holders, forge Guardian attestations or produce fraudulent VAAs without any on-chain evidence of compromise. Post-quantum cryptographic standards have been finalised by the National Institute of Standards and Technology, and the Ethereum roadmap acknowledges quantum migration as a long-term concern, but neither Wormhole's Guardian signing infrastructure nor the underlying EVM chains or Solana have published a concrete migration timeline to quantum-resistant cryptography. Current quantum hardware cannot break these algorithms at production scale, but the structural vulnerability will remain until a migration is completed.

Offer-Related Risks

• Cross-chain transfer delay and rate-limit risk: Configurable consistency levels define how long Guardians wait before signing a VAA for each source chain, reducing the risk of signing based on unconfirmed state. Per-chain NTT rate limits constrain the volume of W that can move through any single chain pair within a configured window, and transfers that exceed capacity are queued rather than silently dropped, preserving user funds while throttling abnormal flow.

Crypto-Asset-Related Risks

• Native multichain token design and supply parity risk: The Global Accountant tracks the total circulating supply of W across all connected chains and is designed to prevent cross-chain transfers that would create a supply that exceeds the verified on-chain total. This functions as an on-chain accounting backstop against unbacked minting across NTT deployments.

Project Implementation-Related Risks

• Network support and deprecation risk: Changes to supported networks, Guardian disconnections, and service discontinuations are publicly announced with defined grace periods before taking effect. This provides holders, integrators and liquidity providers advance notice to adjust routing, withdraw assets from affected chains, or migrate to alternative networks before access is removed.
• Relayer and execution dependency risk: Any participant holding a correctly signed VAA may submit it to the destination chain, meaning message delivery is not exclusively dependent on any single relay provider. The Executor marketplace creates competition among multiple independent providers, reducing the impact of any single provider's failure on message delivery timing or availability.
• Administrative upgrade and pause role risk: Governance contract upgrades executed through MultiGov are subject to the timelock delay, during which the scheduled action is publicly visible on-chain. The pause function available to the NTT Pauser role halts new transfer initiation but does not affect transfers already in progress or completed; it is therefore a targeted operational control rather than a full asset freeze.
• Governance concentration and Guardian threshold risk: Guardian governance actions require a two-thirds supermajority (13 of 19 canonical Guardians) to pass, raising the coordination cost for any unilateral action. MultiGov adds a second layer of control for W token governance through on-chain checkpointing, replay guards preventing double-execution, configurable quorum thresholds at the proposal level, and a timelock delay between proposal approval and execution, providing a window for holders to respond.
• Incident response and emergency-control risk: Emergency patching relies on existing Guardian governance upgrade authority, allowing affected contracts to be replaced through the standard governance path without requiring a general protocol shutdown. This provides an auditable escalation mechanism while preserving continuity of unaffected protocol components.
• Guardian monitoring and manual-response dependency: The Governor enforces a configurable delay window — up to 24 hours — on transfers that would breach per-chain flow limits, during which time Guardian operators can investigate and remove suspicious messages from their local queues before those messages complete. Governor status is observable on the Wormhole gossip network, enabling coordinated Guardian response within the delay window.

Technology-Related Risks

• Smart-contract and protocol defect risk: 29 independent third-party audits have been completed across core protocol, NTT, MultiGov and chain-specific components, with reports published following issue resolution. A continuous bug bounty program operated through Immunefi offers a maximum reward of USD 5,000,000 for critical vulnerabilities across smart contracts, Guardian nodes and blockchain integrations, providing ongoing incentive for external security researchers to identify and responsibly disclose defects.
• Guardian network compromise risk: The Governor can delay token-bridge messages that would exceed configured per-chain inbound or outbound flow limits by up to 24 hours. During this window, Guardian operators monitoring transfer flows can identify and remove fraudulent or anomalous messages from their local queues before they are executed on the destination chain, limiting the exploitable window if a minority of Guardians is compromised short of the signing threshold.
• Cross-chain supply and bridge-integrity risk: The Governor, Global Accountant and Guardian monitoring operate as layered, independent controls for cross-chain transfers: the Global Accountant enforces supply parity at the accounting layer, the Governor enforces throughput limits and enables manual review at the operational layer, and Guardian monitoring provides real-time detection at the validator layer. These controls together constrain the impact and speed of a bridge-integrity failure, though each control depends on timely and correct Guardian operation to function as intended.
• Transferability and rate-limit risk: Configurable per-chain inbound and outbound rate limits with a queuing mechanism constrain abnormal or exploitative transfer volumes without causing asset loss. Transfers exceeding limits are held in the queue until capacity refills, and the queue can be cancelled by the sender where supported. Rate limit parameters may be adjusted by the NTT Owner role to reflect changing operational or risk conditions.

Bitstamp Europe S.A.

549300XIBGTJ0PLIEO72

W

W does not have a standalone consensus mechanism. Transactions involving W obtain ordering, execution, and finality through the consensus mechanism of the underlying chain on which the transaction is submitted. Cross-chain transfers additionally require Wormhole's Guardian attestation: 13 of 19 canonical Guardians must independently sign the same VAA before the destination chain executes the transfer.

On Ethereum, consensus is proof of stake. Validators deposit 32 ETH into the staking contract and are responsible for attesting to proposed blocks and, when selected, proposing blocks. Time is divided into 12-second slots and 32-slot epochs. One validator is randomly selected as block proposer for each slot, and committees of validators provide attestations using BLS12-381 signatures. Finality is established through checkpoint links: once validators representing at least two-thirds of total staked ETH agree on a checkpoint-epoch pair, all blocks within the earlier epoch are finalised. Reverting a finalised block would require destroying at least one-third of all staked ETH through slashing.

On Solana, the consensus mechanism is Tower BFT, a variant of Practical Byzantine Fault Tolerance adapted for Solana's architecture. Tower BFT uses stake-weighted validator voting to achieve finality and leverages Proof of History as a cryptographic clock. Proof of History is a high-frequency verifiable delay function that produces a sequential, cryptographically verifiable time record by applying each output as the next input in a continuous hash chain. This allows Tower BFT to enforce timeouts and ordering constraints without requiring validators to exchange timestamps, significantly reducing messaging overhead. Finality on Solana is achieved when a supermajority of stake-weighted votes confirms a block, with validators committing to lockout periods that increase exponentially with each subsequent vote.

Arbitrum One is an Optimistic Rollup that settles to Ethereum using the Nitro technology stack. The sequencer provides soft finality immediately upon inclusion in its real-time feed; hard finality occurs when transaction batches are posted to and confirmed on the Ethereum parent chain, at which point Arbitrum inherits Ethereum's proof-of-stake security.

On OP Mainnet, transaction finality progresses through four stages: Flashblock preconfirmation (~250 ms), Layer 2 block inclusion (~2 s), Layer 1 batch inclusion (~7 min), and Layer 1 batch finality (~20 min), reached when the Ethereum batch containing the transaction is older than two epochs or 64 Layer 1 blocks. Withdrawals from OP Mainnet to Ethereum require a separate 7-day settlement period to allow the Fault Proof system to function.

Base is an Ethereum rollup using the OP Stack. A single active sequencer accepts transactions, orders them, produces Flashblocks every 200 ms, and posts batches to Ethereum. Finality progresses through the same four staged model: Flashblock inclusion (~200 ms), Layer 2 block inclusion (~2 s), Layer 1 batch inclusion (~2 min), and Layer 1 batch finality (~20 min). Withdrawals from Base to Ethereum similarly carry a 7-day challenge window.

See H.5

2026-01-01

2026-05-19

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at : www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: www.micacryptoalliance.com/methodologies

Land use: 0.41017 m²

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5). Estimates on individual node weight, hazardous components and depreciation rate are used.
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5). Usage of natural resources is approximated through land use metrics. Land use, water use and water recycling are calculated based on energy mix-specific estimates of purchased electricity land intensity, purchased electricity water intensity, and water recycling rates. Full methodology available at: www.micacryptoalliance.com/methodologies