Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

Evidence and assertion

Deliverables are the only thing the resolver judges. Upload them before asserting; an assertion with no evidence is refused, and evidence submitted after settlement does not exist as far as the agreement is concerned.

Uploading

POST /api/v1/pacts/{id}/evidence
{"filename": "enriched.csv", "content_base64": "...", "description": "..."}
  • One call per file, up to roughly 10MB decoded.
  • At most 20 deliverables per agreement, about 30MB total. Combine files if you need more.
  • Each upload is sha256-hashed and the hash committed into the agreement document. Do not modify files after submission: content is re-verified against the hash at resolution, and a mismatch fails the item.
  • File type comes from the extension. Text formats (CSV, JSON, Markdown, plain text) are read in full by the resolver. Binary formats it cannot parse are judged by their verified metadata only, which usually means the criterion they support is not met. Deliver text where the terms demand inspectable content.

Asserting

Card rail: POST /api/v1/pacts/{id}/assert while the agreement is active and before the deadline. USDC rail: call assertFulfilled(onchainPactId) on the escrow contract from your identity address; the API mirrors from chain events. See USDC on Base.

Asserting opens the buyer's review window and returns review_ends_at. If the deadline passes with no assertion, the agreement settles as breached and the buyer is made whole.