Overview
The three layers that make up the Cross-Chain Swap Engine and how they fit together.
The platform separates cleanly into three layers, each with a different role and a different trust profile.
Settlement layer
The on-chain layer is where the protocol's safety property lives. It consists of a DAML package on Canton and a single Solidity contract on Ethereum. Together they enforce that either both sides of a swap settle or both sides refund.
The settlement layer:
Holds locked assets during the lock window. Locked assets are signatory-restricted to the locker; neither Interstice nor the counterparty has authority to move them.
Enforces time-locks for refund. The two locks have independent deadlines.
Charges platform fees on settlement only. Refunds carry no fee.
See The Canton side and The Ethereum side for the contracts in detail.
Coordination layer
The off-chain coordination layer routes RFQs, records reported transitions, and exposes status. It is on the coordination path but not the settlement path — a swap can settle or refund without it.
The coordination layer:
Broadcasts RFQs to eligible counterparties.
Routes quotes back to users.
Issues quote commitments at selection.
Records reports of each on-chain step. Reports are independently verified against the chain — the orchestrator does not trust either side's reports without checking.
Exposes status via a REST API.
The orchestrator does not hold keys. It does not sign settlement transactions. It does not generate secrets. If it is offline, in-flight swaps can still settle through direct interaction with the on-chain contracts.
See Coordination layer for details.
Verification layer
The verification layer is operated by Interstice Identity. It is upstream of the coordination layer and gates which entities can participate in swaps at all.
Verification covers:
Sanctions screening, also through Trulioo.
Wallet screening of the on-chain addresses an entity uses, through TRM Labs.
Terms acceptance against the current Cross-Chain Swap Engine terms.
Verification status is checked at RFQ submission. It is not checked at settlement time — once a swap is in flight, the on-chain contracts settle it without consulting verification. This keeps the settlement layer simple and avoids creating new failure modes.
See Verification for the public-facing detail.
Why the layers are split this way
The split between layers is a security-and-trust split, not an engineering convenience.
Settlement on-chain, signed by the parties themselves. Interstice cannot move locked funds.
Coordination off-chain, by Interstice. This is where the RFQ marketplace and status surface live, but its failure does not put assets at risk.
Verification off-chain, by Interstice and its compliance vendors. Verification gates entry. It does not gate exit (refund). A user whose verification lapses mid-swap is not stranded.
Each layer has a narrower scope than the layer above it. The result is that even if the orchestrator is fully offline and verification is unavailable, an in-flight swap still settles or refunds correctly because the on-chain contracts do not depend on the off-chain layers at settlement.
Where to next
The Canton side — what the DAML package does.
The Ethereum side — what the Solidity contract does.
Coordination layer — what the orchestrator does and does not do.
Last updated