The Three Steps
1. Validate
- Address validity — Is the format correct for each chain?
- Token registration — Is this token supported by the bridge?
- Amount normalization — Will this amount survive decimal conversion? (See Decimal Normalization)
- Fee structure — Are the fee amounts valid?
ValidationError with a specific error code.
2. Build
| Chain | Return Type | Works With |
|---|---|---|
| EVM | { to, data, value, chainId } | viem, ethers |
| NEAR | { signerId, receiverId, actions } | near-kit, @near-js/* (via shims) |
| Solana | TransactionInstruction[] | @solana/web3.js |
- Contract addresses for the current network
- Function call encoding
- Gas limits and deposits (where applicable)
3. Sign & Send
What Happens After You Send
Once your transaction confirms on the source chain:- Proof generation — The bridge infrastructure creates a cryptographic proof of your transfer
- Relayer pickup — If you included fees, relayers compete to finalize your transfer
- Finalization — The relayer submits the proof to the destination chain
- Delivery — Tokens arrive in the recipient’s account
With and Without Relayers
You have two options for finalization:| Approach | How It Works | When to Use |
|---|---|---|
| With fees | Relayers finalize automatically | Most use cases — simple, reliable |
| Without fees | You finalize manually | Cost savings, custom timing needs |
fee and/or nativeFee > 0):
The ValidatedTransfer Object
After validation, you get an object containing everything the builders need:Error Handling
Validation errors have specific codes you can handle:Chain-Specific Details
While the pattern is the same, each chain has quirks:- EVM: Requires a separate approval transaction for ERC20 tokens
- NEAR: Requires storage deposits before first transfer
- Solana: Returns instructions, not a complete transaction
- Bitcoin: Uses a different flow entirely (deposit address + finalization)