fee: 0n and nativeFee: 0n, relayers won’t process your transfer. You finalize it yourself on the destination chain.
When to use this:
- Cost savings on high-volume transfers
- Running your own relayer infrastructure
- Specific timing or ordering requirements
The Process
The steps depend on your source chain: From NEAR:- Initiate transfer (
ft_transfer_call) - Call
signTransferto trigger MPC signing - Parse the
SignTransferEventfrom logs - Submit finalization on destination chain
- Initiate transfer on source chain
- Wait for proof to become available (Merkle proof or Wormhole VAA)
- Submit finalization on NEAR
When is Finalization Ready?
Poll the API for theSigned status:
Initialized status and wait ~15-20 min).
From NEAR to EVM
NEAR → EVM transfers require three steps: initiate, sign, then finalize.Step 1: Initiate the Transfer
Step 2: Sign the Transfer
After the transfer is initialized, you must callsignTransfer to trigger MPC signing:
Step 3: Finalize on EVM
Parse theSignTransferEvent from the sign transaction logs and finalize on EVM:
The MPC signature needs format conversion for EVM — use
MPCSignature.toBytes(true) to add 27 to the recovery ID. For Solana, use toBytes(false).From EVM to NEAR
Ethereum (Merkle Proof)
Ethereum uses the NEAR light client for verification:L2s (Wormhole VAA)
Base, Arbitrum, Polygon, and BNB use Wormhole:From Solana to NEAR
Solana also uses Wormhole VAAs:Finalization Builders
Each destination has abuildFinalization method:
Working Examples
For complete, runnable examples:- NEAR → EVM:
e2e/near-to-eth.test.ts - EVM → NEAR:
e2e/eth-to-near.test.ts
Consider Using Relayers Instead
Manual finalization adds complexity. Use relayer fees if:- You want fire-and-forget simplicity
- The fee cost is acceptable
- You don’t need precise timing control