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.
Top comments (0)