Agreement surface
Signed deal terms
The seller signature is the contract's proof that the seller accepted the buyer, roles, assets, amounts, clocks and commitments used to open the deal.
Material fields
| Group | Signed content | Integration question |
|---|---|---|
| Parties | buyer, seller, verifier, arbitrator | Are they the intended execution wallets and role contract? |
| Value | token, amount, bond, challengerBond | Do token units, allowance and worst-case allocation match the agreement? |
| Clocks | duration, challengeWindow, rulingWindow, openBy | Can every party act and retrieve evidence before expiry? |
| Commitments | termsHash plus four individual identity references | Can every signer reproduce the exact preimage? |
| Replay and metadata | salt, metaEvidenceURI, chain, verifying contract and domain version | Is the signature unique and bound to the intended deployment? |
Signing flow
- Resolve the intended chain, escrow address and signing-domain version.
- Build the exact
SellerAcceptancestruct and validate numeric units,duration, windows andopenBy. - For the current schema-validity verifier, RFC-8785-canonicalize the acceptance-criteria JSON and set
termsHashto its SHA-256 digest. - Set verifier and arbitrator explicitly; never substitute them after the signature.
- Set a unique
saltand the agreedmetaEvidenceURI. - Show the seller a human-readable summary derived from the exact typed data.
- Collect the seller EIP-712 signature, recover it locally and compare every field with the transaction arguments.
- Open the deal once. A consumed or expired acceptance requires a new signing session.
- An unused acceptance can be revoked on-chain by the seller before a buyer consumes it.
Canonicalization rule
The escrow treats termsHash as opaque bytes. Integrators therefore need one versioned, byte-for-byte canonicalization rule outside the contract. Persist the original document, canonical bytes, algorithm identifier and digest together. A digest without a reproducible preimage cannot support later verification.
Seller review checklist
- Token address and decimals are correct for the selected chain.
- Principal, both bonds and maximum loss are understandable.
- Delivery and verification requirements point to durable, retrievable material.
- Challenge and ruling windows are long enough for realistic response.
- Verifier and arbitrator policies are available before signing.
- Identity references are either intentionally populated or intentionally zero.
Negotiation stays off-chainThe contract proves acceptance of encoded terms; it does not provide offer negotiation, document hosting or a commercial reasonableness check.