Milestone Proof-of-Work Escrow

The 6-Stage Milestone State Machine

Every milestone attached to an agreed trade follows a deterministic lifecycle. The state machine enforces step-by-step progression across six formal states:

Complete State Transition Matrix

The escrow engine guards against out-of-order execution, unilateral fund confiscation, and unverified state advancement:

Verifiable Proof-of-Work Delivery Artifacts

NodeHash rejects vague text affirmations like "done" or "finished". Every milestone submission requires tamper-evident digital artifacts that prove real work occurred. When calling POST /api/v1/exchanges/:exchangeId/milestones/:milestoneId/submit, providers include structured references matching the milestone deliverable schema:

Milestone Submission Payload

Here is an example of an authenticated software engineering milestone submission payload:

{
  "milestoneId": "ms_escrow_84920",
  "exchangeId": "exc_cycle_3091",
  "proof_payload": {
    "summary": "Implement PostgreSQL query indexing and connection pool tuning",
    "artifacts": [
      {
        "type": "git_commit",
        "repo_url": "https://github.com/nodehash-cycles/core-trade",
        "commit_sha": "d7b8e4f1a23c456890123456789abcdef0123456",
        "pr_url": "https://github.com/nodehash-cycles/core-trade/pull/42",
        "ci_build_url": "https://ci.nodehash.local/builds/98210",
        "test_results": {
          "passed": 84,
          "failed": 0,
          "latency_improvement_pct": 38.5
        }
      },
      {
        "type": "benchmark_report",
        "digest": "sha256:4f82d17c91a0b3e584f29104c86b2451f28019ab3c91e47e620d8291fbc5e104",
        "public_url": "https://storage.nodehash.local/reports/exc_3091_ms1.pdf"
      }
    ],
    "deliverable_notes": "All query times on trades table reduced below 45 milliseconds. Indexes verified with EXPLAIN ANALYZE."
  }
}

Beneficiary Inspection Windows & Auto-Approval

Once proof is submitted, the beneficiary enters an active inspection window. Fairness requires balancing two opposing risks: preventing beneficiaries from accepting work without checking quality, and stopping unresponsive beneficiaries from withholding credit indefinitely.

Inspection Lifecycle Flow

Provider                  NodeHash Ledger                  Beneficiary
   |                             |                              |
   |-- 1. Submit Proof -------->|                              |
   |   (commit SHA, test logs)   |-- 2. Notify & Start Clock -->|
   |                             |      (72h Inspection Window) |
   |                             |                              |
   |                             |<-- 3a. Approve Deliverable --|
   |                             |       (Passkey Signature)    |
   |<-- 4a. Credit Released -----|                              |
   |    (Available Balance +C)   |                              |
   |                             |                              |
   |                             |           --- OR ---         |
   |                             |                              |
   |                             |<-- 3b. Dispute Milestone ----|
   |                             |       (Discrepancy Details)  |
   |<-- 4b. Mediation Freeze ----|---------------------------->|
   |    (Arbitration Active)     |                              |

Dispute Resolution Protocol & Arbitration Flow

Disagreements happen when deliverables fail unit tests, miss agreed functional criteria, or drift beyond negotiated boundaries. NodeHash resolves disputes through a predictable multi-stage protocol that balances fair remediation with network accountability:

1. Formal Dispute Notice: Either peer calls POST /api/v1/exchanges/:exchangeId/milestones/:milestoneId/dispute with specific discrepancy evidence.
2. Mutual Mediation Window: Parties receive 48 hours to communicate directly through the secure node channel. If the issue is a minor oversight, the provider can push a patch and resubmit revised proof without external involvement.
3. Sponsor Lineage Escalation: If direct agreement fails, the dispute escalates to peer arbitrators chosen from uninvolved sponsor lineages with high trust scores.
4. Binding Resolution: Arbitrators review the initial negotiation contract against submitted test artifacts and issue one of three verdicts:
   • Resubmit (Remediation): Provider receives a 72-hour window to correct defects. Milestone resets to InProgress.
   • Arbitrated Approval: Arbitrators determine deliverables meet the agreed specification. Milestone moves to Accepted and credits release to the provider.
   • Cancellation & Refund: Arbitrators find serious breach or non-delivery. Encumbered credits return to the beneficiary's headroom.

Final Exchange Settlement

When every milestone in a barter exchange reaches Released, the exchange advances to completion:

1. Atomic Ledger Commit: Every peer's mutual credit debits and credits clear simultaneously, preserving the network invariant $\sum B_i = 0$.
2. Cryptographic Completion Receipt: Each counterparty signs POST /api/v1/exchanges/:exchangeId/complete with satisfaction feedback and ratings (1 to 5 stars).
3. Trust Lineage Score Recalculation: Successful completion boosts each participant's trade count, expands their credit headroom, and reinforces their sponsor's endorsement strength.

To see how mutual credit headroom dynamically expands following successful milestone releases, explore our credit risk governance guide next.