mintBlue
Start here

For architects

The reading order when the question is whether the architecture holds, starting at the public audit layer.

Three questions decide whether this architecture survives review: who can read the data, who can amend the record, and who you are locked into. The pages below answer them in that order.

1. Who can amend the record

The public audit layer is the anchor page for this path. The record every exchange is anchored to is shared, append-only and owned by no single party, which is what makes an anchored proof checkable by someone who trusts neither the sender nor mintBlue.

The property that matters most in a review is the easiest one to miss: there is no central store of everyone's records to breach, because the layer carries anchors rather than data.

2. Who can read the data

Non-custodial keys is a matrix rather than a claim. It sets out, per deployment model, where the account root lives, what mintBlue holds, and which parts are designed rather than shipped. It also states, in the open, the property this design does not provide.

Read it before you accept or reject the custody story, and read it instead of any single sentence that says nobody can access anything.

3. Who you are locked into

mintBlue and the SDX Protocol covers the split between the published protocol and the operator of an implementation. No single provider owns the only implementation, so none can lock an organisation in or quietly withdraw it, and the specification stays readable whether or not you buy anything.

The protocol side answers the two questions that follow at the FAQ, including why building it yourself is harder than it looks, and at governance, which is where the neutrality claim is either proved or exposed.

4. What runs where

Machines describes the reader, writer and recorder model: state is rebuilt by replaying the recorded history rather than by trusting a copy somebody sends you. Two parties replaying the same history reach the same state, which is the property that makes reconciliation unnecessary rather than automated.

The self-hosted deployment shapes the protocol defines are at topologies.

5. Which generation you are looking at

Generations says which format the shipped SDK writes, which format the specification defines, and why the two are not wire-compatible. Skipping it is the fastest way to design against the wrong document.

Where the mechanics are specified

The anchoring and audit-trail semantics are at anchoring and the audit log, and what "verifiable" means precisely is at data integrity and verification. Both belong to the protocol, so this site links them rather than restating them.

On this page