Lien reconciliation: the privacy requirement that survives a change of technology

In November 2025, Brazil's Central Bank told the participants of the DREX pilot that the distributed-ledger infrastructure would be shut down and that the project would proceed "technology-agnostic". The first delivery of the new phase, planned for the second half of 2026, has a much narrower and much more concrete scope: lien reconciliation — letting an asset registered at different institutions be used as loan collateral without ambiguity about who holds what.

The prevailing reading was that this was a verdict on blockchain. I spent almost a decade building one and have an obvious interest in the subject, so I'll avoid defending it here. My argument is a different one, and at bottom it's more uncomfortable:

The pilot's central difficulty was not a difficulty of the technology — and that's why it doesn't go away along with it.

Whoever builds the lien layer inherits the same requirement, in another form. It's worth naming while the design is still open.

1. What lien reconciliation is, structurally

The business problem is well known. The same asset can be pledged as collateral to more than one creditor. The records live at different institutions — banks, finance companies, brokerages, registrars, notary offices, 27 state motor-vehicle departments. No one holds the full picture. The creditor cannot verify quickly and with certainty whether the asset is already committed, and credit gets slower and more expensive because of it.

Strip away the financial vocabulary and look at the shape of the problem: preventing the same asset from being spent twice by parties who don't share a database and have no reason to trust one another.

That is double-spend prevention. It's an old distributed-systems problem, and it needs no token, no network, and no probabilistic consensus to be exactly that problem. What changes from one implementation to another is who holds authority over the ordering of events, and what each participant learns along the way.

The Central Bank's choice for 2026 solves the first part by centralization: a central infrastructure reconciles the records. It's a defensible decision, and I'll come back to it at the end. The second part — what each participant learns — is the subject of this piece.

2. Brazil already runs a national lien registry

This discussion is usually treated as speculation about some future system. It isn't. Brazil has for years run a national lien registry at scale, and it's a good place to watch the requirement working in practice.

The National Lien System concentrates the financial restrictions on vehicles pledged as collateral in credit operations across the whole country, and it's operated by B3, through the arm inherited from Cetip. The flow is simple: the lending institution registers the lien when financing the vehicle; when assessing a new operation, it queries the base and receives, in real time, whether there's a restriction; on payoff, it releases the lien.

Two observations about this design.

The first is that it already is, without using the phrase, double-spend prevention — the service's own description points out that the real-time query prevents an already-encumbered vehicle from being used as collateral in another operation. The problem DREX now calls lien reconciliation has a national implementation in production, 24 hours a day, integrated with the state motor-vehicle departments.

The second is more interesting. The query doesn't just return whether a restriction exists: it returns which creditor holds it.

In vehicle credit that has a legitimate function. Whoever is going to trade an encumbered vehicle needs to know whom to pay off. It's operationally necessary information, and the registry is right to provide it in that context.

But note what the property means in information terms: each query hands a competitor the identity of the institution that financed that customer. For vehicle financing, with a standardized ticket and a mature market, the market accepted that cost long ago — and the systemic benefit of reducing fraud largely outweighed it.

The question that DREX phase 3 raises is not about the SNG, which works and solved a real problem. It's about what happens when that model generalizes to other asset classes — atomized receivables, credit rights, closed-end fund shares, collateral for structured operations — where the creditor's identity and the very existence of the assessment are competitively sensitive information, not a necessary operational datum.

3. The leak isn't in the record. It's in the query.

Here's the part I haven't seen discussed publicly, and which I consider the most important requirement to name.

In a central lien registry, the most valuable data isn't the record. It's the query log.

Every time an institution asks "is asset X encumbered?", it tells the central operator that it's assessing credit against X — and, by extension, against X's holder. The answer is beside the point. The question has already given away the information.

Aggregate those queries over a few months and what forms is not a history: it's a real-time map of the financial system's credit pipeline. Who's assessing whom, how often, in which sectors, at what speed, before any operation is closed.

It's worth insisting on the distinction, because it's the heart of the problem. A lien registry stores what happened. A query log reveals what's being considered. The second is more valuable than the first, and it isn't generated by the data — it's generated by the act of asking. No access policy over the registry's content protects against this, because it isn't the content that's being exposed.

There are two derived effects.

The answer leaks too. "Yes, it's encumbered, and the creditor is bank B" tells bank A something about B's commercial relationship with that customer, at the moment A is deciding whether to compete for it.

And there's concentration. A registry that knows every charge on every relevant asset in the country, plus the history of who queried what, is the most valuable database in the Brazilian financial system gathered at a single point. That's a statement about attack surface and about information-custody risk, not about the integrity of any operator.

A necessary caveat, and a sincere one: the phase 3 design isn't public. I'm not criticizing an implementation I haven't seen. I'm describing a requirement that any centralized implementation of this kind faces, and one that's far cheaper to address before the architecture is frozen than after.

4. Two axes of privacy, and the confusion that sank the pilot

The report on the first phase of the DREX pilot, published by the Central Bank in February 2025, concluded that the privacy solutions tested guaranteed the anonymity of transactions including before the Central Bank itself, and that, as a result, supervision, balance freezing and compliance with judicial orders became unfeasible.

That was read in the market as a limitation of blockchain. I think it's an imprecise reading, and the imprecision is exactly what makes the problem transferable.

The solutions tested were technically serious, several of them with first-rate cryptography. They failed because they were built on a definition of privacy inherited from public networks, where privacy means protection against everyone: the neighbor, the competitor, the State. In that tradition, hiding from everybody is the definition of winning.

In a regulated infrastructure, the same definition is defeat. Because there's a third party there that isn't a peer. The supervisor isn't an optional busybody whose curiosity you fend off — it's an entity with a legal mandate, one that needs to see the system, to freeze when the courts order it, and to follow the money when the law requires. "The system has no way to see" is not an acceptable answer to a judicial order.

In other words: the pilot didn't discover a limit of cryptography. It discovered a requirement-specification error. And a requirement error crosses any change of stack — that's why it reappears, on the other side, in a central registry that sees everyone's intent.

Separating the two axes resolves the confusion:

• Horizontal privacy — peers don't see each other. My competitor doesn't map my portfolio, my supplier doesn't read my cash position, the infrastructure operator doesn't learn my pipeline.
• Vertical transparency — whoever holds a legal mandate sees everything. Not by breaking in, not by operational exception, not by a formal request with a response deadline: by design.

The pilot optimized the first axis until it zeroed out the second. A central registry optimizes the second and treats the first as an acceptable consequence. Neither of them is the requirement.

5. The asymmetry that makes the two axes compatible

The natural objection is that these two axes are contradictory. They aren't, and the piece that connects them is old and well understood: visibility without signing power.

The cleanest illustration comes from the BIP-32 standard for hierarchical deterministic wallets. From a seed you derive a tree of keys. Whoever holds the extended public key can derive all the child identifiers of that tree — sees the whole set, recognizes each element — and cannot produce a single signature. It's the key to the statement, not the key to the vault.

This property is not a blockchain property. It's a property of key derivation over elliptic curves, and it works equally well inside a Postgres, in a centralized system, with no block, no consensus and no network.

Applied to a lien registry, the shape is this. The lien identifiers of a single holder are derived hierarchically, so that each creditor recognizes only the relationship it takes part in and cannot link one record to another. Whoever holds that holder's extended key recognizes the whole tree — every charge, all the history — and cannot create, alter or release anything.

And the holder need not be a single one. Each regulator can keep its own, each institution its own within the scope of what falls to it. The result is that visibility is distributed too: for any given holder, few entities see the complete set, and none sees the complete set of everyone.

I described this arrangement in detail in a paper written in 2024 with Professor Henrique Gomes de Moura of UnB, in the context of a Regulated Liability Network. I make a point of recording what it was not: no new cryptographic primitive. Hierarchical wallets are a 2012 standard, stealth addresses had been running for years, an oracle is a textbook pattern. The contribution, if there is one, was the arrangement of who-sees-what. That's what this is about here too.

6. The toolkit, and what each piece costs

Nothing that follows requires a distributed ledger. All of them are techniques applicable to a central registry, and I've ordered them by increasing cost.

Merkle accumulators with exclusion proofs

The registry periodically publishes a cryptographic root of its state. An institution proves that its record is included — or, what matters more here, that an asset is not encumbered — without having to trust the operator's word. Cheap, well understood, and it solves the auditability problem without requiring anyone to see anyone else's content.

Pedersen commitments

The registry stores a commitment to the charge's value instead of the value. The world sees the commitment, not the number. Because the commitments add up among themselves, it's possible to prove that the sum of the liens on an asset doesn't exceed its value without revealing any of the parts. And whoever holds the opening secret reads the number — which gives the supervisor exactly what it needs and no one else. Cost: elliptic-curve operations, orders of magnitude cheaper than general-purpose zero-knowledge proofs.

Private set intersection (PSI)

The institution finds out whether asset X belongs to the set of encumbered assets without revealing X to the operator and without learning the rest of the set. It is, literally, the lien query with the metadata protected. It's been in production for years in other sectors. Cost: communication rounds and work proportional to the size of the set, mitigable with precomputation and partitioning by identifier range.

Private information retrieval (PIR)

Querying a registry without the server learning which row was requested. It's the most direct answer to the problem in section 3. High cost in the single-server case; substantially lower in multi-server schemes that don't collude — which is feasible precisely when the infrastructure has more than one operator, an arrangement the Brazilian registrar market already has.

Threshold custody of the supervisor's key

The ability to open the commitments or to walk a holder's tree is split so that no single person inside the central operator can de-anonymize anything on their own. Standard, cheap, and it addresses the concentration risk without changing the architecture.

I owe an honesty about this list: none of these pieces is free, and the cost is the reason they aren't the default. Single-server PIR is still expensive. PSI requires rethinking the query protocol, not just adding a library. Commitments require deciding who holds the opening key, which is a governance question before it's a technical one.

What I'm defending isn't that they're cheap. It's that their cost be a recorded decision, not an omission — that someone looked at the requirement, priced it and chose, rather than the requirement never having entered the specification.

7. What "technology-agnostic" ought to mean

The Central Bank's choice is defensible, and I don't say that out of diplomacy. With a financial system on its back, a centralized delivery that works is worth more than an elegant distributed architecture that never leaves the lab. The pilot had four years and wasn't converging. Cutting scope to deliver is engineering, not retreat.

But "technology-agnostic" cuts both ways. If the requirement is technology-agnostic, so is the defect.

The February 2025 report was read as a verdict on blockchain. It was a verdict on a requirement specification: privacy was defined as protection against everyone, in an arrangement where there's a third party with a legal mandate that isn't a peer. Swapping the distributed ledger for a central registry doesn't fix that specification. It moves the leak from the content to the query, from the participants to the operator, and from the history to the intent — which is the most valuable of the three.

The toolkit to handle this exists, it's public, it's peer-reviewed over more than a decade, and it doesn't depend on any technological bet. What it requires is that the requirement be written down.

The DREX lien layer is being designed right now. It's the cheapest moment there will ever be to put that line into the specification.