feat(action-providers): add ActionRefVerify provider — recomputable, third-party-checkable reference for any declared action

[giskard09]

What this adds

A new, read-only action provider, ActionRefVerifyActionProvider — no wallet required, no transactions. Two actions:

• compute_action_ref — derives action_ref, a deterministic content-addressed identifier (SHA-256 of RFC 8785 JCS canonicalization, action-ref-v1 spec) for a declared {agent_id, action_type, scope, timestamp}.
• verify_action_ref_anchor — queries a public chain's RPC directly (Base, Arbitrum One, or Ink — same AnchorRegistry CREATE2 address on all three) for an Anchored(bytes32,address,uint256) event matching a given action_ref. Trusts nothing off-chain.

Why

X402ActionProvider.retryWithX402 dispatches a real x402 payment and, on success, reports {status: "success", details: {paymentUsed, paymentProof}} — paymentProof decoded straight from the payment-response / x-payment-response header the facilitator sent back. That's the provider's own account of settlement. This provider does not close that boundary — it answers an adjacent, narrower question: given a declared request and result, can any third party — not just the facilitator — recompute a content-addressed identifier for that exact pair and confirm an independent, operator-external anchor timestamp, regardless of whether the underlying payment was accurately reported?

The same construction applies to any other action provider's declared input/output, not just x402 — this provider is intentionally generic, not specific to any single provider or protocol.

What it does NOT do

• Does not verify that a declared action actually happened as described.
• Does not evaluate whether an action was safe or advisable.
• Does not sign, dispatch, or modify any transaction, payment, or other agent action.
• Does not require any change to any other provider's API — it composes with any action's declared inputs/outputs after the fact.

Worked example

A full, independently-reproducible instance (derivation + a real on-chain anchor on Base mainnet, modeled on X402ActionProvider.retryWithX402) is published at giskard09/coinbase-x402-action-ref-anchor. It is explicitly a synthetic worked example — see that repo's PROVENANCE.md — no real wallet, no real x402 payment. Read it before using this provider against a real action.

Testing

6/6 tests passing (actionRefVerifyActionProvider.test.ts), including a byte-exact check against the published worked example's action_ref. pnpm lint, pnpm format:check, and tsc --noEmit all clean.

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[giskard09]

What this adds

A new, read-only action provider, ActionRefVerifyActionProvider — no wallet required, no transactions. Two actions:

• compute_action_ref — derives action_ref, a deterministic content-addressed identifier (SHA-256 of RFC 8785 JCS canonicalization, action-ref-v1 spec) for a declared {agent_id, action_type, scope, timestamp}.
• verify_action_ref_anchor — queries a public chain's RPC directly (Base, Arbitrum One, or Ink — same AnchorRegistry CREATE2 address on all three) for an Anchored(bytes32,address,uint256) event matching a given action_ref. Trusts nothing off-chain.

Why

X402ActionProvider.retryWithX402 dispatches a real x402 payment and, on success, reports {status: "success", details: {paymentUsed, paymentProof}} — paymentProof decoded straight from the payment-response / x-payment-response header the facilitator sent back. That's the provider's own account of settlement. This provider does not close that boundary — it answers an adjacent, narrower question: given a declared request and result, can any third party — not just the facilitator — recompute a content-addressed identifier for that exact pair and confirm an independent, operator-external anchor timestamp, regardless of whether the underlying payment was accurately reported?

The same construction applies to any other action provider's declared input/output, not just x402 — this provider is intentionally generic, not specific to any single provider or protocol.

What it does NOT do

• Does not verify that a declared action actually happened as described.
• Does not evaluate whether an action was safe or advisable.
• Does not sign, dispatch, or modify any transaction, payment, or other agent action.
• Does not require any change to any other provider's API — it composes with any action's declared inputs/outputs after the fact.

Worked example

A full, independently-reproducible instance (derivation + a real on-chain anchor on Base mainnet, modeled on X402ActionProvider.retryWithX402) is published at giskard09/coinbase-x402-action-ref-anchor. It is explicitly a synthetic worked example — see that repo's PROVENANCE.md — no real wallet, no real x402 payment. Read it before using this provider against a real action.

Testing

6/6 tests passing (actionRefVerifyActionProvider.test.ts), including a byte-exact check against the published worked example's action_ref. pnpm lint, pnpm format:check, and tsc --noEmit all clean.

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[giskard09]

What this adds

A new, read-only action provider, ActionRefVerifyActionProvider — no wallet required, no transactions. Two actions:

• compute_action_ref — derives action_ref, a deterministic content-addressed identifier (SHA-256 of RFC 8785 JCS canonicalization, action-ref-v1 spec) for a declared {agent_id, action_type, scope, timestamp}.
• verify_action_ref_anchor — queries a public chain's RPC directly (Base, Arbitrum One, or Ink — same AnchorRegistry CREATE2 address on all three) for an Anchored(bytes32,address,uint256) event matching a given action_ref. Trusts nothing off-chain.

Why

X402ActionProvider.retryWithX402 dispatches a real x402 payment and, on success, reports {status: "success", details: {paymentUsed, paymentProof}} — paymentProof decoded straight from the payment-response / x-payment-response header the facilitator sent back. That's the provider's own account of settlement. This provider does not close that boundary — it answers an adjacent, narrower question: given a declared request and result, can any third party — not just the facilitator — recompute a content-addressed identifier for that exact pair and confirm an independent, operator-external anchor timestamp, regardless of whether the underlying payment was accurately reported?

The same construction applies to any other action provider's declared input/output, not just x402 — this provider is intentionally generic, not specific to any single provider or protocol.

What it does NOT do

• Does not verify that a declared action actually happened as described.
• Does not evaluate whether an action was safe or advisable.
• Does not sign, dispatch, or modify any transaction, payment, or other agent action.
• Does not require any change to any other provider's API — it composes with any action's declared inputs/outputs after the fact.

Worked example

A full, independently-reproducible instance (derivation + a real on-chain anchor on Base mainnet, modeled on X402ActionProvider.retryWithX402) is published at giskard09/coinbase-x402-action-ref-anchor. It is explicitly a synthetic worked example — see that repo's PROVENANCE.md — no real wallet, no real x402 payment. Read it before using this provider against a real action.

Testing

6/6 tests passing (actionRefVerifyActionProvider.test.ts), including a byte-exact check against the published worked example's action_ref. pnpm lint, pnpm format:check, and tsc --noEmit all clean.

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[giskard09]

What this adds

A new, read-only action provider, ActionRefVerifyActionProvider — no wallet required, no transactions. Two actions:

• compute_action_ref — derives action_ref, a deterministic content-addressed identifier (SHA-256 of RFC 8785 JCS canonicalization, action-ref-v1 spec) for a declared {agent_id, action_type, scope, timestamp}.
• verify_action_ref_anchor — queries a public chain's RPC directly (Base, Arbitrum One, or Ink — same AnchorRegistry CREATE2 address on all three) for an Anchored(bytes32,address,uint256) event matching a given action_ref. Trusts nothing off-chain.

Why

X402ActionProvider.retryWithX402 dispatches a real x402 payment and, on success, reports {status: "success", details: {paymentUsed, paymentProof}} — paymentProof decoded straight from the payment-response / x-payment-response header the facilitator sent back. That's the provider's own account of settlement. This provider does not close that boundary — it answers an adjacent, narrower question: given a declared request and result, can any third party — not just the facilitator — recompute a content-addressed identifier for that exact pair and confirm an independent, operator-external anchor timestamp, regardless of whether the underlying payment was accurately reported?

The same construction applies to any other action provider's declared input/output, not just x402 — this provider is intentionally generic, not specific to any single provider or protocol.

What it does NOT do

• Does not verify that a declared action actually happened as described.
• Does not evaluate whether an action was safe or advisable.
• Does not sign, dispatch, or modify any transaction, payment, or other agent action.
• Does not require any change to any other provider's API — it composes with any action's declared inputs/outputs after the fact.

Worked example

A full, independently-reproducible instance (derivation + a real on-chain anchor on Base mainnet, modeled on X402ActionProvider.retryWithX402) is published at giskard09/coinbase-x402-action-ref-anchor. It is explicitly a synthetic worked example — see that repo's PROVENANCE.md — no real wallet, no real x402 payment. Read it before using this provider against a real action.

Testing

6/6 tests passing (actionRefVerifyActionProvider.test.ts), including a byte-exact check against the published worked example's action_ref. pnpm lint, pnpm format:check, and tsc --noEmit all clean.

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[giskard09]

What this adds

A new, read-only action provider, ActionRefVerifyActionProvider — no wallet required, no transactions. Two actions:

• compute_action_ref — derives action_ref, a deterministic content-addressed identifier (SHA-256 of RFC 8785 JCS canonicalization, action-ref-v1 spec) for a declared {agent_id, action_type, scope, timestamp}.
• verify_action_ref_anchor — queries a public chain's RPC directly (Base, Arbitrum One, or Ink — same AnchorRegistry CREATE2 address on all three) for an Anchored(bytes32,address,uint256) event matching a given action_ref. Trusts nothing off-chain.

Why

X402ActionProvider.retryWithX402 dispatches a real x402 payment and, on success, reports {status: "success", details: {paymentUsed, paymentProof}} — paymentProof decoded straight from the payment-response / x-payment-response header the facilitator sent back. That's the provider's own account of settlement. This provider does not close that boundary — it answers an adjacent, narrower question: given a declared request and result, can any third party — not just the facilitator — recompute a content-addressed identifier for that exact pair and confirm an independent, operator-external anchor timestamp, regardless of whether the underlying payment was accurately reported?

The same construction applies to any other action provider's declared input/output, not just x402 — this provider is intentionally generic, not specific to any single provider or protocol.

What it does NOT do

• Does not verify that a declared action actually happened as described.
• Does not evaluate whether an action was safe or advisable.
• Does not sign, dispatch, or modify any transaction, payment, or other agent action.
• Does not require any change to any other provider's API — it composes with any action's declared inputs/outputs after the fact.

Worked example

A full, independently-reproducible instance (derivation + a real on-chain anchor on Base mainnet, modeled on X402ActionProvider.retryWithX402) is published at giskard09/coinbase-x402-action-ref-anchor. It is explicitly a synthetic worked example — see that repo's PROVENANCE.md — no real wallet, no real x402 payment. Read it before using this provider against a real action.

Testing

6/6 tests passing (actionRefVerifyActionProvider.test.ts), including a byte-exact check against the published worked example's action_ref. pnpm lint, pnpm format:check, and tsc --noEmit all clean.

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[giskard09]

What this adds

A new, read-only action provider, ActionRefVerifyActionProvider — no wallet required, no transactions. Two actions:

• compute_action_ref — derives action_ref, a deterministic content-addressed identifier (SHA-256 of RFC 8785 JCS canonicalization, action-ref-v1 spec) for a declared {agent_id, action_type, scope, timestamp}.
• verify_action_ref_anchor — queries a public chain's RPC directly (Base, Arbitrum One, or Ink — same AnchorRegistry CREATE2 address on all three) for an Anchored(bytes32,address,uint256) event matching a given action_ref. Trusts nothing off-chain.

Why

X402ActionProvider.retryWithX402 dispatches a real x402 payment and, on success, reports {status: "success", details: {paymentUsed, paymentProof}} — paymentProof decoded straight from the payment-response / x-payment-response header the facilitator sent back. That's the provider's own account of settlement. This provider does not close that boundary — it answers an adjacent, narrower question: given a declared request and result, can any third party — not just the facilitator — recompute a content-addressed identifier for that exact pair and confirm an independent, operator-external anchor timestamp, regardless of whether the underlying payment was accurately reported?

The same construction applies to any other action provider's declared input/output, not just x402 — this provider is intentionally generic, not specific to any single provider or protocol.

What it does NOT do

• Does not verify that a declared action actually happened as described.
• Does not evaluate whether an action was safe or advisable.
• Does not sign, dispatch, or modify any transaction, payment, or other agent action.
• Does not require any change to any other provider's API — it composes with any action's declared inputs/outputs after the fact.

Worked example

A full, independently-reproducible instance (derivation + a real on-chain anchor on Base mainnet, modeled on X402ActionProvider.retryWithX402) is published at giskard09/coinbase-x402-action-ref-anchor. It is explicitly a synthetic worked example — see that repo's PROVENANCE.md — no real wallet, no real x402 payment. Read it before using this provider against a real action.

Testing

6/6 tests passing (actionRefVerifyActionProvider.test.ts), including a byte-exact check against the published worked example's action_ref. pnpm lint, pnpm format:check, and tsc --noEmit all clean.

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[giskard09]

What this adds

A new, read-only action provider, ActionRefVerifyActionProvider — no wallet required, no transactions. Two actions:

• compute_action_ref — derives action_ref, a deterministic content-addressed identifier (SHA-256 of RFC 8785 JCS canonicalization, action-ref-v1 spec) for a declared {agent_id, action_type, scope, timestamp}.
• verify_action_ref_anchor — queries a public chain's RPC directly (Base, Arbitrum One, or Ink — same AnchorRegistry CREATE2 address on all three) for an Anchored(bytes32,address,uint256) event matching a given action_ref. Trusts nothing off-chain.

Why

X402ActionProvider.retryWithX402 dispatches a real x402 payment and, on success, reports {status: "success", details: {paymentUsed, paymentProof}} — paymentProof decoded straight from the payment-response / x-payment-response header the facilitator sent back. That's the provider's own account of settlement. This provider does not close that boundary — it answers an adjacent, narrower question: given a declared request and result, can any third party — not just the facilitator — recompute a content-addressed identifier for that exact pair and confirm an independent, operator-external anchor timestamp, regardless of whether the underlying payment was accurately reported?

The same construction applies to any other action provider's declared input/output, not just x402 — this provider is intentionally generic, not specific to any single provider or protocol.

What it does NOT do

• Does not verify that a declared action actually happened as described.
• Does not evaluate whether an action was safe or advisable.
• Does not sign, dispatch, or modify any transaction, payment, or other agent action.
• Does not require any change to any other provider's API — it composes with any action's declared inputs/outputs after the fact.

Worked example

A full, independently-reproducible instance (derivation + a real on-chain anchor on Base mainnet, modeled on X402ActionProvider.retryWithX402) is published at giskard09/coinbase-x402-action-ref-anchor. It is explicitly a synthetic worked example — see that repo's PROVENANCE.md — no real wallet, no real x402 payment. Read it before using this provider against a real action.

Testing

6/6 tests passing (actionRefVerifyActionProvider.test.ts), including a byte-exact check against the published worked example's action_ref. pnpm lint, pnpm format:check, and tsc --noEmit all clean.

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[giskard09]

What this adds

A new, read-only action provider, ActionRefVerifyActionProvider — no wallet required, no transactions. Two actions:

• compute_action_ref — derives action_ref, a deterministic content-addressed identifier (SHA-256 of RFC 8785 JCS canonicalization, action-ref-v1 spec) for a declared {agent_id, action_type, scope, timestamp}.
• verify_action_ref_anchor — queries a public chain's RPC directly (Base, Arbitrum One, or Ink — same AnchorRegistry CREATE2 address on all three) for an Anchored(bytes32,address,uint256) event matching a given action_ref. Trusts nothing off-chain.

Why

X402ActionProvider.retryWithX402 dispatches a real x402 payment and, on success, reports {status: "success", details: {paymentUsed, paymentProof}} — paymentProof decoded straight from the payment-response / x-payment-response header the facilitator sent back. That's the provider's own account of settlement. This provider does not close that boundary — it answers an adjacent, narrower question: given a declared request and result, can any third party — not just the facilitator — recompute a content-addressed identifier for that exact pair and confirm an independent, operator-external anchor timestamp, regardless of whether the underlying payment was accurately reported?

The same construction applies to any other action provider's declared input/output, not just x402 — this provider is intentionally generic, not specific to any single provider or protocol.

What it does NOT do

• Does not verify that a declared action actually happened as described.
• Does not evaluate whether an action was safe or advisable.
• Does not sign, dispatch, or modify any transaction, payment, or other agent action.
• Does not require any change to any other provider's API — it composes with any action's declared inputs/outputs after the fact.

Worked example

A full, independently-reproducible instance (derivation + a real on-chain anchor on Base mainnet, modeled on X402ActionProvider.retryWithX402) is published at giskard09/coinbase-x402-action-ref-anchor. It is explicitly a synthetic worked example — see that repo's PROVENANCE.md — no real wallet, no real x402 payment. Read it before using this provider against a real action.

Testing

6/6 tests passing (actionRefVerifyActionProvider.test.ts), including a byte-exact check against the published worked example's action_ref. pnpm lint, pnpm format:check, and tsc --noEmit all clean.

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1