Skip to main content
When you set 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:
  1. Initiate transfer (ft_transfer_call)
  2. Call signTransfer to trigger MPC signing
  3. Parse the SignTransferEvent from logs
  4. Submit finalization on destination chain
From EVM/Solana:
  1. Initiate transfer on source chain
  2. Wait for proof to become available (Merkle proof or Wormhole VAA)
  3. Submit finalization on NEAR
The proof type and wait time depends on the source:

When is Finalization Ready?

Poll the API for the Signed status:
For Ethereum → NEAR specifically, you need to wait for the light client to sync the block (check 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 call signTransfer to trigger MPC signing:

Step 3: Finalize on EVM

Parse the SignTransferEvent 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 a buildFinalization method:

Working Examples

For complete, runnable examples:

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