What changes vs. EVM destinations
| EVM destination | Non-EVM destination | |
|---|---|---|
targetChain | viem Chain | solanaMainnet / tronMainnet |
recipient | Address | base58 (Solana) / Tron T-prefix string |
tokenRequests[].address | EVM Address or TokenSymbol | SPL mint / TRC-20 contract string |
Destination calls | supported | not supported (claims only) |
| UserOp path | supported | not supported |
fillTransactionHash | Hex | string (base58 / Tron hex) |
Example: USDC from Base to Solana
solanaMainnet for tronMainnet and pass a Tron T-prefix recipient and a TRC-20 contract address to bridge to Tron instead.
Constraints
- No destination calls. Solana and Tron destinations are claim-only — you can’t pass a
callsarray on a non-EVM intent. If your flow needs onchain logic on the destination, route to an EVM chain. - No UserOp path.
sendUserOperationand the UserOp transaction shape remain EVM-only. - No destination-side signing. Smart-session destination signatures are skipped on non-EVM chains — there’s no validator there to verify them. Origin signing is unchanged.
- EIP-7702 authorization is a no-op on non-EVM destinations.
fillTransactionHashis a plain string. WasHexon EVM destinations; widened so base58 and Tron hex round-trip cleanly.
Tracking the intent
waitForExecution and getIntentStatus work the same way as for EVM destinations. Inspect status.operations[] for per-chain transaction hashes — the destination entry’s fillTransactionHash will be a base58 (Solana) or hex (Tron) string.