Do not trust the tracker. Recompute it.
Every commitment an escrow deal makes is a hash anyone can recompute. The verifier further down runs the whole scheme inside your browser, over inputs you supply and reads from a public chain, and tells you whether they reproduce the values you were shown. It never asks our server for the answer, only for data, the same standard the Free Roll verifier already set.
What is committed, and how
1. The terms are hashed
Every field you both agreed, from the addresses and the amount down to each deadline window and a random salt, is packed in a fixed order and hashed with keccak256. That one value is the terms hash, and there is exactly one set of terms that produces it.
2. The deal id pins it to one contract
The deal id is the hash of a fixed prefix, the chain id, the contract address and the terms hash together. So a deal id does not just commit to the terms, it commits to which chain and which contract the money sits in. The same terms on another chain are a different deal.
3. Settlement is arithmetic
Who gets what is a pure function of the deal's own fields and the outcome. The contract refuses any settlement that does not pay out exactly what was paid in, and the same arithmetic runs on this page, so you can check any split to the base unit.
4. Rulings chain into one log
Each published ruling is hashed with sha256, each entry carries the hash of the one before it, and the arbiter transaction commits the hash on chain before the money moves. Editing an entry breaks its hash, removing one breaks the chain, and both are checks your browser runs itself.
The exact scheme
No paraphrase. This is what the contract and this page both compute, stated fully enough to reimplement from scratch without reading our code.
termsHash = keccak256(
TERMS_TYPEHASH a fixed 32 byte constant, published in the repository
buyer, seller, arbiter, token each address as a 32 byte word
amount uint256, one 32 byte word
buyerBond, sellerBond uint96, each padded to a 32 byte word
feeBps uint16, padded to a 32 byte word
fundingWindow, deliveryWindow,
inspectionWindow, rulingWindow uint24 seconds, each padded to a 32 byte word
salt bytes32
) all fields concatenated in this exact order
dealId = keccak256(
DEAL_ID_PREFIX a fixed 32 byte constant
chainId uint256
contract address padded to a 32 byte word
termsHash
)
ruling bytes = the published document as canonical JSON:
keys sorted ascending by code unit, no whitespace, integers only,
printable ASCII only, absent values written as the literal null
rulingHash = sha256(ruling bytes)
prevRulingHash = the previous entry's rulingHash. Sequence 1 points at 32 zero bytes.
The arbiter's transaction carries rulingHash on chain before funds move.One detail is worth calling out, because it is where an independent reimplementation is most likely to disagree with a correct contract. The ruling bytes are canonical on purpose: keys are sorted by code unit, not by locale, there is no whitespace, and an absent value is the literal null rather than an omitted key, because an omitted key and a null key are different bytes and only one of them is what was hashed. The verifier below hashes the exact bytes the log serves, so a document that was reordered, reworded or trimmed after publication cannot reproduce its own recorded hash.
Verify it in your browser
Your browser cannot talk to a chain directly from this page, so chain reads go through a read only proxy on our API that answers five fixed questions about the one deployed contract per chain and nothing else. Everything it returns is an input. Every verdict below is computed on your machine.
The deployed contracts
One contract per chain, not upgradeable, no proxy. These addresses are the whole allowlist: the read proxy this page uses will not touch any other contract, and neither should you. Escrow runs on test networks today, so a chain that does not answer here is a chain nothing is deployed to.
Asking each chain…
Check a deal's terms commitment
Paste the terms exactly as they were agreed and this recomputes the terms hash and the deal id in your browser. If they reproduce the deal id you hold, the terms you are looking at are the terms the contract holds the money under, with no room for a quietly edited version. Pick a chain above and the money fields can be read straight off the contract; the windows and the salt come from your own copy of the terms.
Recompute a settlement
The split of a settled deal is pure arithmetic over the deal's own fields, so you can rerun it here for any outcome. Reading a deal above fills this in, including the outcome the chain recorded. What comes out is what the contract credited, to the base unit, or the contract could not have settled at all: it refuses any settlement that does not pay out exactly what was paid in.
Check a published ruling and the whole chain behind it
Paste a ruling id from the rulings log. Your browser fetches the published text, hashes it, walks every link back to the first ruling ever published, recomputing each one's hash on the way, and compares the result against what the arbiter's transaction committed on chain. The two optional fields let a party also check the log against what their own deal card said.
What this does and does not prove
It proves the record was not tampered with
Terms that reproduce the deal id are the terms the money sits under, on that chain, at that contract, with no version of them anyone edited afterwards. A ruling whose text hashes to its record, whose chain joins all the way back to the first entry, and whose hash matches what the arbiter committed on chain, is the ruling that was actually made, in a log nothing was deleted from.
It does not prove a deal was wise
Integrity is about the record, not the judgement. A verified commitment can still be a deal you should not have taken, a verified ruling can still be one you disagree with, and no hash makes a counterparty honest. The escrow page states the one residual the contract cannot remove, and it applies here unchanged.
The modules this page runs are pinned, byte for byte, against test vectors emitted by the deployed contract's own bytecode, and the same check runs on our side as pnpm check:escrow-parity before any deploy. That is the operator half of what you are doing here: we prove our twin agrees with the contract, and you prove the published record agrees with the twin, so at no point is anybody just taking our word.