The Base bridge contract locks or burns tokens when sending messages to Solana,
and mints or unlocks tokens when receiving messages from Solana.
The Bridge contract itself builds Merkle trees from outgoing messages.
Validators verify the Merkle root every 300 finalized blocks and relay it to Solana.
You then prove your message exists in the tree to complete the transfer on Solana.
Tokens that are native to Base are locked and tokens that are native to Solana are burned when bridging to Solana.
Tokens that are native to Solana are minted and tokens that are native to Base are unlocked when bridging to Base.
Twin Contract: Your personal smart contract on Base for executing calls from Solana
What is the Twin Contract?
The Twin Contract is a smart contract that acts as your execution context on Base.
It represents the msg.sender on Base when you send an arbitrary contract call from Solana.
The Solana bridge program handles token transfers by locking or burning tokens and emitting events. For messaging, validators relay these messages to Base where they’re executed through your personal Twin contract - a smart contract that acts as your execution context on Base.Key Programs:
The relayer program is not part of the core bridge.
This is a convenience feature built on top of the bridge to reduce friction in the Solana -> Base direction.
Flow: Lock SOL → Wait for Validator Pre-approval → Execute on BaseThe Solana to Base bridge uses a pull-based model that requires 3 steps:
Initiate the bridge on Solana - Lock your SOL or native SPL token in a Solana vault
Wait for validators to pre-approve the message - Validators verify and approve your bridge message
Execute the message on Base - The approved message is executed on Base to mint SOL and execute any additional arbitrary calls
Tokens that are native to Solana are locked and tokens that are native to Base are burned when bridging to Solana.
Tokens that are native to Base are minted and tokens that are native to Solana are unlocked when bridging to Base.
For convenience, a relayer service is available that automatically handles step 3 for users who only want to worry about the initial transaction on Solana. This provides a seamless bridging experience while maintaining the security of the pull-based model.
The example above shows how to bridge native SOL to Base.
To bridge custom SPL tokens,
you need to create wrapped ERC20 representations on Base using the CrossChainERC20Factory.
Flow: Burn SOL (on Base) → Wait 15min → Generate Proof → Execute on SolanaThe Base to Solana flow requires manual proof generation. You burn wrapped SOL on Base, wait for finalization, then generate a cryptographic proof to execute on Solana and receive native SOL.
The repository includes utilities for converting between Solana and Base address formats,
getting your Solana CLI keypair for signing transactions,
and building and sending Solana transactions.
Convert Solana pubkey to bytes32 for Base contracts:
example.ts
Report incorrect code
Copy
Ask AI
// Convert Solana pubkey to bytes32 for Base contractsimport { pubkeyToBytes32 } from "./utils/pubkeyToBytes32";const bytes32Address = pubkeyToBytes32(solanaAddress);
Sol2Base is a production-ready Next.js application that demonstrates how to build a complete frontend for the Base-Solana bridge. It features a “hacker” aesthetic with Matrix-style animations and includes wallet integration, CDP faucet, ENS/Basename resolution, and real-time transaction monitoring.
# Clone and setupgit clone https://github.com/base/sol2base.gitcd sol2basenpm install --legacy-peer-deps# Environment setupcp env.template .env.local# Add Coinbase Developer Platform (CDP) API credentials for faucet (optional)# Start development servernpm run dev# Open http://localhost:3000
Get your Coinbase Developer Platform (CDP) API credentials from the the portal.The example above uses the Coinbase Developer Platform faucet for SOL.
To get access to the faucet API, you can follow the instructions here.