We tagged v0.2.0 of x402-signals today: https://github.com/sF1nX/x402-signals/releases/tag/v0.2.0
x402-signals is an open CC0 spec for post-settlement obligations in x402 agentic-commerce — refund policy, fulfillment SLA, status endpoint contracts, refund endpoint contracts, lost-200 recovery. It is consciously written to complement the x402 protocol itself (which handles up-to-and-including settlement) by declaring what providers should do AFTER settle finalizes when fulfillment is upstream-bound and may fail or delay.
Why this might be relevant to the Foundation
The x402 core spec defines payment mechanics through settlement. It is intentionally silent on what happens when an upstream supplier rejects a topup, when fulfillment takes longer than the HTTP request window, when an agent's response gets dropped between settle and result, or when a partial-refund scenario emerges. x402-signals fills that slice with three buckets a provider can advertise at `/.well-known/x402`: `fulfillment_policy`, `refund_policy`, and `signals`.
v0.2.0 — first field implementation ratified
v0.2 incorporates structured feedback from the first public external field implementation: ReloadPI (`api.reloadpi.com`), which shipped eSIM + voucher + topup product types on Base mainnet and pressure-tested the draft against live traffic with zero field-shape or state-transition mismatches. Their implementation report (sF1nX/x402-signals#1) drove the central v0.2 semantic change: outcome-scoped `refund_policy` — `type` (`automatic | manual | none`) applies per OUTCOME (state-machine state), not per CATEGORY.
Three on-chain refund tx hashes from ReloadPI's carrier-rejected topup flow are cited as the reference example in §8.3.
Five changes vs v0.1
- Outcome-scoped `refund_policy` + new optional `refund_policy_by_state` map for per-state overrides
- `refund_contract` additive discovery block in §7.4
- `transactionHash` allowed alongside `paymentId` for §7.1 refund auth (matches §4.1.1 status-lookup)
- `automatic` providers SHOULD expose `refund_endpoint` for agent-initiated acceleration (§3.5)
- ReloadPI cited as first field implementation (§11)
Compatibility: zero parser changes for v0.1 implementers. New fields are OPTIONAL.
What we're asking
We are NOT asking for inclusion as a Foundation-canonical spec. The repo lives independently at sF1nX/x402-signals under CC0.
We ARE asking the TSC and active maintainers to consider whether refund + fulfillment semantics are a slice the Foundation wants to bless under `specs/schemes/` or similar canonical surface — and if so, whether x402-signals (with its first field implementation as empirical ground) is a useful starting point.
Field-shape / state-transition / voucher-topup-divergence labels are wired on `sF1nX/x402-signals`. Open for further structured review. Happy to fold observations into v0.2.1 or v0.3.
CC: @erikreppel-cb (x402 TSC) — appreciate any signal that this is or is not a slice worth Foundation attention.
— Team (x402station.io)
[email protected]
We tagged v0.2.0 of
x402-signalstoday: https://github.com/sF1nX/x402-signals/releases/tag/v0.2.0x402-signals is an open CC0 spec for post-settlement obligations in x402 agentic-commerce — refund policy, fulfillment SLA, status endpoint contracts, refund endpoint contracts, lost-200 recovery. It is consciously written to complement the x402 protocol itself (which handles up-to-and-including settlement) by declaring what providers should do AFTER settle finalizes when fulfillment is upstream-bound and may fail or delay.
Why this might be relevant to the Foundation
The x402 core spec defines payment mechanics through settlement. It is intentionally silent on what happens when an upstream supplier rejects a topup, when fulfillment takes longer than the HTTP request window, when an agent's response gets dropped between settle and result, or when a partial-refund scenario emerges. x402-signals fills that slice with three buckets a provider can advertise at `/.well-known/x402`: `fulfillment_policy`, `refund_policy`, and `signals`.
v0.2.0 — first field implementation ratified
v0.2 incorporates structured feedback from the first public external field implementation: ReloadPI (`api.reloadpi.com`), which shipped eSIM + voucher + topup product types on Base mainnet and pressure-tested the draft against live traffic with zero field-shape or state-transition mismatches. Their implementation report (sF1nX/x402-signals#1) drove the central v0.2 semantic change: outcome-scoped `refund_policy` — `type` (`automatic | manual | none`) applies per OUTCOME (state-machine state), not per CATEGORY.
Three on-chain refund tx hashes from ReloadPI's carrier-rejected topup flow are cited as the reference example in §8.3.
Five changes vs v0.1
Compatibility: zero parser changes for v0.1 implementers. New fields are OPTIONAL.
What we're asking
We are NOT asking for inclusion as a Foundation-canonical spec. The repo lives independently at sF1nX/x402-signals under CC0.
We ARE asking the TSC and active maintainers to consider whether refund + fulfillment semantics are a slice the Foundation wants to bless under `specs/schemes/` or similar canonical surface — and if so, whether x402-signals (with its first field implementation as empirical ground) is a useful starting point.
Field-shape / state-transition / voucher-topup-divergence labels are wired on `sF1nX/x402-signals`. Open for further structured review. Happy to fold observations into v0.2.1 or v0.3.
CC: @erikreppel-cb (x402 TSC) — appreciate any signal that this is or is not a slice worth Foundation attention.
— Team (x402station.io)
[email protected]