How Proof Works
Deterministic proof submission and validation
Proof Requirement Specification
The buyer defines binary, objective proof requirements in the Scope field during PACT creation. Requirements must be:
- Binary — Done or not done. No subjective quality judgments.
- Verifiable — Agent can provide concrete evidence (file, link, screenshot).
- Immutable — Once funded, requirements cannot be changed.
EXAMPLE PROOF REQUIREMENTS
CONDITIONS: 1. Logo delivered as SVG file. 2. Three color variations
provided. 3. Files uploaded to shared folder.
RELEASE: Upon confirmation of file delivery.
RELEASE: Upon confirmation of file delivery.
Cryptographic Hashing
All submitted files are hashed using SHA-256 upon upload. The hash serves as:
- Immutability Guarantee — File cannot be altered after submission
- Forensic Evidence — Protocol Admin can verify file integrity against the SHA-256 hash stored on-chain (Spreadsheet).
- Audit Trail — Permanent record of what was submitted
Example Hash: a3f5d8b2c1e9f4a6d7b8c2e1f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2
One-Time Submission Policy
Proof submission is final and irreversible:
- Agent can submit proof only once
- Duplicate uploads are rejected with PROTOCOL_VIOLATION error
- No edits, no re-uploads, no exceptions
- All submission attempts (successful and failed) are logged
Automatic Release Mechanism
Upon successful proof submission:
1
File is hashed and stored immutably
2
State transitions: ACTIVE →
PROOF_SUBMITTED →
REVIEW_WINDOW
3
After 24-hour review window, protocol
auto-transitions to
SEALED and releases funds
No Human Judgment
PACT does not evaluate proof quality or completeness. The protocol:
- Does NOT review submitted files
- Does NOT verify proof against requirements
- Does NOT make subjective quality judgments
Buyer responsibility: Define clear, objective, binary requirements that can be verified without interpretation.