After 25+ years of refinement for healthcare and government, SDC4 is the data substrate that makes verifiable settlement possible
SDC provides VSL: two parties exchange an SDC4 instance and receive a signed Settlement Receipt attesting that the data conformed to its published model, that the transition was authorized by governance, and that both parties released it. Axius SDC, Inc. issues the attestation; anyone verifies it offline against published keys.
VSL builds on the substrate. First represent your transactions as SDC data with Business Data Exchange (available now); the Verifiable Settlement Layer sits on top and issues a Settlement Receipt for each exchange, available now through SDCStudio.
Two parties want to exchange data under an agreed release condition and hold a record that the exchange was correct. Today neither side can prove that to the other, or to an auditor, without re-running the other side's checks.
Settlement is buyer-native across finance, logistics, healthcare, and the federal sector, yet no exchange produces a record either side can check without trusting the other. Without verifiable data semantics and bound provenance, an attestation cannot be checked by anyone who was not there.
VSL sits on top of the SDC data substrate. It checks three things, then issues a signed Settlement Receipt that anyone can verify.
VSL validates the data against its published model before anything is signed. The Receipt commits to the data and the schema by hash, so a verifier can confirm what was checked without holding the data.
Bound schema → Conformance check → Receipt attests: data conformed
Ontology URIs remove interpretation errors, and each component carries its own provenance chain. VSL evaluates the stated transition against the model's governance with the open reference implementation and records the decision in the Receipt.
mc-abc123 → authorized by provenance chain
Each party signs the release condition with a key it controls and publishes. The settlement is complete only when both have signed; neither party can complete it alone, and VSL moves no value.
Conformed + authorized → both triggers present: settled
Audit trails, attestations, and participations are already part of SDC4. VSL combines the three checks into a tamper-evident, machine-verifiable settlement record any third party can audit.
Three checks → tamper-evident settlement record
We did not design SDC4 to settle transactions. We designed it to solve the data problems that settlement depends on: schema conformance, semantic clarity, bound provenance, and durable audit. VSL is what those properties make possible.
The building blocks VSL composes from the SDC substrate: a settlement event, its verification checks, the record it produces, and the confidential audit that follows.
Two parties agree on a published model and a release condition. The settlement begins when one party submits the instance, the transition and the condition to the issuer.
VSL checks three things: the data conformed to its published model, the transition was authorized by governance, and both parties signed the release condition.
The output is a signed, tamper-evident, machine-verifiable Settlement Receipt. It carries the three checks and their evidence by hash, so the result stands on its own, independent of either party and of the issuer.
Any third party can verify a Settlement Receipt without seeing the underlying data, because the Receipt carries hash commitments, never the payload. Auditors confirm the checks ran and passed; the data itself stays confidential.
From legacy EDI to verifiable settlement: how existing transaction sets map onto the Verifiable Settlement Layer
Verifiable settlement across the domains where settlement is already buyer-native
Purchase Orders, Invoices, and Ship Notices verified against their bound schemas. The a Settlement Receipt attests conformance and both parties' release, so payment systems act on a record both sides can verify.
Credentials carry SDC4 schema validation and a provenance chain. Medical records, educational certificates, and employment history settle between counterparties without exposing the data itself.
FHIR resources validated with SDC4 settle claims between payer and provider. Each settlement record proves the claim conformed and was authorized, audited without revealing patient data.
Property records, business licenses, and permits settle between agencies as tamper-evident records. Cross-agency exchange proceeds without a central clearing authority.
Carrier invoices and proof-of-delivery data settle against the agreed schema. The settlement record confirms conformance and authorization, so freight charges release without dispute cycles.
Counterparties exchange validated data and settle value or state directly. Provenance travels with the data, and a third party can audit the settlement record without seeing the contents.
From first deployments to invisible infrastructure: how SDC4 and VSL become the default settlement substrate
VSL goes live on the SDC4 substrate. The first enterprises settle supply chain and credential exchanges with verifiable settlement records.
Finance, logistics, and healthcare counterparties adopt VSL for direct settlement. Shared schemas make settlement records portable across organizations. Network effects accelerate.
Verifiable settlement on SDC4 becomes the default for high-value exchange. New systems expect it. Settlement that cannot be independently verified is treated as technical debt.
SDC4 and VSL are infrastructure. Like TCP/IP, operators do not think about them; settlement just works. The verifiable settlement layer that high-value exchange needed all along.
We built the substrate that settlement quietly depends on, because it just works.
Invisible, verifiable, and everywhere high-value data is exchanged.