Pre-launch: these are the mainnet networks and contracts the service will run on at launch.
Supported chains
- Key is the chain’s name everywhere in the API, the SDK and the MCP.
- Family decides the address format and how a transaction is signed and broadcast.
- Leg timelock is the chain’s safe timelock. How a pair of chains turns into the two legs’ timelocks is in HTLC and timelocks.
- Keeper claims for you: once the secret is revealed, Hashlock’s keeper claims that leg to its fixed recipient, so the counterparty does not have to. A Bitcoin claim needs the receiver’s own signature, so the receiver claims it.
GET /v1/assets (MCP: list_assets). An asset is { chain, symbol, address, decimals }, where address is the token contract and null means the chain’s native coin.
HTLC contracts
- On EVM chains the factory deploys one escrow clone per leg at a deterministic address, so you can check the exact escrow before funding. The settlement builders return the address; you never pass a contract address yourself.
- On TRON one pool contract holds every escrow; on Solana each escrow is a PDA of the program.
- How each one works is in Settlement by chain.
How to name a chain
The same token on two chains is two assets:
USDC@ethereum, USDC@base and USDC@solana are different, and a swap between them is a cross-chain swap.
On EVM chains, sign with the chainId the fund builder returns, not your wallet’s current network.
Confirmations
A leg counts as funded — and a claim or refund as done — only once the watcher sees it buried deep enough that a reorganisation cannot undo it. Until then the swap stays in its previous state.
So the time from broadcast to “funded” is mostly the chain’s: a Bitcoin funding takes three blocks, each about ten minutes on average and sometimes much longer. Do not fund the next leg, or treat a leg as settled, before
GET /v1/swaps/{id} (or the swap.* webhooks) says so.