Hash time-locked contracts
Each leg of a swap is an HTLC escrow with two ways out:- Claim: anyone presenting the
secretwhosesha256equals the hashlock releases the funds to the leg’s recipient. - Refund: after the leg’s timelock, the funds go back to the funder.
sha256 on every chain
Both legs use the same hashlock, sha256(secret), and the secret is 32 bytes.
- Why sha256: Bitcoin Script has
OP_SHA256but no keccak. Usingsha256everywhere lets one secret open a Bitcoin P2WSH escrow and an EVM, TRON or Solana escrow alike. The EVM and TRON contracts computesha256, notkeccak256. - Why exactly 32 bytes: the EVM and TRON contracts take the secret as
bytes32, and the Solana program enforces the same length. A longer preimage could open one leg but not the other. - Format in the API:
hashlockis 64 hex characters (no0x). Thesecretsent to the claim builder is 32-byte hex.
Asymmetric timelocks
The two legs do not expire at the same time.- The initiator holds the secret and funds the long leg.
- The counterparty funds the short leg.
How the server picks them
Each chain has a safe timelock, set from its finality and reorg risk. The current values in the server’s chain config are:
For a pair of chains:
- The leg on the chain with the longer safe timelock is the long (initiator) leg. On a tie, leg
b— the taker’s — is the long leg. - The short leg gets its chain’s timelock.
- The long leg gets
max(its chain's timelock, short leg + 2 hours). The minimum gap between the legs is 2 hours.
- BTC ↔ Sepolia: the Bitcoin leg is long at 24 h, the EVM leg is short at 4 h.
- Sepolia ↔ Solana (tie): the short leg is 4 h, the long leg is 6 h.
GET /v1/swaps/{id} shows them per leg.
On Bitcoin, a refund’s timelock is measured against the chain’s median time past, which trails real time. A refund built just after the timelock may be rejected by nodes as non-final; the refund builder says so and tells you how far behind the chain clock is.