Search
Search for projects by name or address
Base Solana BridgeBase Solana Bridge
About
Base's native lock-and-mint token and message bridge between Base and Solana. Messages from Solana are verified on Base solely by signatures: 2-of-2 Base validators plus 3-of-10 partner signers managed by Chainlink's CCIP governance. The bridge escrow, all... wrapped tokens and all Twin accounts are upgradable by a single EOA without delay.
About
Base's native lock-and-mint token and message bridge between Base and Solana. Messages from Solana are verified on Base solely by signatures: 2-of-2 Base validators plus 3-of-10 partner signers managed by Chainlink's CCIP governance. The bridge escrow, all... wrapped tokens and all Twin accounts are upgradable by a single EOA without delay.
Base’s native lock-and-mint token and message bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. between Base and Solana. Messages from Solana are verified on Base solely by signatures: 2-of-2 Base validatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier plus 3-of-10 partner signers managed by Chainlink’s CCIP governance. The bridge escrow, all wrapped tokens and all Twin accounts are upgradable by a single EOA without delay.
Architecture
A central Bridge contract on Base combines an arbitrary message bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. and a lock-and-mint token bridge with Solana: Base-native assets (ETH, ERC20s) are escrowed in the Bridge, Solana-native assets (SOL, SPL tokens) are minted as CrossChainERC20 tokens. Only the Base side is analyzed here; the Solana bridge program and its custody are out of scope.
Message lifecycle
Outgoing messages escrow or burn the asset and are appended to an onchain merkle mountain range accumulator that offchain infrastructure relays to Solana. Incoming messages must first be attested in the BridgeValidator; anyone can then execute them via Bridge.relayMessages(), which mints or releases tokens, executes arbitrary calls through the sender’s Twin account, or both. Failed executions can be retried permissionlessly.
Crosschain validation
There are no fraud proofs, validity proofs or light clients: message validity rests entirely on two signature quorums that must both be met — 2 of 2 “Base validatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier” and 3 of 10 partner signers listed in the SignerRegistry. If these two groups collude, they can mint unbacked tokens, drain the escrow, and act through any user’s Twin account. The Base validator set and both thresholds are fixed (no setter functions, no proxy admin), while the partner signer set is managed by the same RBACTimelock (minimum delay 3h) that administers Chainlink’s CCIP contracts on Base (tracked in our CCIP review).
Wrapped tokens and Twin accounts
CrossChainERC20 tokens are deployed permissionlessly through a factory as beacon proxies, minted and burned only by the Bridge. Each Solana address gets a deterministic Twin beacon proxy that executes arbitrary calls on its behalf on Base.
Pausing
1 guardian account(s) can pause and unpause the bridge at any time, blocking outgoing messages, attestations and message execution.
UpgradeabilityThe ability for rollup smart contracts and parameters used in a rollup to be updated by holders of an admin key. Upgradeability represents a vector of risk for users, and should be decentralized and combined with time delays for greater security guarantees. and governance
A single EOA is the admin of the Bridge proxy, the owner of the Bridge (managing guardians), and the owner of both beacons — it can upgrade the escrow and replace the code of every wrapped token and every Twin account without delay. The BridgeValidator and CrossChainERC20Factory proxies have no admin and cannot be upgraded.
Symbol | Last 24h
Volume | Last 24h
transfer count | Last 24h avg.
transfer time | Last 24h avg.
transfer value | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Symbol | Last 24h
Volume | Last 24h
transfer count | Last 24h avg.
transfer time | Last 24h avg.
transfer value | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Symbol | Last 24h
Volume | Last 24h
transfer count | Last 24h avg.
transfer time | Last 24h avg.
transfer value | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Timestamp | Tokens | Value | Bridge | Transfer time | Chains | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Timestamp | Tokens | Value | Bridge | Transfer time | Chains | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Timestamp | Tokens | Value | Bridge | Transfer time | Chains | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
2026 August 27, 07:43 UTC9changesInitial discovery of the Base < Solana native bridge (Base side): Bridge escrow with MMR (merkle mountain range) message accumulator, BridgeValidator (2-of-2 Base validators + 3-of-10 Chainlink partner signers, fixed at initialization), SignerRegistry owned by the CCIP RBACTimelock (border of this discovery), CrossChainERC20/Twin beacon architecture upgradable by a single EOA.
Initial discovery of the Base <> Solana native bridge (Base side): Bridge escrow with MMR (merkle mountain range) message accumulator, BridgeValidator (2-of-2 Base validators + 3-of-10 Chainlink partner signers, fixed at initialization), SignerRegistry owned by the CCIP RBACTimelock (border of this discovery), CrossChainERC20/Twin beacon architecture upgradable by a single EOA.
Initial discovery
| + | Status: CREATED |
| contract CrossChainERC20 (base:0x0c39C78Dc31082187D8D7de9937bA46Ddba3c043) [basesolbridge/CrossChainERC20] | |
| +++ description: Implementation contract for the CrossChainERC20 tokens (beacon proxies) representing Solana-native assets on Base (e.g. SOL, JitoSOL). Only the Bridge can mint and burn them. | |
| + | Status: CREATED |
| contract Bridge (base:0x3eff766C76a1be2Ce1aCF2B69c78bCae257D5188) [basesolbridge/Bridge] | |
| +++ description: Core contract of the Base <> Solana bridge on the Base side. Outgoing messages (token transfers and arbitrary Solana instructions) are appended to an onchain merkle mountain range accumulator that is consumed by offchain infrastructure and the bridge program on Solana. Incoming messages from Solana must first be attested in the BridgeValidator and can then be relayed permissionlessly: they mint CrossChainERC20 tokens, release escrowed Base-native assets or execute arbitrary calls through per-user Twin contracts. Base-native assets (ETH, ERC20s) that are bridged to Solana are escrowed in this contract. | |
| + | Status: CREATED |
| contract SignerRegistry (base:0x50Ea62F44f44C17d48390cc9fd235dac8E5e127a) [basesolbridge/SignerRegistry] | |
| +++ description: Registry of the partner validator set that co-signs attestations of Solana -> Base messages for the BridgeValidator of the Base <> Solana bridge. | |
| + | Status: CREATED |
| contract RBACTimelock (base:0x7B0328745A01634c32eFAf041d91432a075B308D) [transporter/RBACTimelock] | |
| +++ description: Role based timelock used to administer CCIP contracts. | |
| + | Status: CREATED |
| contract BridgeValidator (base:0xAF24c1c24Ff3BF1e6D882518120fC25442d6794B) [basesolbridge/BridgeValidator] | |
| +++ description: Attestation registry for messages passed from Solana to Base: batches of message hashes become valid for execution in the Bridge after being co-signed by at least 2 of 2 Base validators and 3 partner validators listed in the SignerRegistry. The validator set and thresholds are fixed at initialization: the contract exposes no functions to change them and its proxy has no admin. | |
| + | Status: CREATED |
| contract Twin (base:0xb0887e4793d944Cf7bA674B3b3FA5C15900ddaA7) [basesolbridge/Twin] | |
| +++ description: Implementation contract for Twin accounts: each Solana address gets a deterministic Twin beacon proxy on Base that executes arbitrary calls on its behalf when instructed via bridge messages from Solana. Only the Bridge can call it. | |
| + | Status: CREATED |
| contract TwinBeacon (base:0xb326c02150bb0De265Bb0eCeDA53531ab0163bf6) [global/UpgradeableBeacon] | |
| +++ description: A beacon with an upgradeable implementation currently set as base:0xb0887e4793d944Cf7bA674B3b3FA5C15900ddaA7. Beacon proxy contracts pointing to this beacon will all use its implementation. | |
| + | Status: CREATED |
| contract CrossChainERC20Factory (base:0xDD56781d0509650f8C2981231B6C917f2d5d7dF2) [basesolbridge/CrossChainERC20Factory] | |
| +++ description: Factory that permissionlessly deploys CrossChainERC20 token contracts (beacon proxies) representing Solana-native assets (SOL and SPL tokens) on Base. The deployed tokens are minted and burned by the Bridge. | |
| + | Status: CREATED |
| contract CrossChainERC20Beacon (base:0xdDc41fdA4B758728d07F4686DbE7D1C75C6b2552) [global/UpgradeableBeacon] | |
| +++ description: A beacon with an upgradeable implementation currently set as base:0x0c39C78Dc31082187D8D7de9937bA46Ddba3c043. Beacon proxy contracts pointing to this beacon will all use its implementation. | |
Base Chain
Actors:
Role based timelock used to administer CCIP contracts.
- Can interact with SignerRegistry
- add, remove and rotate the partner validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier signers (up to 20) that attest Solana -> Base messages in the BridgeValidator
- Can interact with RBACTimelock
- grant or revoke roles on this timelock
- Can interact with SignerRegistry
- attest messages passed from Solana to Base by co-signing message batches for the BridgeValidator (the partner validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier threshold defined there is required, alongside the Base validator signatures). Attested messages are executable on the BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. without further verification
- Can interact with BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge.
- pause and unpause the Bridge, which blocksAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. outgoing messages, incoming relays and new message attestations in the BridgeValidator
- Can interact with BridgeValidator
- attest messages passed from Solana to Base by co-signing message batches (2 of 2 signatures required, alongside 3 partner validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier signatures). Attested messages are executable on the BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. without further verification
- Can upgrade with no delay
- BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge.
- Can interact with Bridge
- grant and revoke the guardian role and transfer ownership of the Bridge
- Can interact with TwinBeacon
- change the implementation of the TwinBeacon and with it the code of every Twin account contract of the Base <> Solana bridge
- Can interact with CrossChainERC20Beacon
- change the implementation of the CrossChainERC20Beacon and with it the code of every bridged token (e.g. SOL, JitoSOL) of the Base <> Solana bridge
Base Chain
Implementation contract for the CrossChainERC20 tokens (beacon proxies) representing Solana-native assets on Base (e.g. SOL, JitoSOL). Only the BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. can mint and burn them.
Core contract of the Base <> Solana bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. on the Base side. Outgoing messages (token transfers and arbitrary Solana instructions) are appended to an onchain merkle mountain range accumulator that is consumed by offchain infrastructure and the bridge program on Solana. Incoming messages from Solana must first be attested in the BridgeValidator and can then be relayed permissionlessly: they mint CrossChainERC20 tokens, release escrowed Base-native assets or execute arbitrary calls through per-user Twin contracts. Base-native assets (ETH, ERC20s) that are bridged to Solana are escrowed in this contract.
- Roles:
- admin: EOA 10
- guardians: EOA 2
- owner: EOA 10
Registry of the partner validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier set that co-signs attestations of Solana -> Base messages for the BridgeValidator of the Base <> Solana bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge..
- Roles:
- owner: RBACTimelock
- signers: EOA 1, EOA 11, EOA 12, EOA 13, EOA 3, EOA 4, EOA 5, EOA 6, EOA 7, EOA 9
Attestation registry for messages passed from Solana to Base: batches of message hashes become valid for execution in the BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. after being co-signed by at least 2 of 2 Base validatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier and 3 partner validators listed in the SignerRegistry. The validator set and thresholds are fixed at initialization: the contract exposes no functions to change them and its proxy has no admin.
- Roles:
- baseValidators: EOA 14, EOA 8
Implementation contract for Twin accounts: each Solana address gets a deterministic Twin beacon proxy on Base that executes arbitrary calls on its behalf when instructed via bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. messages from Solana. Only the Bridge can call it.
A beacon with an upgradeable implementation currently set as Twin. Beacon proxy contracts pointing to this beacon will all use its implementation.
- Roles:
- owner: EOA 10
Factory that permissionlessly deploys CrossChainERC20 token contracts (beacon proxies) representing Solana-native assets (SOL and SPL tokens) on Base. The deployed tokens are minted and burned by the BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge..
A beacon with an upgradeable implementation currently set as CrossChainERC20. Beacon proxy contracts pointing to this beacon will all use its implementation.
- Roles:
- owner: EOA 10
The current deployment carries some associated risks:
Funds can be stolen if a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).