FAQ

The questions architects and decision-makers ask most often about the open data-sharing protocol.

An open protocol lets any receiver independently verify a cross-organisation data exchange, recorded on a public audit layer that no single party owns. These are the questions architects and decision-makers ask most often about it.

The new part is that an open protocol lets the receiver alone verify a cross-organisation exchange: what was shared, by whom, when, and on what basis, recorded on a public audit layer that no single party owns. Encryption sits at field level and the data stays at its source, so parties that do not trust each other's infrastructure can still exchange and prove those exchanges. The same protocol is reused by every case, in place of a fresh integration built for each partner.

Read more: What this adds beyond Kafka. Also: The base layer.

Why not just use a simpler message bus or event bus between the parties?

A message bus is transport you operate, and every participant has to trust its operator for ordering and integrity. This protocol replaces that trust with cryptographic proof of order and content, field-level encryption, delegated identity, and references whose proof travels with them. For high-volume real-time streaming inside a single organisation, an event bus is the faster and better tool and honestly where it wins; the trade is raw throughput for verifiability between parties that do not trust each other.

How is this different from data clean rooms or secure multi-party compute?

Clean rooms and secure compute answer a bounded, batch research question: compute this over data no one can see, and reveal only the result. This protocol works in the stream and does a different job, proving what happened to data, who did what, when, and on what basis, with identity and an immutable audit trail, at the source. The two combine well and are not rivals.

Is a blockchain or a distributed ledger used as a component in this solution?

Yes: the protocol anchors its records to a public audit layer, a neutral, append-only ledger that no single party owns, so that ordering and integrity can be verified independently of any operator. Only compact cryptographic proofs are written there; the data itself stays encrypted at its source and never lands on that layer. The property that matters is a tamper-evident, self-verifiable audit trail, which is why the public audit layer was chosen in place of a database that one party controls.

The public audit layer uses an output-based model (a UTXO model) rather than an account model, and this shapes how it behaves here. Records are tied to fresh keys, so entries are not trivially linkable to a single holder, which is privacy (protection with accountability), not anonymity. At high volume the model composes cleanly: independent outputs let validation run in parallel instead of serialising behind one global account state, and those outputs are splittable.

Does this rely on energy-intensive mining?

Participants do not mine, and no energy-intensive computation runs on a participant's side. A party's node writes compact proofs to the public audit layer and reads them back, and verifying a proof is a light check. The audit layer's ordering is maintained by dedicated operators, and because that cost is shared across enormous transaction volume, the energy attributable to anchoring a single proof is negligible per record. The protocol's own work, encrypting, addressing, and verifying, is ordinary computation.

If we adopt this, how do we avoid vendor lock-in?

Because the standard is open and any provider can implement it, no single supplier holds your data or your integration, and every exchange stays independently verifiable. Continuity is built into the architecture itself: any conforming provider can retrieve and serve your data. You can also run it yourself.

Why not just build this ourselves?

You can: the protocol and the specification are open, and the reference implementation is source-available and free to fork and run, so building it yourself is a supported path. What you would be rebuilding is specialised verifiable-data-exchange machinery that has already been through two development phases, so the real question is time and focus, not whether it is possible. Every record and proof is portable and exportable, so nothing you build or adopt is trapped.

Read more: Governance and working group. Also: Getting started.

If no one owns the protocol, why would we pay a provider, and will they still be around in five years?

Everything is source-available, including the state machines, so you can take it and run it yourself at no licence cost for the protocol itself. What a provider charges for is managed provisioning (one-click setup, scaling, service-level guarantees, and a support licence): you pay for the running of it, never for the protocol. And because continuity is architectural, if any single provider disappears, another conforming provider (or you) can retrieve and keep serving your data.

Read more: Governance and working group. Also: About.

Isn't this a lot to integrate? It sounds more complex than the single-vendor SaaS we are used to.

Shared ecosystem infrastructure is genuinely more involved to stand up than single-tenant SaaS, and pretending otherwise would be dishonest. The usual path is a phased start with a small number of participants, so the first exchange proves value before the network scales. Because one protocol is reused for every partner, that integration effort is paid once rather than rebuilt for each new counterpart.

How is this different from data wallets or personal data stores like Solid?

Wallets, pods, and Solid organise data around a person, giving an individual one place to hold their own data and grant others access to it. This standard governs the exchange between organisations: a shared protocol for the organisation-to-organisation lane, with field-level encryption, delegated identity, and a record of each exchange that the receiver can verify alone. The two solve different problems and combine well, a personal store on one side and an organisation-to-organisation protocol on the other.

Read more: The base protocol. Also: The base layer.

Where does this fit next to a data mesh or data lake?

A data lake and a data mesh organise data inside one organisation: a lake centralises it in a single store, and a mesh distributes ownership across domain teams while keeping it governed as one estate. This standard operates in the lane between organisations, carrying an exchange from one party to another with field-level encryption, delegated identity, and a verifiable record of what moved. A mesh or a lake keeps your own data in order; this protocol moves audit-grade data across the boundary to another organisation.

Read more: The base protocol. Also: What this adds beyond Kafka.

How is this different from an API gateway?

An API gateway exposes and manages one provider's interface, so each partner you connect to brings its own contract, endpoints, and integration work. This standard is a single agreement that every participant implements once, so the same protocol carries every counterpart and every case, in place of a fresh integration built per partner. A gateway is provisioned for each provider; this protocol is implemented once and reused across all of them.

Read more: The base protocol. Also: Avoiding vendor lock-in.

New here? Getting started walks through a first exchange.

On this page