# LayerZero routes

## One token, five contracts

- **An address per chain.** A token is a LayerZero OFT contract on each of Ethereum, Base, Robinhood Chain and BSC, and a mint on Solana, held by LayerZero’s OFT program. The five addresses are all different and all end in `6ea`. They are on the token’s page and in `/api/pools`.
- **1B per chain.** Each chain mints its own 1 billion at launch, all of it into that chain’s pool, 5 billion across the five. On an EVM chain `launchSlice()` is that 1B and `launchTotal()` the 5B. Nothing can mint more: there is no mint function and no minter.
- **Burn and mint.** A transfer burns the tokens on the chain it leaves and LayerZero’s message mints the same number on the chain it reaches. On an EVM chain the token’s fee is moved to `bridgeFeeTo()` and only the rest is burned, so what is burned on one side is exactly what is minted on the other.
- **What is on a chain, and what is reported.** On each EVM chain `localSupply()` is what is on that chain now; it moves as tokens cross. `totalSupply()` is a reported figure: it starts at the chain’s 1B, and for tokens launched from the current factories the platform’s SupplyReporter on that chain mirrors the token’s supply on Solana into it. A report moves no balance and mints nothing, and the token refuses one below its own `localSupply()` or above `launchTotal()`. Earlier launches have no reporter and always report their slice.
- **Peers are sealed at launch.** A peer is the token’s counterpart on another chain, the only address it accepts a mint from. The factory registers the four peers in the transaction that creates the token and hands ownership to a LaunchOwner contract that is sealed from the start: `sealed_()` is true and it has no way to add, change or remove a peer.

| Chain | SupplyReporter |
| --- | --- |
| Ethereum | 0xD7AF0c412911DCE5F864d949abA14a3048DD87B2 |
| Base | 0xF10254C126e41F69799e781D185cc42c99EE37Ed |
| Robinhood Chain | 0x51D658a71AEa38f123d4c73e42703Fb9C949900A |
| BSC | 0xf1a98Fa0B2baB64BC4358dC0C2c13444ecCA365b |

## How every route is set up

A route is one direction between two chains, for one token. When the factory creates a token it is, for that one transaction, the token’s LayerZero delegate, and it writes every route from a table fixed in its own constructor. Nothing is left on LayerZero’s defaults, because a default can be changed by whoever administers the endpoint.

- **Libraries.** The send and the receive message library are named explicitly: LayerZero’s Ultra Light Node on every chain, the same contracts the endpoint’s defaults point at today, pinned so they stay.
- **Executor.** LayerZero’s executor on each chain is named explicitly, with a cap on the message size.
- **Verifiers.** No required verifiers. An optional set of Pangea’s own verifier plus the external ones, and 2 of the set must attest before a message counts. So no single party can deliver a message: not Pangea’s verifier, and not any one external one.
- **Confirmations.** 1 on every source chain, Solana included: the verifiers attest once the send has 1 confirmation. Both ends of a route hold the same number.
- **A gas floor.** Every transfer must give the delivery at least 100,000 gas on an EVM chain, and 200,000 compute units plus 2,074,080 lamports on Solana, for the recipient’s token account. It is an enforced option, added to every send, so a sender cannot under-pay delivery.
- **A message size.** Up to 10,000 bytes between EVM chains and from Solana. Toward Solana 256 bytes for launches from the current factories; the factory admin can move that between 200 and 800 for launches after, never for a token that exists. A Solana transaction is small, and a cap above what Solana can deliver would let a message be sent that can never land.

| Chain | Optional verifiers | Of which must attest | Confirmations |
| --- | --- | --- | --- |
| Ethereum | Pangea, LayerZero Labs, Nethermind, Horizen, Canary | 2 | 1 |
| Base | Pangea, LayerZero Labs, Nethermind, Horizen, Canary | 2 | 1 |
| Robinhood Chain | Pangea, LayerZero Labs, Nethermind | 2 | 1 |
| BSC | Pangea, LayerZero Labs, Nethermind, Horizen, Canary | 2 | 1 |
| Solana | Pangea, LayerZero Labs, Nethermind, Horizen, Canary | 2 | 1 |

That is the set on each chain, for its routes to Ethereum, Base, BSC and Solana. Robinhood Chain has two of the external verifiers, so a route with Robinhood Chain at either end uses the verifiers both chains have: Pangea, LayerZero Labs and Nethermind, 2 of 3. Every other route has 5, 2 of 5.

| Chain | Send library | Receive library | Executor |
| --- | --- | --- | --- |
| Ethereum | 0xbB2Ea70C9E858123480642Cf96acbcCE1372dCe1 | 0xc02Ab410f0734EFa3F14628780e6e695156024C2 | 0x173272739Bd7Aa6e4e214714048a9fE699453059 |
| Base | 0xB5320B0B3a13cC860893E2Bd79FCd7e13484Dda2 | 0xc70AB6f32772f59fBfc23889Caf4Ba3376C84bAf | 0x2CCA08ae69E0C44b18a57Ab2A87644234dAebaE4 |
| Robinhood Chain | 0xC39161c743D0307EB9BCc9FEF03eeb9Dc4802de7 | 0xe1844c5D63a9543023008D332Bd3d2e6f1FE1043 | 0x4208D6E27538189bB48E603D6123A94b8Abe0A0b |
| BSC | 0x9F8C645f2D0b2159767Bd6E0839DE4BE49e823DE | 0xB217266c3A98C8B2709Ee26836C98cf12f6cCEC1 | 0x3ebD570ed38B1b3b4BC886999fcF507e9D584859 |
| Solana | 7a4WjyR8VZ7yZz5XJAKm39BUGn5iT9CKcv2pmG9tdXVH | 7a4WjyR8VZ7yZz5XJAKm39BUGn5iT9CKcv2pmG9tdXVH | AwrbHeCyniXaQhiJZkLhgWdUCteeWSGaSN1sTfLiY7xK |

| Chain | LayerZero endpoint | Launch factory | Pangea’s verifier |
| --- | --- | --- | --- |
| Ethereum | 0x1a44076050125825900e736c501f859c50fE728c | 0x1D583e6eA4AA7c5e167a7E69B07b83DD5B813f53 | 0x5FA03555f186e53a644405817E1BeAC894Bd6562 |
| Base | 0x1a44076050125825900e736c501f859c50fE728c | 0xba4beE425F268f7Dc0F7e5457d14320d5A64cd06 | 0x6dbFda44baB6bf0DDF3E9F88d7823eDdB48f4b25 |
| Robinhood Chain | 0x6F475642a6e85809B1c36Fa62763669b1b48DD5B | 0x8A1F3e1DB07048c007F6d9ab924494C77c0DBa65 | 0x85880e7D5315365165E97620Ba17B48A645b13F3 |
| BSC | 0x1a44076050125825900e736c501f859c50fE728c | 0xd1454764E8D87B117a23491E77cAfcCC50430256 | 0xF61Ed4347c4D02522e96657a606f49E8381B3dCA |
| Solana | ULN 7a4WjyR8VZ7yZz5XJAKm39BUGn5iT9CKcv2pmG9tdXVH | Splitter program Hb5uTppRbNxc3RjVRqTWqfdU3E3GiZyGYKccxYf9tUej | 7EgbAY7663cybirqgmFHzF8q9debeePxr8ra7wKyEmNE |

| Verifier | Ethereum | Base | Robinhood Chain | BSC | Solana |
| --- | --- | --- | --- | --- | --- |
| LayerZero Labs | 0x589dEDbD617e0CBcB916A9223F4d1300c294236b | 0x9e059a54699a285714207b43B055483E78FAac25 | 0xd01ae6905d48315f7bE10C7330aeCF8360Ef5b12 | 0xfD6865c841c2d64565562fCc7e05e619A30615f0 | 4VDjp6XQaxoZf5RGwiPU9NR1EXSZn2TP4ATMmiSzLfhb |
| Nethermind | 0xa59BA433ac34D2927232918Ef5B2eaAfcF130BA5 | 0xcd37CA043f8479064e10635020c65FfC005d36f6 | 0x0Ffe02DF012299A370D5dd69298A5826EAcaFdF8 | 0x31F748a368a893Bdb5aBB67ec95F232507601A73 | GPjyWr8vCotGuFubDpTxDxy9Vj1ZeEN4F2dwRmFiaGab |
| Horizen | 0x380275805876Ff19055EA900CDb2B46a94ecF20D | 0xa7b5189bcA84Cd304D8553977c7C614329750d99 | not on this chain | 0x247624e2143504730aeC22912ed41F092498bEf2 | HR9NQKK1ynW9NzgdM37dU5CBtqRHTukmbMKS7qkwSkHX |
| Canary | 0xa4fE5A5B9A846458a70Cd0748228aED3bF65c2cd | 0x554833698Ae0FB22ECC90B01222903fD62CA4B47 | not on this chain | 0xfA9bA83C102283958B997Adc8B44ED3A3CdB5dDa | 7jMeX5mzXnSSKYd8DxBDP4xMnkNFZZZm5W28FWUTbwU3 |

On Solana the same is done by Pangea’s splitter program. The program holds one route setting per destination chain, and the first transfer on a token’s route applies it to that token, once: the libraries, the executor, the verifiers in both directions, the confirmations and the gas floor. The token’s LayerZero admin and delegate on Solana is an address only that program can sign for, and the program has no instruction that changes a peer, a library or a verifier afterwards.

## Why nobody can change a route later

- On an EVM chain the factory writes the routes while it is the token’s delegate, then never calls the endpoint for that token again and has no function that could. The token’s owner, the sealed LaunchOwner, has no way to name another delegate. So no key, including Pangea’s, can change a token’s libraries, executor or verifiers.
- This matters because a delegate who could name the verifiers could name itself, attest a message nobody sent, and mint. Sealing the peers alone would not close that.
- One thing stays adjustable on purpose: the gas floor. The LaunchOwner’s admin can raise or lower it, so that a chain changing its gas costs does not break bridging for good. It accepts exactly one `lzReceive` option and nothing else, under hard caps of 1,000,000 gas and 10,000,000 in value, so it cannot add a payment to anyone or set a floor nobody can pay. On Solana the gas floor is fixed when the route is opened.
- The other side of this: if LayerZero retires a verifier a route depends on, that route keeps working only while two of its verifiers still attest, and nobody can swap one in. A paused bridge can be lived with; a token anyone could mint could not.
- On Solana the admin can change the route setting for launches still to come. A token’s route is applied with the setting in force when it launched, and the program refuses a setting edited after that, unless the admin signs the opening; once a route is open nothing changes it.

## Check it yourself

Everything above can be read from the chains, with no help from Pangea. The worked example is PTEST4, a live test launch, on Base. Its address there is `0x2dEC1F0FBe66ef78a7cec00cD1FD9c58345ED6Ea`; the other addresses are in the table at the end. These are read-only calls, with Foundry’s `cast` and any RPC endpoint for the chain.

The token's peers, owner and delegate, on Base:

```bash
TOKEN=0x2dEC1F0FBe66ef78a7cec00cD1FD9c58345ED6Ea
ENDPOINT=0x1a44076050125825900e736c501f859c50fE728c
RPC=your-base-rpc-endpoint

# its counterpart on Ethereum, BSC, Robinhood Chain and Solana
for EID in 30101 30102 30416 30168; do
  cast call $TOKEN "peers(uint32)(bytes32)" $EID --rpc-url $RPC
done

# the owner is a LaunchOwner, sealed: true
OWNER=$(cast call $TOKEN "owner()(address)" --rpc-url $RPC)
cast call $OWNER "sealed_()(bool)" --rpc-url $RPC

# the delegate, the only key that can set verifiers, is the factory that launched it
cast call $ENDPOINT "delegates(address)(address)" $TOKEN --rpc-url $RPC
```

One route's libraries, executor, verifiers and gas floor: Base to Robinhood Chain:

```bash
EID=30416
SEND_LIB=$(cast call $ENDPOINT "getSendLibrary(address,uint32)(address)" $TOKEN $EID --rpc-url $RPC)
cast call $ENDPOINT "isDefaultSendLibrary(address,uint32)(bool)" $TOKEN $EID --rpc-url $RPC
cast call $ENDPOINT "getReceiveLibrary(address,uint32)(address,bool)" $TOKEN $EID --rpc-url $RPC

# verifiers: (confirmations, required count, optional count, threshold, required, optional)
ULN=$(cast call $ENDPOINT "getConfig(address,address,uint32,uint32)(bytes)" $TOKEN $SEND_LIB $EID 2 --rpc-url $RPC)
cast decode-abi "f()((uint64,uint8,uint8,uint8,address[],address[]))" $ULN

# executor: (max message size, executor)
EXE=$(cast call $ENDPOINT "getConfig(address,address,uint32,uint32)(bytes)" $TOKEN $SEND_LIB $EID 1 --rpc-url $RPC)
cast decode-abi "f()((uint32,address))" $EXE

# the gas floor every send carries
cast call $TOKEN "enforcedOptions(uint32,uint16)(bytes)" $EID 1 --rpc-url $RPC
```

What those return for this token, read on 19 October 2026:

| Read | Answer | What it means |
| --- | --- | --- |
| `peers(30416)` | `0x00000000000000000000000068906d8b2a22d329b853ec650fa6a29fab6056ea` | The token on Robinhood Chain, left-padded to 32 bytes. |
| `peers(30168)` | `0xbad1e830d4a3bba670d642dd253151f5564074eb91e9197e0216ec274e91df6e` | Its OFT store on Solana, `DaGUXY1qixx3Wsp7KFb7L6UtXV6QHCRXtaXtx4yfLued`, as 32 bytes. |
| `sealed_()` | `true` | No peer can ever be added, changed or removed. |
| `delegates(token)` | `0x025f893Bdcd7978232C211e3A28610FC6d8B8970` | The factory that launched it, an earlier one than today’s, with no code to touch the endpoint again. |
| `isDefaultSendLibrary` | `false` | The library is pinned, not inherited. |
| `getConfig(... 2)` | `(1, 0, 3, 2, [], [3 verifiers])` | 1 confirmation, no required verifiers, 3 optional, 2 must attest. |
| `getConfig(... 1)` | `(10000, 0x2CCA08ae69E0C44b18a57Ab2A87644234dAebaE4)` | Messages up to 10,000 bytes, LayerZero’s executor. |
| `enforcedOptions(30416, 1)` | `0x000301001101000000000000000000000000000186a0` | One `lzReceive` option: 0x186a0, which is 100,000 gas. |

The three optional verifiers it returns are Pangea’s on Base, `0x6dbFda44baB6bf0DDF3E9F88d7823eDdB48f4b25`, and LayerZero Labs’ and Nethermind’s there. Toward Solana the same read returns 5 verifiers and an executor cap of 200 bytes: this token was launched before the factories raised it to 256. The gas floor toward Solana reads `0x00030100210100000000000000000000000000030d40000000000000000000000000001fa5e0`: 0x30d40 is 200,000 compute units and 0x1fa5e0 is 2,074,080 lamports.

On LayerZero Scan, look up the token’s address, or any transfer. Its transfer from Base to Robinhood Chain on 16 October 2026, `0x5860a6920fd6fe6d97f7d88104d6ce105bb43fd4a9654d7d84cdd9229e961f65`, shows all three of the route’s verifiers attesting, and the delivery five seconds after the send. Each message lists the verifiers that attested and the `lzReceive` gas it carried.

On Solana, a token’s route to a chain is open when LayerZero’s receive config account for it exists: the ULN program’s address for the seeds `"ReceiveConfig"`, the chain’s endpoint id as four big-endian bytes, and the OFT store. Its contents are the confirmations and the verifiers, in the same order as above. For PTEST4, read on 19 October 2026, the routes from Base and Robinhood Chain are open, each with 1 confirmation and 2 of its verifiers, and the routes from Ethereum and BSC are not open yet: nobody has bridged on them. [Bridging from code →](https://www.pangea.trade/app/docs#bridge-code) has a script that checks it.

| Chain | PTEST4 on that chain |
| --- | --- |
| Ethereum | 0x835e9CFB333B9E4811CA1585460442806a99d6eA |
| Base | 0x2dEC1F0FBe66ef78a7cec00cD1FD9c58345ED6Ea |
| Robinhood Chain | 0x68906D8b2A22D329b853ec650Fa6A29fAb6056Ea |
| BSC | 0x90Ba4Df685A2D33c12C40F03808F290519E7F6EA |
| Solana | Mint DdJ6R9TSKdNYMZhdgATANT98BJNgScuU58baQoCfZ6ea, OFT store DaGUXY1qixx3Wsp7KFb7L6UtXV6QHCRXtaXtx4yfLued |

> **Note:** Pangea’s own checks do the same against every factory before a launch: each route’s two ends must agree, and every verifier a factory names must be on a list kept by hand, with the operator’s name. The addresses on this page are those.

Part of the Pangea documentation: https://www.pangea.trade/app/docs.md