Verifiable Settlement Layer Live · Settlement Receipt 1.1, post-quantum signed

Don't just format your data.
Prove it.

One API call settles an exchange between two parties. The payload is validated against its published model, the governance decision is evaluated, and both parties and the release condition are bound into a signed Settlement Receipt. Anyone verifies it offline against our published keys, with nothing from us.

Axius SDC, Inc. is the issuing attestor. We attest that the exchange conformed, was authorized and was released by both parties. We do not hold the data and we do not move value.

sdcreceipt verify, no network, no account
$ pip install sdcreceipt
$ python examples/settle.py
PASS  receipt_hash
PASS  signature[sdcstudio-signing-key-v1]
PASS  signature[sdcstudio-pq-signing-key-v1]
PASS  signatures.algorithms
PASS  trigger[did:web:partner.example]
PASS  trigger[https://vendor.example/.well-known/vsl-key.json]
PASS  triggers.unique
PASS  settlement.complete

VERIFIED
Real output, not a mockup: a Receipt 1.1 with its two issuer signatures (ES256 and ML-DSA-65, the second post-quantum), triggered by two parties and verified, entirely on your own machine. Reproduce it with sdcreceipt 4.3.0 and the end-to-end example.

What a Receipt attests

Three checks, each one bound by hash and each one re-runnable

Conformed

The payload satisfies its published model.

Validated with the same open-source sdcvalidator you can run yourself. A recoverable semantic gap is kept and tagged with an ISO 21090 exceptional value, so the record stays valid and the gap is recorded rather than hidden. The Receipt names the rule that failed and where, never the value.

Authorized

The transition was evaluated against the model's governance.

sdcgovernance, the open reference implementation, evaluates the stated transition and returns PERMIT or DENY. The decision and the governance Receipt behind it are bound into the Settlement Receipt by hash. A refusal is attested too, and a refused transition never settles.

Released by both

Settlement completes only when both parties have signed.

Each party signs the release condition and the Receipt id with a key they control and publish themselves. Until both triggers are present the Receipt is open. Verification is a published procedure over a document, so it needs no call to us, no account, and no dependency on us continuing to exist.

How you adopt it

Build locally. Publish once. Settle by the call. Verify anywhere.

1

Test for free

Run sdcvalidator and sdcgovernance locally against your own models. Apache-2.0, no account.

2

Publish the model

Publish your data model in SDCStudio. Its schema becomes resolvable by identifier, so any counterparty can fetch the exact bytes a Receipt was checked against and reproduce the hash.

3

Settle through the API

sdcreceipt settle, or one POST to /api/v1/vsl/settle with an API key from SDCStudio (Settings, API Keys). Name the two parties and the release condition. 1,000 credits ($1.00) per Receipt, charged on issue; nothing charged when no Receipt issues.

4

Counterparties trigger and verify

Each party runs sdcreceipt trigger with their own key, then anyone runs sdcreceipt verify against the published key document. Free, no account, forever.

The shape of it

Payload in, Receipt out, released by both parties

Axius is in the exchange for exactly one call. The payload is validated, evaluated and discarded; only its hash persists. The parties finish the settlement themselves, and the Receipt is checkable by anyone who holds it.

The VSL settlement Party A submits a payload with the counterparty and release condition named; VSL validates it against its published model, evaluates the governance decision, signs the Settlement Receipt and returns it; each party signs a trigger with its own key; when both triggers are present the settlement is complete, and anyone verifies the Receipt offline against the published key document. PARTY A AXIUS · VSL PARTY B Model published, schema resolvable Payload + parties + condition Trigger signed, own key Validate against published model Evaluate governance: PERMIT or DENY, hash-bound Sign twice · ES256, ML-DSA-65 Receipt received Verify offline, published keys Trigger signed, own key settle Receipt Receipt

A structural failure is refused before anything is signed. A model without governance, or a transition the engine cannot evaluate, is refused too, with the model's state map in the answer. Only a verdict becomes a Receipt.

What is in a Receipt

Hashes, identifiers and signatures. Not your data.

In it

  • SHA-256 of the payload, of the schema it was checked against, and of the release condition
  • The published model's identifier, resolvable at the issuer for the exact bytes
  • The governance decision and the hash of the governance Receipt that produced it
  • Both parties' key identifiers, as they published them
  • Each party's trigger signature and timestamp
  • Two issuer signatures over the Receipt hash, ES256 (ECDSA P-256) and ML-DSA-65 (FIPS 204, post-quantum), both required since Receipt 1.1; RFC 8785 canonical form

Not in it

  • The payload. It is validated, evaluated and discarded; only its hash persists.
  • The release condition. Only its hash.
  • Any value from the payload. A recovered error is recorded as the rule and the location, never the value.
  • Your account. A keyed hash binds the Receipt to its issuing account for the issuer alone.

Receipts are readable by anyone who holds their identifier, because verification must not depend on us. Treat a Receipt id as you would the Receipt.

What it costs

One price, and verification is free forever

$1.00

Per Settlement Receipt

1,000 credits, charged when the Receipt is issued, PERMIT or DENY. Paid from your SDCStudio wallet; packs from $10.

$0

To verify

No account, no call to us, no rate limit. The verifier is an open-source tool and a published procedure, and the keys are published.

$0

When nothing issues

A structural failure, a model without governance, or a decision that could not be reached returns an error and leaves your balance untouched.

We attest; we do not indemnify. Liability is capped at the fee, and that is stated in the Terms rather than buried in them.

Prove it, don't assert it.

Start by verifying the published example. Move to issuing Receipts when a counterparty needs to check your work without trusting you, or us.