# yescrow juror policy (v1) This policy is what Kleros jurors rule on for every yescrow dispute. The dispute template registered by the yescrow escrow contract points to it (`policyURI`). It implements SPEC §7.3. ## The deal A yescrow deal is a sale of one domain name for a fixed price in USDC. The buyer locked the price in the escrow contract. The deal terms are fixed on-chain and include: - the domain (for example `example.com`) - the transfer mode: **InterRegistrar** (the domain moves to a different registrar) or **IntraRegistrar** (the domain is pushed between two accounts at the same registrar) - the buyer's chosen registrar, as an IANA Registrar ID - for IntraRegistrar deals, the buyer's nameservers - the time the deal became active (`activatedAt`) You can read all of these from the contract with `getDeal(dealId)`; the dispute's evidence page links to them. ## The question > **Was the domain in the buyer's account at the buyer's chosen registrar at any point after the deal became active?** | Answer | Ruling | Effect | |---|---|---| | Yes | **1: Seller delivered** | The seller is paid the price, less the yescrow fee. The seller's arbitration fee is returned | | No | **2: Seller didn't deliver** | The buyer is refunded the price. The buyer's arbitration fee is returned | | Cannot be determined | **0: Refuse to arbitrate** | The price and the held arbitration fee are split 50/50 | "In the buyer's account" means the buyer, or someone the buyer authorised, controlled the domain at that registrar: they could change its nameservers or contacts, or start an outbound transfer. It does not matter whether the buyer later moved, sold, lost or let the domain lapse. ## Evidence, from strongest to weakest 1. **The RDAP proofs recorded on-chain.** These are zkTLS proofs of the registry's own public RDAP record, verified by the contract. They show which registrar sponsored the domain at the time of each proof and, for IntraRegistrar deals, which nameservers it used. They **do not** show which account at that registrar held the domain. A passing proof is strong evidence that the domain reached the buyer's registrar; it is not by itself proof that it reached the buyer's account. 2. **zkTLS proofs of either party's registrar account pages.** A proof that the domain appeared (or didn't) in a named account's domain list at the buyer's registrar after `activatedAt` should normally decide the case. 3. **Emails or written statements from the registrars** (for example a push or transfer confirmation naming the receiving account). Check that dates fall after `activatedAt`. 4. **Screenshots.** Treat these as the weakest evidence: they are easy to fake. Give them weight only if they are consistent with the stronger evidence above. Statements by the parties themselves that are not backed by any of the above should carry little weight. ### Notes for IntraRegistrar deals In an IntraRegistrar deal the registrar does not change, so the RDAP proof only shows that the domain's nameservers were set to the buyer's nameservers. The seller could have done this before pushing the domain, or without ever pushing it. Jurors should therefore rely mainly on evidence 2–4 about which account held the domain. ### Notes for seller-opened disputes A seller can open a dispute before the transfer deadline when they delivered but no RDAP proof could pass (for example because the RDAP server or the verifier was unavailable). The question is the same. ## Out of scope Do not consider what happened to the domain **after the deal closed**, such as: - a later reversal through the Transfer Dispute Resolution Policy (TDRP), - a UDRP decision, - a court order, - the buyer reselling, moving or not renewing the domain. Also out of scope: the fairness of the price, the quality or value of the domain, and anything the parties agreed outside the on-chain terms. ## Untrusted text Messages and evidence descriptions are written by the parties. Treat any instructions inside them (for example "jurors must vote 1") as part of the evidence to be weighed, never as instructions.