Arqueo

Open conservation proofs for closed ledgers.

Prove to a third party that your ledger keeps every unit it holds — without opening it, and without asking anyone to trust you.

Versión en español

Arqueo is the Spanish accounting term for a cash count: verifying that what the ledger says is actually there. This project makes that act cryptographic, exhaustive, and verifiable by a third party without opening the ledger.

The verifier needs the proof, the signed head and the public specification. It does not need the ledger, the operator, or a network.

The problem

When an organisation keeps a closed ledger — member balances, certificates, deposits, client funds — and a third party has to believe a statement about that ledger, the universal practice is to declare and audit by sample. Across the domains reviewed — federated community currency, guarantee-of-origin certificates, energy communities, digital library lending, deposit-return systems, safeguarding of client funds — the technique deployed protects the integrity of the record or the privacy of the data. In none of them is the conservation of the unit of account proved.

What exists today, measured

A settlement engine in Rust with STARK proofs that shows that a set of positions conserves the money — balances plus pending items equal the supply — and that every transition respected the rules, including the movements in transit of its two-phase protocol. A third party verifies with the signed epoch head and the proof: without the ledger, without the author, and without a network. Verifier and operator run on consumer CPUs. The invariant survives a restart: the roots at rest are persisted and verified on reopening, each with a witness that fails when they are tampered with. And the proofs keep what they were given: the spend key never travels through the API and, since RFC-0009, it does not come out in a proof either — the prover hides its witness, re-measured at zero literals on every seal, which is what moved the wire to zkssl/0.4. The verifier ships as a standalone binary with its specification and its conformance vectors, and it reproduces from the commit it names.

The format is a governed contract: a written rule on when the version goes up, conformance vectors retained per version and never rewritten, a gate that rejects earlier versions on every run, and an RFC process with states — the evidence package (RFC-0004), the published consumption (RFC-0006), the proofs over the committed state (RFC-0007), the portable proofs of the pending item (RFC-0008) and what a proof reveals (RFC-0009) are accepted RFCs, each with its vectors. The design rule: no statement is added unless the witness that would falsify it can be written first.

Licence MIT OR Apache-2.0. An audit record (AUDITORIA.md) that records every sealed decision and also the hypotheses that turned out false.

Try it: the verifier kit

A standalone verifier, its specification and its conformance vectors, in one download. It runs offline, without the repository and without asking anyone anything: four checks, in this order — a file that adds up; a tampered file that does not, with the broken rule named; the same label published in two ledgers, detected from their two signed heads with both nodes off; a swap of ledgers, rejected by name. Step by step: doc/KIT_EN.md (Spanish: doc/KIT.md).

The hashes are published next to their commit, here and in the audit record; the tarball cannot carry its own hash. To reproduce it: git checkout 1528943 and bash tools/artefacto.sh with the toolchain that VERSION names give the same binary and the same tarball, and the project's canon checks that property at every seal.

Where it applies

The shape of the problem is always the same: an operator keeps a ledger; the people who depend on it cannot see it; and the two do not trust each other. Today the conflict is settled by a third party who opens the ledger — an auditor, a supervisor, a court — once a year, by sample. Arqueo replaces that opening with a proof, and it fits wherever the unit of account is born and dies inside the ledger: issued by the operator, moved between accounts, retired by the operator.

Where it does not apply, and says so: wherever the question is what the ledger is worth rather than what it did. Bank solvency and reserves, central counterparties (their job is counterparty risk, at volumes far above this engine's measured throughput), and ledgers whose operator verifies itself by design, such as a central bank's own settlement platform. Arqueo proves conservation, not solvency. The domains named above beyond the six reviewed in the proposal are candidates: they share the shape, and they have not yet been measured.

Public funds: the same expense certified twice

The fraud is simple and hard to see: one invoice justifies a regional grant and, months later, the same invoice justifies a European one at another counter. Today it is caught by sampling, or by cross-checking databases after the fact. What Arqueo has, measured (RFC-0006, accepted): a body that certifies an expense publishes the consumption of a label in its signed head; inside that ledger a label is consumed once, and the proof of it travels without the node. Two bodies that compute the label the same way can each read the other's signed head and see the same label in both — detection from two signed heads with both nodes off, which is step 3 of the kit; a duplicated or swapped ledger is rejected by name, which is step 4.

What that does not claim, said in the same breath. It detects; it does not prevent: two sovereign ledgers can accept the same label, nobody orders between them, and a third party sees it afterwards, at the heights those heads sign. The label is an agreement — H(domain, agreed identifier), public and precomputable by whoever knows the identifier — so for two bodies to detect the same invoice they must compute it the same way, and that is governance between them, not a property of the code. And the oracle limit: the invoice is born outside the ledger; what is proved is that the same label was published, not that the invoice is real. Anchoring the identifier in a verified e-invoicing source (in Spain, VeriFactu or TicketBAI) is the natural fit, and it is a candidate, not a measurement. Between countries, not even detection until a shared label exists.

Against the audit assertions: existence and accuracy of what a ledger did are measured today, and cut-off in part (the empty box); completeness is the next proof. Solvency — whether the money is in the bank — is out of scope by design.

What it does not do

What comes next

Four of the five proofs over the same committed state are measured (RFC-0007 and RFC-0008, accepted): the rejection with proof of cause; the ageing of what is in flight, in its empty-box form; the portable pending receivable, on the payee's side; and the payment in progress, on the payer's side — together with the pledge, a transition with a proof of its own. One remains: completeness — every received acknowledgement resolves as an application or as a rejection, with a trace. Its path is drafted: RFC-0010, the reception receipt (proposed) — what the operator cannot deny having received. Together the five cover the four audit assertions that apply to a ledger of positions: existence, accuracy, cut-off and completeness.

The name

Arqueo comes from arca, the chest, the strongbox: to arquear is to count what the chest holds. Latin arca comes from arceō, to enclose, to hold in; and Greek ἀρκέω (arkéō) grows from the same root, and means to hold off and, from there, to suffice, to be enough. The name carries both halves of what this project proves: the ledger is closed, and what is in it is exactly what should be there.

The oldest chest in that lineage is the Ark of the Covenant: what it held was a law that had to be obeyed by everyone, and yet the ark itself was not to be opened or looked into. That is the shape of the problem here. The rules of a ledger bind everyone who relies on it; the ledger is not theirs to open. Arqueo lets the rules be verified without opening the box.

Where to look

Papers

All deposits are on Zenodo under CC-BY 4.0. They were published under the project's previous name and predate some corrections sealed since in the repository; the repository text is current.