DEV Community: William Flores

Institutional Privacy On-Chain Is Three Separate Problems — And Most People Are Conflating Them

William Flores — Wed, 01 Jul 2026 11:59:33 +0000

When institutional builders talk about privacy on public blockchains, they usually mean one of three very different things — and conflating them is how you end up with infrastructure that solves the wrong problem.

This week Stellar shipped a developer preview of Confidential Tokens: Pedersen commitment-based private balances for any SEP-41 token, with an auditor view key and selective disclosure. Around the same time, XRPL's Permissioned Domains (XLS-80) went live on mainnet, gating participation in restricted venues based on verified credentials. Both are real institutional infrastructure. Neither one is the same thing.

And neither one answers the question institutions actually ask when they sit down with legal and compliance: what happens when a loan goes bad?

Here is how I think about the three layers.

Layer 1: Access

Who is allowed to participate?

This is what XRPL's Permissioned Domains solve. A Permissioned Domain is a reusable rule layer on the ledger. It holds a set of credential requirements — issued by authorized issuers, accepted by the account holder — and any protocol feature (a lending vault, a DEX) can check domain membership before letting an account in.

The domain does not hold assets. It does not do business logic. It is purely an access control check: does this account hold the right credentials to enter this venue?

For institutional lenders, this is the compliance onboarding layer. Before a borrower can interact with an XLS-66 lending vault, the Permissioned Domain can require that they hold a KYC credential, an accredited investor attestation, or a jurisdiction-specific clearance. The ledger enforces this. No human has to check at runtime.

The privacy property: counterparty privacy. An institution can create a restricted lending pool where only credentialed participants can interact. The general public cannot participate, but the ledger still provides public finality for the transactions that do occur.

Layer 2: Visibility

What can observers see about what is happening?

This is what Stellar's Confidential Tokens solve — and what XRPL does not currently have at the transfer layer.

Confidential Tokens use a cryptographic commitment scheme (Pedersen commitments verified by a ZK proof system called UltraHonk, implemented by Nethermind) to hide balance and transfer amounts. An observer can see that a transfer occurred between two addresses — sender and recipient remain visible — but cannot see how much moved.

For institutions managing treasury positions or making large settlements, visible amounts create information leakage problems. A sophisticated observer watching the blockchain can infer trading strategy from transfer sizes. Confidential Tokens cut off that leakage at the transfer layer.

Stellar's preview includes an auditor view key — a designated compliance auditor can see the amounts and balances for assets inside the confidential wrapper. This is selective disclosure: prove a specific fact to a specific party without exposing everything. The same instinct as Ward's replay receipt, applied at a different layer.

The privacy property: economic visibility. What observers can learn about value movement is minimized without removing the public finality that makes the ledger useful.

Layer 3: Resolution

What happens when the credit event occurs?

Neither of the above layers answers this question. And for institutional lending, it is the question that matters most.

A loan can be made between credentialed parties (access solved), with amounts hidden from public view (visibility solved), and still default. When it does, someone has to decide: who absorbs the loss, in what order, how much, verifiably? That decision has historically been made by a person — a servicer, a committee, an admin key holder. The person can be pressured. The person can be wrong. The person is an attack surface.

The resolution layer is the part of the institutional lending stack that removes that person from the moment of default. It reads authoritative on-chain facts — the loan state, the first-loss capital, the policy — applies fixed rules, and returns an answer that any party can independently re-derive against the ledger. No custody. No discretion. No override.

This is where Ward sits. Not at the access layer (that is Permissioned Domains). Not at the visibility layer (that is confidential transfer schemes). At the resolution layer: what happens deterministically, verifiably, and non-custodially when the loan defaults.

Why institutions need all three

The instinct to reach for "privacy" as a single concept is understandable — institutional participants are accustomed to private markets where everything is confidential by default. But on-chain systems require you to be precise about which properties you actually need and at which layer you need them.

Consider a concrete scenario: an institutional lender deploys capital into a permissioned XLS-66 vault. The vault only admits credentialed borrowers (Layer 1 — access). The loan amounts are not visible to external observers (Layer 2 — visibility). After 90 days, the borrower defaults.

Now what?

The access layer cannot help — it was only relevant at entry. The visibility layer cannot help — hiding the default amount from observers does not resolve who takes the loss. What the institution needs is a third layer: a deterministic system that reads the on-chain facts, applies the waterfall, computes the depositor loss after first-loss capital absorbs its share, and produces a result that is verifiable, re-derivable, and identical regardless of who runs it.

Without that third layer, you have a "private" lending protocol that still handles defaults by committee. The privacy work gets undone the moment the credit event creates a dispute.

The one-line framing

After thinking through the stack, here is the cleanest way I have found to say it:

Privacy answers who can see and who can enter. Resolution answers what happens when the loan defaults.

They are not the same problem. They require different tools. And institutions need both.

What we are building

At Ward Protocol, we are building the resolution layer for XLS-66 lending vaults on the XRP Ledger. Ward reads on-chain facts, applies fixed rules, and returns unsigned resolution outputs that institutions sign — never holding keys, never exercising discretion.

The core invariant is ward_signed = False. That constraint is formally verified and independently re-checkable. The safety proofs are public:

# Install z3
pip install z3-solver

# Re-check the conservation invariant yourself
python ward_loss_conservation.py
# Returns: PROVEN (obligation UNSAT) — every unit owed accounted for exactly once

The validator is aligned to the finalized XLS-66 object model and running on Devnet. The source code is open: github.com/wflores9/Ward-Protocol-OS.

We are in the XRPL Make Waves hackathon and building toward the same XLS-66 mainnet activation the rest of the ecosystem is waiting for.

If you are building on XLS-65/66 and thinking about the default resolution question, I would like to talk — reach out on X @wardprotocol.

When an On-Chain Loan Defaults: The Mechanics, and the Options for Resolving It

William Flores — Fri, 26 Jun 2026 04:02:48 +0000

On-chain lending is arriving on the XRP Ledger in earnest. XLS-65 (Single Asset Vault) and XLS-66 (Lending Protocol) bring native lending and borrowing into the protocol, and they shipped through one of the most rigorous review processes in XRPL's history.

Most of the conversation so far has been about the happy path: how vaults aggregate capital, how loans get originated, how interest accrues. That's the easy 95%. This post is about the other 5% — the part that's actually hard, and that determines whether the whole system is trustworthy: what happens when a loan defaults.

I want to do two things here, as concretely as I can: walk through how default actually works mechanically in this kind of system, where it goes wrong, and then lay out the real options for resolving it — with honest tradeoffs, not a single answer.

Part 1: How a default actually happens

A loan in this model isn't a single object doing everything. There are a few moving pieces:

A Vault (XLS-65) holds pooled assets from depositors. Depositors get shares; the vault tracks total assets and any unrealized loss.
A Loan Broker sits between the vault and borrowers. It originates loans against the vault's capital and, importantly, can post First-Loss Capital — a cushion that absorbs initial losses so depositors aren't the first to take the hit.
A Loan is the agreement itself: principal, interest rate, payment schedule, the parties.

Default isn't a flag that magically appears. In the XLS-66 model, when a borrower fails to meet their obligations, the loan can be moved into a defaulted state through a management action by the broker (a LoanManage-type transaction), typically after a grace period. That's an important design point: default is an explicit, observable on-chain event with an actor and a transaction behind it — not an ambient condition.

So far, so clean. The mechanics are well-defined. The hard part isn't detecting that a default happened. The hard part is everything that comes after.

Part 2: Where it actually goes bad

Default detection is the easy part. Loss allocation is where the complexity — and the risk — lives. Several things have to be answered, and each is a place where systems break.

1. How much was actually lost?

This sounds trivial and isn't. The loss isn't just "the loan amount." It's the outstanding principal and interest, minus whatever First-Loss Capital absorbs, minus any recovery. Get the order of operations wrong — for instance, paying out on the gross loan instead of the net loss after first-loss capital — and you over-distribute, draining the vault beyond the real loss. This is a correctness bug that looks fine in the happy path and only bites on default.

2. Who absorbs it, and in what order?

First-loss capital, then equity tranches, then senior depositors — the waterfall. In TradFi securitizations this is spelled out in hundreds of pages of legal documents and executed by a servicer. On-chain, it has to be encoded somewhere, and the question is where, and who can change it.

3. Who computes and executes the resolution?

This is the real fork in the road, and it's where the design choices diverge sharply. Someone — or something — has to look at the facts, compute the outcome, and move the funds. That decision is the rest of this post.

The failure modes cluster around #3. The XRPL lending protocol's own security process surfaced exactly these kinds of issues during testing — an inverted invariant that could have let phantom collateral go undetected, rounding errors, and specification-vs-implementation discrepancies. Those are the bugs that live in the resolution path, not the origination path. Default is where subtle errors become expensive.

Part 3: The options for resolving it

Here are the real approaches, with what each is good and bad at. None is strictly correct — they trade off differently depending on who's lending, to whom, and under what trust assumptions.

Option A: Off-chain servicer / workout process

A human or institution decides the outcome, the way TradFi does today.

Good: handles ambiguity and edge cases human judgment is suited to; legally familiar; flexible.
Bad: slow; opaque; discretionary. The affected parties have to trust the servicer's decision, often without being able to independently verify it. It's also a single point of pressure — a servicer can be lobbied, captured, or simply wrong. And it doesn't match the settlement speed of the rails the asset now lives on.

Option B: Admin / multisig discretion

A privileged key or a multisig of insiders executes resolution.

Good: fast to build; flexible; can correct mistakes.
Bad: the privileged key is the attack surface. If it's compromised, it can release or freeze funds outside any rule. Even when honest, it asks every other participant to trust that the insiders won't act against them. This is the pattern behind a large share of DeFi loss events — the trusted party was the failure.

Option C: Pure smart-contract automation

The resolution logic is encoded in a contract that holds the funds and executes automatically.

Good: deterministic; no human in the loop; fast.
Bad: the contract now holds value, which makes it the honeypot. Bugs are exploitable for real money (see: most of DeFi's exploit history). Upgradeability reintroduces an admin key — and the discretion problem with it. And encoding a full loss waterfall correctly in-contract is genuinely hard, as the testing findings above suggest.

Option D: Native protocol primitives (first-loss capital)

The protocol itself absorbs some loss via built-in mechanisms like First-Loss Capital.

Good: built-in, battle-tested as part of the amendment, no extra trust assumption.
Bad: it's a cushion, not a full resolution. It absorbs initial loss to protect depositors, but it doesn't by itself answer multi-party waterfalls, disputes, or produce an auditable record of why a given party received what they did. It's necessary, not sufficient, for complex structures.

Option E: A deterministic, non-custodial resolution layer

A separate layer reads ledger state, computes the outcome by fixed rule, and returns an unsigned result the rightful party signs — holding no funds or keys itself.

Good: deterministic (same facts, same outcome); re-derivable by any third party (you can check it rather than trust it); non-custodial, so there's no honeypot and no admin key to steal or override. Errors are detectable because the result can be replayed against the ledger.
Bad: it's a newer pattern with less production history; it depends on the relevant facts being fully on-chain and verifiable (if a key input lives off-chain or is asserted rather than derived, the guarantee is only as good as that input); and for simple single-lender vaults it may be more machinery than the situation needs.

So which is right?

Honestly: it depends, and most real deployments will combine several. Native first-loss capital (D) is almost certainly part of any serious design. Simple vaults may be fine with protocol primitives plus minimal automation. Complex, multi-party, institutional structures — where auditability and non-discretion are requirements, not nice-to-haves — are where the deterministic, verifiable approaches (E) earn their complexity. And there will be cases where genuine ambiguity means a human (A) or an arbiter still belongs in the loop, ideally bounded by rules rather than given open discretion.

The honest open questions, for me, are:

How much of real-world loss allocation can actually be made deterministic, versus how much genuinely requires judgment?
When an input to resolution isn't natively on-chain, what's the right way to bind it so the resolution stays verifiable?
How do you handle disputes without reintroducing exactly the discretionary trust you were trying to remove?

I'm building one of the approaches above — a deterministic, non-custodial resolution layer (Ward) — so I have a horse in this race, and I'll be transparent that it's early and still being aligned to the finalized XLS-66 model. But I'm genuinely more interested, right now, in the shape of the problem than in selling a single answer to it. The resolution layer of on-chain lending is underexplored relative to how much it matters, and I'd rather see it figured out well than figured out fast.

If you're working on any part of this — origination, vaults, risk, resolution, or the messy default path specifically — I'd like to compare notes.

If you spot something wrong in the mechanics above, tell me — I'd rather be corrected than confident.