Skip to content

Fiscal402 protocol

Protocol

Fiscal402 protocol

A verifiable representation of a fiscal event. This is the public contract, not the execution engine.

What is standardized

Fiscal402 defines a verifiable representation of a fiscal event. The public, stable object today is fiscal402.receipt / 1.0.0. Canonicalization, signatures and artifact hashes are part of that contract. Anyone with the receipt, JWKS and bound bytes can check integrity without calling Fiscal402.

Conceptual objects

The execution architecture uses additional types. They are not all public JSON APIs today.

ObjectStatus
PaymentAdapterInternal — protocol → PaymentEvidence
PaymentEvidenceInternal / north-star — normalized settlement input
FiscalEventInternal / north-star — payment + parties + supply
JurisdictionRouterInternal — selects an engine
FiscalDeterminationOUTPUT of processing FiscalEvent; projected onto the receipt
FiscalArtifactBound by hash on the receipt
fiscal402.receipt/1.0.0CURRENT public spec, frozen
fiscal402.receipt/2.0.0EXPERIMENTAL generic spec

Current public receipt spec

  • fiscal402.sorted-json/1 — compact JSON, recursive alphabetic keys, UTF-8. Not RFC 8785 / JCS.
  • SHA-256 of that canonical UTF-8 string.
  • Ed25519 over the hex digest string. kid receipt-ed25519-v1.
  • UBL hash: SHA-256 of exact generated UTF-8 bytes. Identifier sha256-utf8-bytes.

One primitive, over time

One verifiable fiscal event format, independent of how value moved. Today the production path is x402 v2 exact, EU VAT, and fiscal402.receipt/1.0.0. Receipt v2 is experimental. UK VAT is an experimental determination path and does not emit a statutory invoice. Additional rails and engines are future architecture.