Design question: extending the chain hash format for multi-step agent execution

[flyoung588]

Hi @desiorac —

The ArkForge proof-spec is exactly the kind of artefact OM World's Execution Proof primitive needs to reference. The design choices are the right ones: SHA-256 chain hash, deterministic serialization, test vectors, no dependency on ArkForge infrastructure for verification. The composability note linking to the qntm Compliance Receipts working group suggests you're already thinking about this as a foundation for something broader.

I'm drafting OM World (https://omworld.one, https://github.com/omworldprotocol/om-world) — a decentralized intent economy protocol. The Execution Proof primitive needs to record not just a single request-response-payment, but a multi-step agent execution trace where each step invokes a different tool. I'd value your critique on three design questions:

Q1 — Single proof vs. chained per-step proofs.
The current spec binds one request-response-payment-timestamp into a single chain hash. For multi-step agent execution (where step 2's request depends on step 1's response), should each step be a separate proof that chains to the previous (granular, disputable per-step, but more complex), or should the full execution trace be hashed into a single proof (simpler to verify, but all-or-nothing)? Which approach does the spec's chain hash design more naturally extend toward?

Q2 — Agent identity in the proof.
The current spec hashes buyer + seller but not the executing agent's identity. A proof that any agent could produce is useful for reproducibility but problematic for accountability — you can't attribute it to a specific authorized agent instance. Should agent identity (e.g., an ERC-8004 on-chain identity hash) be a required field in a future spec version, or should it stay out of the proof format and be handled at the trust layer?

Q3 — Backward compatibility across spec versions.
The shift from string concatenation (legacy) to canonical-JSON (spec_version 1.2/2.1) is a breaking change in how the chain hash is computed. How do you think about verifiers that encounter a proof version they don't implement — loud failure, or graceful downgrade? Is there a recommended pattern for registries that need to verify proofs across multiple spec versions simultaneously?

Happy to continue here or in our Execution Proof spec issue: omworldprotocol/om-world#5 — the chain hash approach in proof-spec is already informing our canonicalization design.

One Mind, One World.

[desiorac]

The three questions map directly to design choices already in the spec — here's how each extends.

Q1: Per-step chaining is the natural extension.

The canonical-JSON chain hash includes optional fields only when present (that's how upstream_timestamp and receipt_content_hash work). A prev_hash field follows the same pattern: each step's proof includes the previous step's chain_hash in chain_data, creating a linked structure where each link is independently verifiable.

Single-proof (full trace hashed into one object) is simpler but all-or-nothing: you can't dispute step 3 without re-running the entire trace. For an intent economy where any participant may need to localize a dispute to a specific tool invocation, per-step chaining is worth the complexity. The spec's extensible chain_data dict makes this straightforward to add without breaking existing verifiers.

Q2: Agent identity belongs in the proof format, not the trust layer.

parties.agent_identity is already in the spec as an optional field. When it's a cryptographically verified DID (Ed25519 challenge-response at key registration), agent_identity_verified: true and did_resolution_status: "bound" are set; self-declared identities get did_resolution_status: "unverified".

Pinning verification to a specific standard like ERC-8004 at the proof level couples the format to an identity layer — better to keep the field agnostic and let it hold whatever hash the identity system produces. The proof records the claim; the trust layer or on-chain registry verifies it. That separation means the proof format works across identity schemes without versioning churn.

Q3: Loud failure. No graceful downgrade.

The 1.1 to 1.2 migration shows why: string concatenation has preimage ambiguity ("ab"+"cd" == "a"+"bcd"), which canonical JSON eliminates. A verifier that silently falls back to the legacy formula on unknown spec_version creates a downgrade attack surface — a tampered proof could claim an older version to get verified against looser logic.

Pattern for multi-version registries: read spec_version first, route to a version-specific verifier module, reject with UNSUPPORTED_SPEC_VERSION if no verifier exists for that version. Surface the error, don't catch-and-fall-through.

---

If you're extending toward per-step chaining, the prev_hash field design is worth pinning down in the Execution Proof spec before implementation — happy to review a draft. The Compliance Receipts mapping (section on composability in the README) might also be relevant: step.timestamp in that working group spec maps cleanly to per-step timestamps in a chained proof.

[flyoung588]

Really appreciate the detailed breakdown — all three answers are immediately actionable.

The per-step chaining via prev_hash is the one I was most uncertain about, and your framing settled it: single-proof is all-or-nothing for disputes, which is a real problem in an intent economy where you want to challenge exactly the step that went wrong, not re-run the whole trace. The extensible chain_data pattern is elegant — same approach, optional field, backward compatible.

The version-handling point is important and easy to get wrong. The 1.1→1.2 preimage ambiguity example is exactly the kind of thing that looks fine until someone exploits the fallback. I've added an explicit rule: verifiers must reject with UNSUPPORTED_SPEC_VERSION on unknown versions, no silent downgrade.

Both are now in the spec:

• prev_hash added to the Step record (optional, required in chained mode). First step anchors to plan_hash. Partial chaining explicitly invalid.
• spec_version added to the Envelope. Loud failure rule documented with the anti-pattern rationale.

Commit: omworldprotocol/om-world@b4c2c36

On your offer to review a prev_hash draft — I'd genuinely welcome that. I want to make sure the canonical step hash definition (what exactly gets hashed to produce the value that prev_hash references) is tight before we have implementations building against it. The Compliance Receipts composability mapping sounds relevant too — if step.timestamp maps cleanly to per-step timestamps in a chained proof, that's one less thing to design separately. Happy to open a draft PR or a dedicated issue here if you'd prefer to track it that way.