Client responsibilities

Integration guide

An integration coordinates signed documents, token approvals, role operators, evidence storage and clocks around a deliberately small escrow contract.

Source published · no supported SDKThe contracts, client modules, schemas and three local examples are published at github.com/Sinetti-ai/Sinetti (Apache-2.0). There is no supported SDK package or public deployment. The flow below describes integration responsibilities.

1. Preflight

Pin chain ID, escrow address, bytecode/source revision and EIP-712 domain version.
Use a local or separately reviewed deployment of the current source; none is supported publicly.
Resolve verifier and arbitrator policies, endpoints, keys, conflicts and expected availability.
Choose deadlines from operational latency, not contract minimums.
Prepare durable evidence storage; a URL is not an integrity commitment.

2. Build and open

terms = buildSellerAcceptance({
  buyer, seller, verifier, arbitrator, token,
  amount, bond, challengerBond, termsHash,
  buyerIdentityRef, sellerIdentityRef,
  verifierIdentityRef, arbitratorIdentityRef,
  duration, challengeWindow, rulingWindow,
  openBy, salt, metaEvidenceURI
})
sellerSignature = signTypedData(domain, terms)
verifyLocally(domain, terms, sellerSignature, seller)
approveToken(escrow, buyerPrincipal)
openDeal(terms, sellerSignature)

This is protocol-shaped pseudocode, not a published SDK. Use the contract interfaces and client modules from the published source and compare emitted deal fields with the preflight object.

3. Watch states and clocks

Event or state	Client action
`DealOpened`	Persist deal ID, full signed terms and chain position.
Seller bond required	Track allowance and `postBond()` before the delivery path proceeds.
`DeliverySubmitted`	Resolve the evidence envelope and verify committed digests.
`VerificationRecorded`	Notify the disadvantaged party and expose the exact challenge deadline.
`Challenged`	Freeze normal finalization; preserve both parties' evidence and track ruling deadline.
`Settled`	Read explicit credits, then prompt each beneficiary to withdraw.

4. Transaction discipline

Treat reads and event replay as idempotent; treat writes as state-dependent.
Simulate or re-read the deal immediately before a write.
Wait for the application's chosen confirmation depth before presenting a transition as final.
Deduplicate logs by chain ID, transaction hash and log index; handle removed logs during reorganization.
Never infer settlement allocation only from the verdict. Read the terminal reason and credits.

5. Failure handling

Failure	Safe response
Artifact cannot be retrieved or digest differs	Do not claim successful verification; preserve the mismatch and use Inconclusive where authorized.
Role service unavailable	Expose the relevant deadline and escalation path; do not silently substitute another address.
Transaction reverts after stale state	Re-read state and recompute the valid action set.
Withdrawal receiver fails	Keep the credit visible and retry from the beneficiary; other settlements need not be blocked.

← Evidence format Verifier role →