Escrow specification

Version 1. TernEscrow is deployed on every supported chain, with no owner and no upgrade path. Its addresses are in Contract addresses.

In short: each cross-chain swap is two deposits, one on each chain, locked to the same secret. The user’s deposit sits on the source chain and the solver’s on the destination chain. Revealing the secret pays the user first, and then lets the solver collect the user’s deposit. If the secret is never revealed, both deposits return to whoever made them. This page is the full technical specification of that mechanism, for auditors and for teams building on the contracts directly. To integrate through the API, start with How Tern works instead.

1. Summary

Tern settles cross-chain swaps as pairs of conditional transfers. On every chain, a single escrow contract holds funds under an execution condition: the SHA-256 hash of a 32-byte fulfillment. Revealing the fulfillment pays the escrow’s receiver. If the escrow reaches its expiry, the funds return to the sender. A cross-chain swap is tracked off-chain as a quote. It consists of a source escrow prepared by the user and one or more destination escrows prepared by a solver, all bound to the same execution condition. The user reveals the fulfillment to collect the destination escrows; the same fulfillment then lets the solver collect the source escrow. The design rests on five choices:

One escrow contract per chain, holding every escrow, so there is one address to index and to trust.
Absolute expiries (expiresAt, Unix seconds), never block counts, so expiries on two chains can be compared.
Escrow IDs that do not include the amount, so an actual amount can differ from the quote without breaking matching.
Deposit addresses for every escrow, so users can fund a swap with a plain transfer, including from an exchange.
No admin: no owner, pause, token allowlist, or upgrade path.

This page specifies the contracts on EVM chains and Starknet, where they are deployed. Bitcoin (Section 8) is specified for a later release.

Scope

In scope	Out of scope
Escrow contract interface and behavior on EVM and Starknet	Quote pricing and solver strategy
Deposit addresses (forwarders)	Server API shape (only the rules it must enforce)
Off-chain rules for solvers, relayers, apps, and keepers	Frontend UX
Bitcoin script (informative, for a later phase)	Fee model

Same-chain swaps do not use escrows: TernSwap is specified on its own page, TernSwap. The key words MUST, MUST NOT, SHOULD, and MAY are used as in RFC 2119.

2. Terminology

The vocabulary follows Interledger (ILPv4) and the IETF Crypto-Conditions draft, whose PREIMAGE-SHA-256 condition type is the condition used here.

Term	Meaning
Escrow	Funds held by the escrow contract under one set of terms. One escrow per chain-side of a transfer.
Escrow contract	The single settlement contract deployed on a chain.
Sender	The party whose funds an escrow holds. Receives them back on reject or expire.
Receiver	The party paid when the escrow is fulfilled.
Asset	The token held. On EVM, `0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE` denotes the native coin.
Fulfillment	A 32-byte secret.
Execution condition	`SHA-256(fulfillment)`, 32 bytes.
Expiry (`expiresAt`)	Unix timestamp in seconds. Before it, the escrow can be fulfilled. At or after it, it can be expired.
Salt	A 32-byte value chosen by the sender so one sender can hold several escrows with otherwise identical terms.
Escrow terms	The tuple that identifies an escrow: sender, receiver, asset, execution condition, expiry, salt. The amount is not part of the terms.
Escrow ID	A hash of the escrow terms, chain ID, and contract address (Section 5.2).
Prepare	Lock funds into an escrow.
Fulfill	Pay an escrow to its receiver by presenting the fulfillment.
Reject	Return an escrow to its sender before expiry, authorized by the receiver’s signature.
Expire	Return an escrow to its sender at or after expiry.
Deposit address	A counterfactual address bound to one set of escrow terms. Funds sent there are moved into the escrow by a sweep.
Sweep	Move the balance of a deposit address into its escrow, or back to the sender if the deposit is not acceptable.
Quote	The off-chain record of one swap: its source escrow and one or more destination escrows that share an execution condition.
Solver	The market participant that prepares destination escrows with its own liquidity and is the receiver of the source escrow.
Relayer	A service that submits transactions on behalf of users (gasless prepare, fulfill). It never holds user funds.
Keeper	A service that expires escrows past their expiry. Anyone can act as a keeper.

3. Design goals

Trust-minimized. No attesters, oracles, multisigs, or settlement ledger. Funds move only by the escrow rules.
One mechanism everywhere. The same terms, states, and transitions on every chain.
Amount-independent identity. Every party can compute an escrow ID before funds move, and an escrow’s identity does not change if its amount differs from the quote.
Simple to audit. Small, immutable contracts with a short list of invariants (Section 10.1).
Good UX without trust. Gasless entry, plain-transfer deposits, fast unwinds, and automatic returns.

4. Architecture

Component	Responsibility	Holds funds?
Escrow contract (per chain)	Prepare, fulfill, reject, expire, deposit addresses	Yes, under the escrow rules
Server	Quotes and solver auctions, timing rules (Section 9.2); indexing (watchers); relayer (fulfill submission); keeper (sweeps and expiries)	No
Solver	Destination liquidity; source collection	Its own funds only
App	Generates and protects the fulfillment; verifies before revealing	No

4.1 Swap lifecycle

Alternative outcomes:

Solver declines (before preparing): the solver signs a reject for the source escrow; anyone submits it and the user’s funds return immediately.
Fill below the user’s minimum: the solver prepares an additional destination escrow with the same condition for the shortfall, or both sides unwind: the solver rejects the source escrow and the user’s app rejects the destination escrows.
Nobody acts: each escrow is expired by a keeper after its expiry and returns to its sender.

5. Escrow data model

5.1 Escrow terms

struct EscrowTerms {
    address sender;
    address receiver;
    address asset;              // ERC-20, or NATIVE
    bytes32 executionCondition; // SHA-256(fulfillment)
    uint64  expiresAt;          // Unix seconds
    bytes32 salt;
}

On Starknet the same fields use ContractAddress, u256 for the condition, u64 for the expiry, and felt252 for the salt. Terms MUST satisfy:

sender != 0, receiver != 0, sender != receiver
executionCondition != 0
block.timestamp < expiresAt <= block.timestamp + MAX_DURATION at prepare time

5.2 Escrow ID

EVM:

escrowId = keccak256(abi.encode(
    ESCROW_ID_TAG,            // keccak256("TernEscrow.v1")
    block.chainid,
    address(this),
    terms.sender,
    terms.receiver,
    terms.asset,
    terms.executionCondition,
    terms.expiresAt,
    terms.salt
));

Starknet:

escrow_id = poseidon_hash_span([
    'TernEscrow.v1', chain_id, contract_address,
    sender, receiver, asset,
    condition.low, condition.high,
    expires_at, salt,
])

The amount is deliberately excluded. Off-chain services MUST implement these derivations exactly.

5.3 Stored state

The contract stores only what changes:

enum State { None, Prepared, Fulfilled, Rejected, Expired }

struct EscrowRecord {
    uint248 amount;   // fixed at prepare
    State   state;
}

mapping(bytes32 escrowId => EscrowRecord) public escrows;

Terms are not stored. Every state-changing call after prepare receives the terms in calldata, and the contract recomputes the escrow ID. Terms are always recoverable from the Prepared event.

5.4 State machine

fulfill is allowed only strictly before expiresAt; expire only at or after it. The two windows never overlap. Every escrow leaves Prepared exactly once.

6. EVM escrow contract

6.1 Interface

interface ITernEscrow {
    struct EscrowTerms {
        address sender;
        address receiver;
        address asset;
        bytes32 executionCondition;
        uint64  expiresAt;
        bytes32 salt;
    }

    struct Fulfillment {
        EscrowTerms terms;
        bytes32     fulfillment;
    }

    enum State { None, Prepared, Fulfilled, Rejected, Expired }

    event Prepared(
        bytes32 indexed escrowId,
        address indexed sender,
        bytes32 indexed executionCondition,
        address receiver,
        address asset,
        uint256 amount,
        uint64  expiresAt,
        bytes32 salt
    );
    event Fulfilled(bytes32 indexed escrowId, bytes32 fulfillment, uint256 amount);
    event Rejected(bytes32 indexed escrowId, uint256 amount);
    event Expired(bytes32 indexed escrowId, uint256 amount);
    event Swept(bytes32 indexed escrowId, address indexed depositAddress, uint256 amount);
    event Bounced(bytes32 indexed escrowId, address indexed depositAddress, address asset, uint256 amount);

    // Prepare
    function prepare(EscrowTerms calldata terms, uint256 amount) external payable returns (bytes32 escrowId);
    function prepareWithPermit2(
        EscrowTerms calldata terms,
        uint256 amount,
        ISignatureTransfer.PermitTransferFrom calldata permit,
        bytes calldata signature
    ) external returns (bytes32 escrowId);

    // Settle
    function fulfill(Fulfillment[] calldata items, uint256 minTotal) external;
    function reject(EscrowTerms calldata terms, bytes calldata receiverSignature) external;
    function expire(EscrowTerms[] calldata terms) external;

    // Deposit addresses
    function depositAddress(EscrowTerms calldata terms, uint64 depositDeadline) external view returns (address);
    function sweep(EscrowTerms calldata terms, uint64 depositDeadline) external returns (bytes32 escrowId);
    function rescue(EscrowTerms calldata terms, uint64 depositDeadline, address token) external;

    // Views
    function escrowId(EscrowTerms calldata terms) external view returns (bytes32);
    function escrows(bytes32 escrowId) external view returns (uint248 amount, State state);
    function rejectDigest(bytes32 escrowId) external view returns (bytes32);
}

6.2 `prepare`

MUST require terms.sender == msg.sender.
MUST validate the terms (Section 5.1) and 0 < amount <= type(uint248).max.
MUST require escrows[id].state == None.
Native asset: MUST require msg.value == amount. ERC-20: MUST require msg.value == 0, pull amount with transferFrom, and require that the contract’s balance increased by exactly amount. Fee-on-transfer tokens are therefore rejected.
MUST store {amount, Prepared} and emit Prepared.

6.3 `prepareWithPermit2`

Gasless creation. Anyone (normally the relayer) may submit it.

ERC-20 only.
The sender is terms.sender, which MUST be the Permit2 signer.
MUST call PERMIT2.permitWitnessTransferFrom with the escrow contract as recipient, requestedAmount = amount, owner = terms.sender, and a witness binding every term and the amount:

bytes32 constant ESCROW_WITNESS_TYPEHASH = keccak256(
    "EscrowWitness(address sender,address receiver,address asset,bytes32 executionCondition,uint64 expiresAt,bytes32 salt,uint256 amount)"
);

string constant WITNESS_TYPE_STRING =
    "EscrowWitness witness)EscrowWitness(address sender,address receiver,address asset,bytes32 executionCondition,uint64 expiresAt,bytes32 salt,uint256 amount)TokenPermissions(address token,uint256 amount)";

Permit2 provides the nonce and deadline. The rest follows prepare steps 2–5.

Because the signature covers every term, a copied signature can only create the exact escrow the sender signed.

6.4 `fulfill`

fulfill(items, minTotal) settles one or more escrows. For each item:

Recompute id from item.terms.
MUST require state == Prepared and block.timestamp < terms.expiresAt.
MUST require sha256(abi.encodePacked(item.fulfillment)) == terms.executionCondition.
Set state = Fulfilled before transferring.
Transfer the full amount to terms.receiver. Native transfers MUST forward all remaining gas (no stipend). A failed transfer MUST revert.
Emit Fulfilled(id, fulfillment, amount).

If minTotal > 0, every item MUST share the same receiver and asset, and the sum of amounts paid MUST be at least minTotal. This is the slippage guard: the relayer passes the user’s minimum for the whole destination side of a quote. Solvers settling source escrows pass minTotal = 0. Anyone may call fulfill. Funds only ever go to each escrow’s receiver.

A transaction that reverts still publishes its calldata. Any party revealing a fulfillment MUST simulate fulfill first and broadcast only if the simulation succeeds (Section 9.4). Escrow amounts never change after prepare, so a passing simulation stays valid until the escrow expires.

6.5 `reject`

Early return, authorized by the receiver.

MUST require state == Prepared.
MUST verify receiverSignature from terms.receiver over the EIP-712 message below, using ERC-1271 for contract receivers.

// Domain: name "TernEscrow", version "1", chainId, verifyingContract
bytes32 constant REJECT_TYPEHASH = keccak256("Reject(bytes32 escrowId)");

Set state = Rejected, transfer amount to terms.sender, emit Rejected.

A reject signature is single-use because the escrow can only leave Prepared once, and it cannot be replayed on another chain or contract because the escrow ID binds both. Uses:

the solver rejects a source escrow it will not fill, so the user is repaid immediately
the user’s app rejects destination escrows when it declines a fill, so the solver is repaid immediately

6.6 `expire`

For each terms entry: MUST require state == Prepared and block.timestamp >= terms.expiresAt; set state = Expired; transfer amount to terms.sender; emit Expired. Anyone may call it.

6.7 Deposit addresses

Every escrow can be funded through a deposit address bound to its terms and a deposit deadline.

depositId      = keccak256(abi.encode(escrowId, depositDeadline))
depositAddress = CREATE2(escrowContract, depositId, initCodeHash(DepositForwarder clone))

DepositForwarder is a minimal clone with no arguments. It accepts native coin, and exposes one function, transferAll(asset, to), callable only by the escrow contract. sweep(terms, depositDeadline), callable by anyone:

Compute id, depositId, and the deposit address; deploy the forwarder clone if it has no code.
Read the forwarder’s balance of terms.asset. MUST require it to be non-zero.
If all of the following hold, the deposit is accepted:
- escrows[id].state == None
- block.timestamp <= depositDeadline < terms.expiresAt
- the terms are valid (Section 5.1)
The forwarder transfers its full balance to the escrow contract. The escrow is created with amount equal to the balance actually received, and Prepared and Swept are emitted. There is no minimum on-chain; solvers decide whether to fill.
Otherwise the forwarder transfers its full balance to terms.sender and emits Bounced.

rescue(terms, depositDeadline, token), callable by anyone, sends the forwarder’s full balance of any token != terms.asset to terms.sender. It covers wrong-token deposits.

Case	Result
Exact amount before the deadline	Escrow created
More or less than quoted	Escrow created for the actual amount
Arrives after the deposit deadline	Bounced to sender
Arrives after the escrow already exists	Bounced to sender
Wrong token	Returned by `rescue`

For deposit addresses, terms.sender is the user’s refund address on the source chain. It MUST be an address the user controls, never an exchange deposit address.

6.8 General requirements

No owner, pause, whitelist, upgradeability, or selfdestruct.
Reentrancy guard (transient storage) on every state-changing function, in addition to checks-effects-interactions.
MAX_DURATION = 30 days.
PERMIT2 is the canonical address 0x000000000022D473030F116dDEE9F6B43aC78BA3.
Rebasing tokens are unsupported. Tokens with blocklists are supported, subject to the simulation rule in Section 6.4.

7. Starknet escrow contract

The Starknet contract implements the same model with these differences.

Topic	Starknet behavior
Native coin	None. ETH and STRK are ERC-20s; there is no `NATIVE` sentinel.
Gasless prepare	No permit function. Wallets submit `[approve, prepare]` as one multicall, gasless through a paymaster or SNIP-9 outside execution. In both cases the caller is the user’s account, so `sender == get_caller_address()` still holds.
Fulfillment hashing	The 32-byte fulfillment is passed as `u256` (big-endian), split into eight `u32` words, and hashed with `core::sha256::compute_sha256_u32_array`. The result MUST equal the EVM `sha256(abi.encodePacked(bytes32))` of the same bytes.
Escrow ID	Poseidon (Section 5.2).
Reject signature	SNIP-12 (revision 1) typed data `Reject { escrow_id: felt }` with domain name `TernEscrow`, version `v1` (the short string `'v1'`), verified through the receiver account’s SRC-6 `is_valid_signature`, which must return `'VALID'` or `1` (returned by older account implementations); any other value fails the reject. The version is not numeric because starknet.js, and so most wallets, encodes a numeric string such as `"1"` as the number 1, while Cairo’s `'1'` is the short string 0x31; `'v1'` has one encoding everywhere.
Deposit addresses	The escrow contract deploys a `DepositForwarder` class with `deploy_syscall`, salt `poseidon_hash_span([escrow_id, deposit_deadline])` (starknet.js `hash.computePoseidonHashOnElements`, not the two-input `computePoseidonHash`), and constructor calldata `[escrow_contract]`. The address is computed with the standard Starknet contract-address formula. The forwarder class hash is fixed at construction and can never change.

7.1 Interface

#[derive(Copy, Drop, Serde)]
pub struct EscrowTerms {
    pub sender: ContractAddress,
    pub receiver: ContractAddress,
    pub asset: ContractAddress,
    pub execution_condition: u256,
    pub expires_at: u64,
    pub salt: felt252,
}

#[derive(Drop, Serde)]
pub struct Fulfillment {
    pub terms: EscrowTerms,
    pub fulfillment: u256,
}

#[starknet::interface]
pub trait ITernEscrow<T> {
    fn prepare(ref self: T, terms: EscrowTerms, amount: u256) -> felt252;
    fn fulfill(ref self: T, items: Array<Fulfillment>, min_total: u256);
    fn reject(ref self: T, terms: EscrowTerms, receiver_signature: Array<felt252>);
    fn expire(ref self: T, terms: Array<EscrowTerms>);
    fn deposit_address(self: @T, terms: EscrowTerms, deposit_deadline: u64) -> ContractAddress;
    fn sweep(ref self: T, terms: EscrowTerms, deposit_deadline: u64) -> felt252;
    fn rescue(ref self: T, terms: EscrowTerms, deposit_deadline: u64, token: ContractAddress);
    fn escrow_id(self: @T, terms: EscrowTerms) -> felt252;
    fn get_escrow(self: @T, escrow_id: felt252) -> (u256, State);
    fn reject_hash(self: @T, escrow_id: felt252, receiver: ContractAddress) -> felt252;
    fn forwarder_class_hash(self: @T) -> ClassHash;
}

Events mirror the EVM events with snake-case fields. escrow_id, sender, and execution_condition are keys.

An undeployed Starknet account cannot validate signatures, so a receiver with an undeployed account cannot sign a reject. Destination escrows paying such receivers can only be fulfilled or expired.

8. Bitcoin (informative)

Not deployed. The same terms map onto a Taproot output.

Internal key: unspendable NUMS point (script-path spends only)

Leaf 1  fulfill:  OP_SIZE 32 OP_EQUALVERIFY
                  OP_SHA256 <executionCondition> OP_EQUALVERIFY
                  <receiver x-only key> OP_CHECKSIG

Leaf 2  expire:   <expiresAt> OP_CHECKLOCKTIMEVERIFY OP_DROP
                  <sender x-only key> OP_CHECKSIG

Leaf 3  reject:   <sender x-only key> OP_CHECKSIGVERIFY
                  <receiver x-only key> OP_CHECKSIG

expiresAt is a Unix timestamp, at least 500,000,000, so OP_CHECKLOCKTIMEVERIFY compares it against median time past. Median time past lags wall-clock time by roughly an hour; Section 9.2 accounts for this.
Expire transactions MUST set nLockTime >= expiresAt and an input nSequence below 0xffffffff, otherwise the timelock is not enforced.
The Taproot address is itself the deposit address. Each UTXO paid to it is one escrow, identified by its outpoint; several UTXOs with the same condition are fulfilled together.
The amount is the UTXO value and is not part of the script, consistent with Section 5.2.

9. Off-chain protocol rules

9.1 Quotes

A quote record contains at least:

Field	Description
`quoteId`	Server identifier.
`executionCondition`	Unique per quote. MUST NOT be reused across quotes.
Source	chain, asset, quoted amount, escrow terms, `depositDeadline`
Destination	chain, asset, receiver, `minAmount`, expected `expiresAt`
Solver	Receiver of the source escrow and sender of the destination escrows.

Escrows are linked to a quote through the execution condition, which is an indexed field of Prepared. The source escrow ID can be computed before funding; additional destination escrows are discovered by condition.

9.2 Timing

Each chain c has:

Parameter	Meaning	Default
`skew(c)`	Maximum lag between real time and the time the chain uses for expiry	EVM and Starknet: 60 s. Bitcoin: 2 h
`confirm(c)`	Time the solver waits before treating a source escrow as final	Solver policy

Global parameters:

Parameter	Meaning	Default
`settleWindow`	Time the solver needs to fulfill the source after the fulfillment appears on the destination	1 h (2 h if the source is Bitcoin)
`minFulfillWindow`	Minimum time a destination escrow must have left when the user reveals	30 min

The server MUST reject any quote where:

source.expiresAt < destination.expiresAt + settleWindow + skew(source) + skew(destination)

The values in use, measured from the time a firm quote is made:

Deadline	Value
Deposit deadline (the quote’s `expiresAt`), for a wallet deposit or a deposit address	30 minutes
Destination escrows’ `expiresAt`	4 hours
Source escrow’s `expiresAt`	The formula above, rounded up to the hour: 5 to 6 hours

9.3 Solver rules before preparing a destination escrow

The solver MUST:

Compute the expected source escrow ID from the quote and read it on-chain. It MUST be Prepared.
Check the on-chain terms: receiver is the solver, the asset and condition match the quote, and the amount is acceptable for the price it intends to deliver.
Check source.expiresAt - now is large enough for the destination expiry plus the margins in Section 9.2.
Wait confirm(source chain).

If it will not fill, the solver SHOULD sign a reject for the source escrow so the user is repaid immediately.

9.4 App and relayer rules before revealing a fulfillment

The fulfillment MUST be generated from a CSPRNG (32 bytes) and MUST NOT leave the app until every check below passes:

Find all destination escrows with the quote’s condition on the destination chain.
Each MUST be Prepared, pay the user’s receiver, use the expected asset, and have at least minFulfillWindow left.
The sum of their amounts MUST be at least the user’s minAmount.
Simulate fulfill(items, minAmount) against current state. Broadcast only if it succeeds, through private submission where available.

The app reads chain state directly through RPC and MUST NOT rely only on server status. If the fill is below the minimum, the app SHOULD wait briefly for the solver to add an escrow for the shortfall, then sign rejects for the destination escrows and expect the solver to reject the source escrow.

9.5 Keepers

Keepers SHOULD call expire for every escrow past its expiry. Payments only go to senders, so anyone can run a keeper. Combined with deposit addresses, a user who funds an escrow either receives the swap or gets funds back without further action.

9.6 Watchers

One contract address per chain to index.
Events carry full terms, so watchers rebuild escrow state from logs alone.
Watchers MUST persist their cursor, wait chain-specific confirmations, and handle reorgs by re-reading from a safe block.

10. Security considerations

10.1 Invariants

ID	Invariant
I1	An escrow’s amount is fixed at prepare. Funds leave an escrow only through fulfill, reject, or expire.
I2	Each escrow leaves `Prepared` at most once.
I3	Fulfill is possible only before `expiresAt`; expire only at or after it.
I4	Only the sender can create an escrow naming them as sender directly or by Permit2 signature. Through a deposit address anyone can fund an escrow under the sender’s terms; its funds still go only to the receiver on fulfill or back to the sender, so the most a third party can do is occupy the ID (Section 10.2).
I5	Fulfill pays only `terms.receiver`. Reject, expire, bounce, and rescue pay only `terms.sender`.
I6	For each asset, the contract’s balance is at least the sum of amounts of escrows in `Prepared`.

10.2 Threats and mitigations

Threat	Mitigation
A copied signature redirects funds	The Permit2 witness binds every term and the amount (Section 6.3).
Third party occupies an escrow ID	Escrow IDs include the sender, and only the sender can call `prepare` (I4). Anyone who knows the terms can still fund a deposit address for them and sweep it first, occupying the ID with a small amount. This is griefing only: the user’s own `prepare` reverts or their deposit bounces back to them, and no funds are lost. The app retries with a new execution condition, which gives a new ID. Applies on every chain.
Dust escrow tricks a solver into filling	Solvers verify the expected source escrow ID and amount on-chain (Section 9.3).
Fulfillment leaked by a reverted transaction	Simulate before broadcasting (Section 9.4).
Fulfill and expire race after expiry	Disjoint windows (I3).
Cross-chain expiry inversion (block-based expiries drifting apart between chains)	Absolute timestamps plus the server timing rule (Section 9.2).
Reused execution condition	A revealed fulfillment unlocks every escrow with that condition for its receiver. Apps MUST never reuse a condition.
Reject signature replay	The escrow ID binds chain and contract; state allows a single transition.
Reentrancy	Checks-effects-interactions plus a reentrancy guard.
Native payout to contract wallets	All gas forwarded; failures revert and are caught by simulation.
Fee-on-transfer tokens	Exact balance-delta check at prepare and sweep.
Deposit sent after the window, twice, or in the wrong token	Bounce and rescue to the sender (Section 6.7).
Bitcoin timelock not enforced	`nSequence` and `nLockTime` requirements (Section 8).
No pause	Incident response is off-chain: stop quoting, stop solver fills. Existing escrows still settle or expire by their rules.

10.3 Trust assumptions

Users trust only the escrow contract code and their own app’s verification. They do not trust the server (including its relayer), the solver, or keepers.
Solvers trust the escrow contract and their own confirmation policy for source chains.
Availability (RPCs, relayers, keepers) affects speed, not safety.

Get started

Concepts

Guides

Protocol

Escrow specification

1. Summary

Scope

2. Terminology

3. Design goals

4. Architecture

4.1 Swap lifecycle

5. Escrow data model

5.1 Escrow terms

5.2 Escrow ID

5.3 Stored state

5.4 State machine

6. EVM escrow contract

6.1 Interface

6.2 `prepare`

6.3 `prepareWithPermit2`

6.4 `fulfill`

6.5 `reject`

6.6 `expire`

6.7 Deposit addresses

6.8 General requirements

7. Starknet escrow contract

7.1 Interface

8. Bitcoin (informative)

9. Off-chain protocol rules

9.1 Quotes

9.2 Timing

9.3 Solver rules before preparing a destination escrow

9.4 App and relayer rules before revealing a fulfillment

9.5 Keepers

9.6 Watchers

10. Security considerations

10.1 Invariants

10.2 Threats and mitigations

10.3 Trust assumptions

​1. Summary

​Scope

​2. Terminology

​3. Design goals

​4. Architecture

​4.1 Swap lifecycle

​5. Escrow data model

​5.1 Escrow terms

​5.2 Escrow ID

​5.3 Stored state

​5.4 State machine

​6. EVM escrow contract

​6.1 Interface

​6.2 prepare

​6.3 prepareWithPermit2

​6.4 fulfill

​6.5 reject

​6.6 expire

​6.7 Deposit addresses

​6.8 General requirements

​7. Starknet escrow contract

​7.1 Interface

​8. Bitcoin (informative)

​9. Off-chain protocol rules

​9.1 Quotes

​9.2 Timing

​9.3 Solver rules before preparing a destination escrow

​9.4 App and relayer rules before revealing a fulfillment

​9.5 Keepers

​9.6 Watchers

​10. Security considerations

​10.1 Invariants

​10.2 Threats and mitigations

​10.3 Trust assumptions

1. Summary

Scope

2. Terminology

3. Design goals

4. Architecture

4.1 Swap lifecycle

5. Escrow data model

5.1 Escrow terms

5.2 Escrow ID

5.3 Stored state

5.4 State machine

6. EVM escrow contract

6.1 Interface

6.2 `prepare`

6.3 `prepareWithPermit2`

6.4 `fulfill`

6.5 `reject`

6.6 `expire`

6.7 Deposit addresses

6.8 General requirements

7. Starknet escrow contract

7.1 Interface

8. Bitcoin (informative)

9. Off-chain protocol rules

9.1 Quotes

9.2 Timing

9.3 Solver rules before preparing a destination escrow

9.4 App and relayer rules before revealing a fulfillment

9.5 Keepers

9.6 Watchers

10. Security considerations

10.1 Invariants

10.2 Threats and mitigations

10.3 Trust assumptions