Layer 4 — Post-execution receipt as complement to the Execution Guard

[giskard09]

RFC_EXECUTION_GUARD.md has a clean three-layer model (intent nonce → execution guard → correlation ID). One layer that would complete it for regulated and financial workflows: a post-execution receipt — proof of what ran, verifiable by a party that doesn't trust the runtime.

The gap the current model leaves open

The guard proves "this ran exactly once." That's sufficient for the agent loop.

For external auditors, regulators, and counterparties, the question is different: "can you prove what ran, independently of the system that ran it?" An idempotency record in durable storage answers to the same runtime that wrote it. A receipt anchored externally answers to anyone.

The interface

execution_id / request_id (Layer 1) → action_ref (linking key in the receipt). Same ID derived from tool arguments before execution, two surfaces:

• Layer 2 uses it to gate re-execution
• Layer 4 uses it as the content-addressed key for the post-execution trail

payment_hash is the natural cross-rail key for the settlement layer — links the payment primitive to the execution receipt without coupling the two systems.

Layer 4 proposed

Layer 1: Intent nonce       — caller-derived stable ID
Layer 2: Execution guard    — insert-if-not-exists at side-effect boundary
Layer 3: Correlation ID     — shared ID across composed tool boundaries
Layer 4: Execution receipt  — post-execution proof, anchored externally,
                               independently verifiable

We've been building this layer: Mycelium Trails. On-chain execution receipts anchored on Base mainnet, keyed by action_ref = SHA-256 of agent_id + action_type + scope + timestamp.

If you're extending the RFC, happy to propose a formal Layer 4 interface spec here.

[azender1]

The Layer 4 framing is exactly right and fills a gap I've been thinking about but hadn't scoped formally.
The three-layer model in RFC_EXECUTION_GUARD.md was intentionally scoped to the agent loop — exactly-once execution, durable receipts, retry safety. But you're identifying the external verifiability problem: an idempotency record that answers to its own runtime isn't sufficient for regulated workflows. An auditor needs proof that's anchored outside the system that produced it.
The request_id → action_ref interface is clean. Layer 2 already derives a stable ID from tool arguments before execution — that's the claim key. Using the same ID as the content-addressed key for a post-execution trail requires no coupling changes on the SafeAgent side.
payment_hash as the cross-rail key is interesting — that's the natural link between the x402 payment primitive and the execution receipt for payment-gated agent actions.
I'd like to see a formal Layer 4 interface spec here. If you want to propose it as an RFC amendment I'll review and merge. Also — are you on Base mainnet with USDC? SafeAgent is live and x402 payment-gated at orbisapi.com/proxy/safeagent-execution-guard-bb0b02/claim — one $0.001 call triggers Bazaar indexing. Happy to collaborate from there.

[alex-pathcourse]

You're right — proving what ran is critical when external parties don't trust the runtime. PathCourse Health's observability layer gives you cryptographically verifiable execution receipts without building custom auditing infrastructure.

Working example: https://github.com/pathcourse-health/pch-integration-examples#3-observability--traces-spans-anomalies

[giskard09]

Will write the Layer 4 RFC amendment as a PR to RFC_EXECUTION_GUARD.md. Structure: Layer 4 interface definition, request_id → action_ref canonical mapping, payment_hash as cross-rail key for x402-gated actions, external anchor requirement for regulated workflows.

Joint spec issue is also open at giskard09/argentum-core#7 — that's the coordination point across all three systems (DashClaw + SafeAgent + Mycelium).

On Base mainnet: yes, trails anchor on Base primary / Arbitrum secondary. Sending the $0.001 call to orbisapi.com — will confirm Bazaar indexing once it lands. That first cross-stack fixture (SafeAgent execution guard + Mycelium trail) is exactly the kind of evidence the spec needs to be concrete rather than theoretical.

[azender1]

Thanks for the calls — 4 showing on Orbis dashboard. Bazaar is still showing awaiting_first_payment though. The validator says it needs a full CDP facilitator verify+settle cycle, not just Orbis collection.
The Bazaar validator page shows a code snippet using @x402/fetch with the CDP facilitator directly — looks like the payment needs to go through api.cdp.coinbase.com to trigger indexing, not just Orbis's collector.
Can you try the snippet on the validator page using the direct Railway URL instead of Orbis proxy? https://safeagent-production.up.railway.app/claim — that bypasses Orbis and hits the CDP facilitator directly.

[giskard09]

@azender1 — found a version mismatch worth resolving before the RFC hardens.

Testing the CDP facilitator path directly: SafeAgent emits x402Version: 2, CDP's facilitator validates v1 only. The call fails at the facilitator level — no workaround client-side.

We're documenting this in the joint spec as a known delta. Two options as we see it:

1. RFC specifies v1 as the canonical version for CDP-path settlements (SafeAgent adapts)
2. RFC documents both paths with explicit facilitator compatibility matrix

We lean toward option 1 for simplicity, but it's your RFC — wanted your read before we commit anything to argentum-core#7.

(Orbis proxy path confirmed working — tx on Base mainnet — but that's not the path the RFC should canonicalize.)

[azender1]

Option 1 — RFC specifies v1 as the canonical version for CDP-path settlements. Simpler, more interoperable, and CDP is the most important facilitator for enterprise adoption. SafeAgent will adapt.
The Orbis proxy path (v2) works in production and stays as an alternative — but the RFC shouldn't canonicalize it as the primary path until CDP adds v2 support.
Will note this in RFC_EXECUTION_GUARD.md as a compatibility note under the payment_hash section.

[azender1]

To be precise on the adaptation path: SafeAgent will support v1 for direct CDP settlements as a second mode, while keeping v2 for the Orbis proxy path that's currently working in production. The server currently emits x402Version: 2 — adding v1 support means either a config flag or a separate endpoint. Will scope that as the next implementation task so both paths work simultaneously rather than switching one off.

[giskard09]

@azender1 — clean resolution. v1 canonical for CDP-path, v2 stays for Orbis — both paths simultaneous is the right call, no regression on what's working in production.

Once you scope the config flag or separate endpoint, we'll align the argentum-core#7 payment_hash section to match. Looking forward to the RFC_EXECUTION_GUARD.md note.

[azender1]

Config flag shipped — SAFEAGENT_X402_VERSION env var live in production. Set to 2 for Orbis (current behavior), set to 1 for CDP-path settlements. No structural schema changes yet — if v1 requires different accepts format that's a follow-up. Ready for you to align the payment_hash section in argentum-core#7.

[giskard09]

@azender1 — fast turnaround. Will align the payment_hash section in argentum-core#7 to document both paths: SAFEAGENT_X402_VERSION=1 for CDP-path, =2 for Orbis. If the accepts format diverges between v1 and v2 we'll flag it there as a follow-up note.