This is the test version. It runs on Arbitrum Sepolia, Arbitrum's test network, with test tokens. The real one runs on Arbitrum One.
In one paragraph
A deal is a record in an escrow smart contract on Arbitrum One, an Ethereum layer 2. The buyer locks the price in USDC or USDT. The seller transfers the domain, and a zkTLS proof of the registry's own RDAP record shows the contract that it arrived at the buyer's registrar. After a challenge window the contract pays the seller. If either side objects, Kleros, a decentralised court, decides. No step needs Yescrow's permission, and nothing lets Yescrow move the money.
The escrow contract
- No admin keys. There is no owner, pause, upgrade, proxy or recovery function. Every setting (the token, the proof verifiers, the Kleros court, the fee) is fixed when the contract is deployed. A new version is a new deployment, and a deal stays on the version it was made on.
- Only the deal's parties get paid. Every payout goes to the buyer, the seller, the fee address, the referrer, or the court's own fee. Anyone may trigger a payout once its conditions are met, but no caller can change where the money goes.
- Pull payments. Payouts are credited to balances and each party withdraws their own, so a blocked address on one side can't trap the other side's money. A party can sign the withdrawal in advance, so it arrives without a return visit.
- Our fee is 1% (100 basis points) of the seller's payout, taken when the seller is paid. If someone referred the deal, a quarter of the fee goes to them.
- The source is verified on Arbiscan: the addresses.
The money: USDC and USDT
A deal holds a dollar stablecoin: Circle's USDC, or Tether's USDT (USDT0 on Arbitrum One). Each token has its own deployment of the same escrow contract. Both issuers can blacklist an address, which freezes the tokens at it, including at the escrow. Yescrow can't prevent that; the pull payments above keep a freeze on one party from trapping the other.
- From a wallet, the buyer signs an EIP-3009
receiveWithAuthorizationfor exactly the price, and Yescrow's relayer submits it, so the buyer needs no ETH for gas. Every step is an EIP-712 signature the wallet shows in full. - From an exchange, the buyer sends the price to the deal's deposit address: a CREATE2 address computed from the escrow, the deal ID and the buyer, so it commits to every term of the deal. Once the money arrives, anyone can sweep it into the deal. If the deal never starts, it goes back to the buyer.
- The deal ID is the keccak256 hash of the terms, the proposer and a nonce, so a signature for one deal can't be used for another.
The proof: zkTLS on the registry's RDAP record
Every domain ending has a registry (Verisign for .com), and every registry runs a public RDAP server that says which registrar holds each domain, by its IANA Registrar ID. A zkTLS proof shows that a given RDAP response really came from the registry's server over HTTPS, without trusting whoever fetched it.
- Two attestors. Each proof needs two signatures over the same TLS session: one from Reclaim Protocol's attestor and one from Yescrow's. Forging a proof would take both keys, and the buyer's challenge window is the backstop.
- The verifier contract checks both signatures, that the TLS server name and request path match the deal's domain and its registry, and that the whole response is revealed. It extracts the registrar ID, status codes, expiry date and nameservers. A registrar's own RDAP server isn't accepted.
- A move between registrars takes two proofs. The “before” proof, at acceptance, shows the domain at another registrar. The “after” proof shows it at the buyer's registrar, with no transfer lock, hold or pending delete, and at least 30 days to expiry.
- A push inside one registrar never shows in RDAP. Its proof shows only that the nameservers changed to the buyer's, so it is weaker and gets a longer challenge window.
- What a proof can't show is which account holds the domain. That is what the challenge window is for: the buyer logs in at their registrar, and challenges if the domain isn't there.
Deadlines
The terms fix every deadline when the deal is proposed, and anyone can call the contract once one passes, so a party who goes quiet can't stall a deal. Yescrow's keeper does it within a minute.
| Deadline | Default |
|---|---|
| Accept | 72 hoursIf the other side doesn't accept, the proposal expires and the money goes back. |
| Transfer | 10 days (5 for a push)No passing proof by then, and the buyer can be refunded in full. |
| Challenge window | 72 hours (7 days for a push)After a passing proof. If the buyer doesn't challenge, the seller is paid. |
| Arbitration fee | 72 hoursAfter a dispute opens. The side that doesn't pay loses by default. |
Disputes: Kleros 2.0
Kleros is a decentralised court on Arbitrum One: jurors are drawn at random from people who stake its PNK token, and paid to vote with the majority. Yescrow doesn't pick or see the jurors. The escrow opens its cases through Kleros's public dispute resolver, and the jurors answer one question: was the domain in the buyer's account after the deal started?
- Deals up to $2,000 go to the Agentic Commerce Court, where three AI agents are the jurors. The fee is about 0.0008 ETH per side, and the deal pays out about 19 hours after the case opens. Yescrow pays this fee for a party with no ETH, and gets it back if that party wins.
- Larger deals go to the General Court, where a human juror decides: about 0.005 ETH per side, and 5.5 to 19 days a round. An appeal adds more jurors.
- Both sides pay the fee, in ETH. The winner gets theirs back. Each deployment caps the fee, so the court can't raise it without limit.
- The escrow pays on the jurors' vote. An appeal funded by one side alone doesn't change the outcome. Once no appeal can follow, anyone can apply the ruling, and the escrow reads it from the court itself.
- If Kleros refuses a case, or gives no final ruling within 90 days, Yescrow's judge (a multisig needing two of three signers) decides it within 14 days, and only between the buyer and the seller. If it doesn't, the deal is split 50/50. The dispute guide has the details.
What Yescrow's servers do
They run this website, submit each signed step for you and pay its gas, generate the proofs, act on deadlines, and send alerts. None of them holds a key that can move a buyer's or a seller's money: every step still needs that party's signature, and anyone can submit it instead. Yescrow's attestor key is one of the two a proof needs. While it is down, deals don't release automatically, and the buyer can still confirm by hand.
Agents and developers use the same API as this website: OpenAPI and llms.txt. How the contracts were attacked and fixed is in the security review.