Protocol-Level Receipts vs Custom Wrapper Logging
Most teams start with custom wrappers: intercept the API call, log the request and response, store it somewhere. This works until an auditor asks "prove this log was not modified." Protocol-level receipts answer that question by design.
Head-to-Head
| Dimension | Claw EA | Custom wrappers / ad-hoc logging |
|---|---|---|
| Evidence standard | Protocol-defined schemas (versioned, interoperable) | Ad-hoc logging (custom per team) |
| Signing | Ed25519 per receipt + per bundle | None (log entries are unsigned) |
| Verification | Deterministic offline verifier | Grep through logs |
| Receipt binding | Receipts bound to event chain via run_id + event_hash | Log correlation by timestamp (approximate) |
| Policy enforcement | Content-addressed WPC pinned in receipts | Config file (version unknown at audit time) |
| Maintenance cost | Protocol handles versioning and schema evolution | Team maintains custom wrappers per model/tool |
| Third-party trust | Verifiable by anyone with the public key | Trust the team that wrote the wrapper |
The Wrapper Tax
Every custom wrapper is a maintenance liability. When the model provider changes their API, the wrapper breaks. When you add a new model, you write a new wrapper. When you need to prove what happened six months ago, you hope the log schema has not changed.
Protocol-level receipts are versioned, schema-defined, and interoperable. A receipt from today and a receipt from six months ago both verify against the same algorithm. The proof bundle schema evolves additively, and unknown versions fail closed in the verifier.
Migration Path
You do not need to rip out custom wrappers overnight. Route model calls through clawproxy to start generating gateway receipts alongside your existing logging. The receipts add a signed evidence layer on top of whatever you already have.