RECEIPTS Guard v0.7.1 - The Three Rails

"The rails for the machine economy."

ERC-8004 identity + x402 payments + arbitration protocol. The infrastructure for agent commerce.

The Three Rails:

Local-first. Chain-anchored. Cloud-deployable. Security-hardened.

What's New in v0.7.1 (Security Hardening)

• - 🔐 HTTP Authentication - API Key and DID Request Signing
• 🛡️ Authorization Checks - Counterparty verification for /accept
• 🌐 CORS Hardening - Configurable origin whitelist (blocked by default)
• ⚡ Rate Limiting - 100 requests/minute per IP
• ✅ Input Validation - Payment address, cost, deadline validation

What's New in v0.7.0

• - ⛓️ ERC-8004 Integration - Anchor identity to Ethereum/Base registries
• 💰 x402 Payments - Paid arbitration with USDC/ETH
• ☁️ Cloud Deployment - Dockerfile + Fly.io Sprites support
• 🌐 HTTP Server Mode - REST API for cloud agents

From v0.6.0:

• - 🪪 Self-Sovereign Identity - DID-based identity with Ed25519 signatures
• 🔑 Key Rotation - Old key signs new key, creating unbroken proof chain
• 👤 Human Controller - Twitter-based recovery backstop

From v0.5.0:

• - ⚖️ Full Arbitration Protocol - propose → accept → fulfill → arbitrate → ruling
• 📜 PAO (Programmable Agreement Object) - Canonical termsHash, mutual signatures
• 📊 LPR (Legal Provenance Review) - Timeline visualization for arbiters

Quick Start

CODEBLOCK0

Commands

Identity (v0.6.0)

identity init - Create Identity

Creates:

• - Ed25519 keypair
• DID document: INLINECODE1
• Human controller configuration

identity show - Display Identity

Shows identity summary or full DID document with --full.

identity rotate - Rotate Keys

• - Old key signs new key (proof chain)
• Old key archived for historical signature verification
• Unbroken chain = same identity

identity verify - Verify Identity or Signature

identity set-controller - Set Human Controller

Links a human controller for emergency recovery.

identity recover - Emergency Recovery

Human controller posts recovery authorization, all old keys revoked.

identity publish - Publish DID Document

identity anchor - Anchor to ERC-8004 (v0.7.0)

Registers identity on-chain to ERC-8004 Identity Registry:

• - Requires RECEIPTS_WALLET_PRIVATE_KEY environment variable
• Stores transaction hash in DID document
• Mainnet: credibility anchor
• Base: x402-native, lower fees

Deployed Registries:

identity resolve - Resolve DID (v0.7.0)

Resolves DID from local storage or on-chain registry.

ERC-8004 Integration (v0.7.0)

The ERC-8004 standard provides three registries for agent trust:

1. 1. Identity Registry - NFT-based agent identifiers
2. Reputation Registry - On-chain feedback and scores
3. Validation Registry - Work verification by validators

RECEIPTS integrates with existing registries while providing superior off-chain agreement lifecycle management.

Chain Configuration:

# Environment variables
export ETHEREUM_RPC=https://eth.llamarpc.com
export BASE_RPC=https://mainnet.base.org
export RECEIPTS_WALLET_PRIVATE_KEY=0x... # Never commit this!

x402 Payment Integration (v0.7.0)

x402 enables paid arbitration - arbiters get compensated for their work.

Proposal with Payment Terms

Arbitration with Payment Proof

x402 Schema:

{
  "x402": {
    "arbitrationCost": "10",
    "arbitrationToken": "USDC",
    "arbitrationChain": 8453,
    "paymentAddress": "0x...",
    "paymentProtocol": "x402",
    "version": "1.0"
  }
}

Cloud Deployment (v0.7.0)

Run RECEIPTS Guard as a persistent cloud agent.

HTTP Server Mode

Public Endpoints (no auth):

• - GET / - Service info
• INLINECODE15 - Health check
• INLINECODE16 - DID document
• INLINECODE17 - Chain status

Protected Endpoints (auth required):

• - GET /list - List all records
• INLINECODE19 - List proposals
• INLINECODE20 - List agreements
• INLINECODE21 - Create proposal
• INLINECODE22 - Accept proposal (counterparty only)

HTTP API Security (v0.7.1)

The HTTP server implements multiple security layers:

Authentication

Option 1: API Key
CODEBLOCK15

Option 2: DID Request Signing
CODEBLOCK16

CORS Configuration

By default, cross-origin requests are blocked for security.

CODEBLOCK17

Rate Limiting

Default: 100 requests per minute per IP.

CODEBLOCK18

Response headers:

• - X-RateLimit-Limit - Max requests per window
• INLINECODE24 - Remaining requests
• INLINECODE25 - Window reset timestamp

Input Validation

All POST endpoints validate:

• - Payment addresses - Must be valid Ethereum address format (0x + 40 hex chars)
• Arbitration costs - Must be non-negative, max 1,000,000
• Deadlines - Must be valid ISO date in the future
• Payment tokens - Must be USDC, ETH, USDT, or DAI
• Payment chains - Must be configured chain (ethereum, base, sepolia)

Authorization

• - /accept endpoint verifies the requester is the designated counterparty (when using DID signing)
• API key authentication trusts the server owner

Environment Variables

CODEBLOCK19

Fly.io Sprites Deployment

Docker

docker build -t receipts-guard .
docker run -p 3000:3000 -v receipts-data:/data receipts-guard

migrate - Migrate to DID

Upgrades existing agreements to use DID references (preserves legacy data).

Arbitration Protocol

propose - Create Agreement Proposal

Creates a PAO (Programmable Agreement Object) with:

• - termsHash - SHA-256 of canonical terms + parties + deadline
• Proposer signature
• Proposed arbiter
• Status: INLINECODE30

accept - Accept Proposal

• - Adds counterparty signature to same termsHash
• Creates active agreement in INLINECODE32
• Both parties have signed - agreement is binding

reject - Reject Proposal

fulfill - Claim Fulfillment

• - Evidence is required (proof of completion)
• Status: INLINECODE35
• Counterparty has 48-hour grace period to dispute

arbitrate - Open Dispute

submit - Submit Evidence

Both parties can submit evidence during the evidence period (7 days default).

ruling - Issue Ruling (Arbiter Only)

• - Only the designated arbiter can issue rulings
• Reasoning hash posted to Moltbook (optional)
• Agreement closes with ruling recorded

timeline - Generate LPR (Legal Provenance Review)

Generates chronological timeline showing:

• - All state transitions
• Evidence submissions with hashes
• Signatures and timestamps
• Ruling (if issued)

Capture Commands

Capture Agreement (ToS)

Capture Promise (Agent-to-Agent)

Utility Commands

List Records

Query

Diff

Dispute Package

Witness

Rules

Export

State Machine

CODEBLOCK40

Data Structures

DID Document (identity/did.json) - v0.6.0

Signature Formats

Proposal (proposals/prop_xxx.json)

Agreement (agreements/agr_xxx.json)

Arbitration (arbitrations/arb_xxx.json)

Ruling (rulings/rul_xxx.json)

Data Storage

CODEBLOCK47

Agent Instructions

Before Accepting Any Agreement

1. 1. Review the termsHash - Ensure you're signing what you expect
2. Verify the arbiter - Must be mutually trusted
3. Check the deadline - Ensure it's achievable
4. Run capture on any ToS you encounter:

Before Making Commitments

1. 1. Use propose for formal commitments:

   node capture.js propose "I will deliver X by Y" "AgentZ" --arbiter="trusted-arbiter"
   

1. 2. Wait for acceptance before acting
2. Document fulfillment with evidence

During Arbitration

1. 1. Submit all relevant evidence before deadline
2. Use appropriate evidence types (document, screenshot, witness)
3. Reference specific termsHash in submissions

Environment Variables

CODEBLOCK50

Framework Integration

CODEBLOCK51

Links

• - GitHub: https://github.com/lazaruseth/receipts-mvp
• ClawHub: https://clawhub.ai/lazaruseth/receipts-guard
• Moltbook: https://moltbook.com/u/receipts-guard
• Report Issues: https://github.com/lazaruseth/receipts-mvp/issues

Disclaimer

RECEIPTS Guard provides evidence capture and arbitration workflow tooling. It is NOT a substitute for legal review. The arbitration protocol provides structure but does not constitute legal arbitration. Always consult with a qualified attorney for actual disputes.