DEV Community: Shota Natenadze

Unlocking Institutional Finance on the XRP Ledger.

Shota Natenadze — Thu, 08 Oct 2026 12:52:51 +0000

How Permission Delegation, Confidential Transfers, Atomic Batch, Sponsored Fees and Dynamic MPTs come together

It is Sunday evening and a tariff announcement drops. If you run an event-driven strategy, you already know what it means. Oil falls at Monday's open, and there is real opportunity in being early.

You are holding $50 million in a tokenized assets. But it is Sunday. The clearing house is closed. Your bank is closed. Nobody is picking up. The tokens are sitting right there on your balance sheet and there is nothing you can do with it until someone in another time zone opens a laptop.

By the time they do, the market has already moved. You were right, and it did not matter.

Now run the same evening on the XRP Ledger. At 9pm on Sunday you pledge the tokens for stablecoins. Collateral and stablecoin change hands in the same instant, in about five seconds. No clearing house, no broker on call, no waiting for a payment rail to wake up.

Nothing about the asset changed between those two versions of Sunday. It was already tokenized in both. What changed is that in the second one, you could actually use it.

That is the difference between tokenizing an asset and mobilizing it, and it is where most of the industry is currently stuck. There are billions of dollars of tokenized funds, treasuries and money market instruments sitting on ledgers right now, doing roughly what they did on a spreadsheet.

The reason is not the technology of tokenizing. It is everything that has to happen afterwards. A regulated institution cannot move an asset unless it can control who inside the firm is allowed to move it, keep the token accurate as the underlying fund changes daily, guarantee that cash and collateral move together or not at all, keep its trading strategy off a public feed, and do all of it without holding a crypto asset its own rules forbid it from touching.

Public ledgers have not been able to offer all five at once. That is the actual blocker, and it has very little to do with blockchains being fast or cheap. Five features released under rippled 3.3.0 close those gaps one by one. The clearest way to see how, is to follow a single asset through its life, so the rest of this piece follows a hypothetical bank, XBank, as it issues a tokenized money market fund and takes it all the way to that Sunday night trade.

Issue and Delegate
XBank tokenizes its money market fund as XMMF using XRPL's Multi-Purpose Token standard. But XBank's internal governance requires them to distribute responsibilities based on internal risk matrix.

Permission Delegation is XRPL's native answer to role-based access: where one account can grant another account a scoped permission to act on its behalf, all enforced by the ledger, instead of an application layer. In XBank's case, treasury delegates a narrow capability to the trading desk: the ability to send XMMF payments. The desk can transact within that scope but cannot mint, burn, or modify governance.

2. Keep the Assets Current
XBank has gone through a change in regulation that impacts their prospectus, which requires them to revise their prospectus URI.

Dynamic MPTs extend the MPT standard by letting issuers mark specific token properties as updatable at the moment of creation, while everything else stays permanently locked. XBank uses this to declare that in the metadata and select compliance flags can evolve post-issuance. The mutability boundary is transparent on-ledger, and it is one-way: once a flag is enabled, it cannot be disabled. Counterparties know exactly what can change and what cannot.

This matters for the flow that follows. When XBank's trading desk swaps tokenised assets for stabelcoins, the counterparty needs confidence that the token they are receiving reflects the fund's current state, not an outdated snapshot. Dynamic MPTs keep the on-chain representation aligned with the off-chain reality of the fund, without reissuing.

3. Make it Private
Confidential Transfers add a privacy layer to MPT transfers: amounts are encrypted on-ledger using zero-knowledge proofs, so the ledger can verify that balances are sufficient without ever seeing the actual figures. Observers see that a transfer occurred but cannot read the amount.

What makes the design workable for institutions is selective decryption. The sender holds a decryption key that can be shared with specific parties: internal auditors, external auditors, the regulator. Public observers see nothing; permissioned reviewers see exactly what they need for quarterly reporting, tax filings, or supervisory review. Confidentiality is also opt-in per transaction, so a fund can keep the collateral leg private while leaving a regulated cash leg transparent, if its compliance posture calls for it.

4.Abstract the Fees
Every XRPL transaction requires a small XRP fee. For a regulated fund, holding XRP, directly or indirectly, is not permitted under Irish, UK, or most EU law. The same blocker hits US '40 Act funds, pension funds, and insurers. The technical requirement to transact contradicts the legal requirement to operate.

Sponsored Fees and Reserves allow one XRPL account to cover the transaction fees and reserve requirements on behalf of another, removing the need for the transacting account to hold any XRP at all. For XBank, a third-party sponsor (the marketplace, a tokenization provider) pays the XRP fees on behalf of the fund. The fund never holds or touches XRP. From its accounting and compliance perspective, it operates exclusively in regulated assets. This is the same model that lets a TradFi fund use SWIFT without paying SWIFT directly: a service layer underneath that the fund never sees.

The Aviva pilot, currently in flight, is the first production-scale test of this pattern and every institutional MMF and RWA program coming to XRPL will be a natural beneficiary of fees sponsorship at the first transaction.

Looking forward
Together, all five features they move XRPL past issuance into the phase that actually matters: collateral mobility. A regulated institution can issue a tokenized asset, keep it current, trade it atomically and privately, and do all of it without holding a crypto asset or breaking its compliance posture. Multiple financial institutions are lined up behind this release like Aviva and Licuido.

LendingProtocolV1_1: Closed-Ended Vaults and Cash-Basis Accounting

Shota Natenadze — Wed, 30 Sep 2026 15:39:48 +0000

The Single Asset Vault has two modes: open-ended and closed-ended. Both use the same Vault ledger object and the same transaction types (VaultCreate, VaultDeposit, VaultWithdraw, VaultSet). The difference is when capital can move in and out.

Open-ended vaults accept deposits and process withdrawals at any time. When a depositor sends assets, they receive shares (MPTs) at the current price per share (PPS = AssetsTotal / SharesTotal). When they withdraw, shares are burned and assets returned at whatever PPS is at that moment. Capital flows are continuous. Open-ended vaults are fully usable for non-lending purposes (e.g., pooled custody, shared treasury), but loan brokers cannot be attached to them.

Closed-ended vaults (up for validator voting under the LendingProtocolV1_1 amendment) have a fixed lifecycle with three phases:

1. Subscription. The vault is open for deposits. Shares are minted. The vault owner sets the subscription window via SubscriptionDate.

2. Investment. The vault closes to new deposits (the protocol enforces this automatically). The vault owner deploys capital into loans. Interest is returned to the vault via VaultDeposit with the tfVaultDonation flag, which increases AssetsTotal without minting new shares, raising PPS for all existing holders.

3. Redemption. After RedemptionDate, the vault reopens for withdrawals. Depositors redeem shares at the final PPS (principal plus earned yield).

Closed-ended vaults are created by setting VaultKind = 1 on VaultCreatealong with SubscriptionDate and RedemptionDate. This field is immutable after creation.

Under LendingProtocolV1_1, LoanBrokerSet requires the vault to be closed-ended and returns tecNO_PERMISSION on an open-ended vault. Nothing else about open-ended vaults changes: they still exist and still accept deposits and withdrawals at any time. The only thing blocked is setting up a loan broker on them.

What LendingProtocolV1_1 introduces

The LendingProtocolV1_1 amendment extends the LendingProtocol and SingleAssetVault amendments with two changes:

First, it introduces the closed-ended vault as a new vault type that users can create. Users can still create both open-ended and closed-ended vaults, but after this amendment is enabled, new loan brokers can only be created against closed-ended vaults.

Second, it introduces cash-basis accounting. Under the original LendingProtocol amendment, all scheduled interest on a loan was recognized at the time of loan origination: the moment the loan was created, the full expected interest was recorded as income in the vault's accounting. LendingProtocolV1_1 changes this so that interest is only recognized as income when payments are actually made. This is a more conservative and accurate accounting model, and it means the vault's AssetsTotal only reflects interest that has actually been received, not interest that is expected in the future.

Why the Closed and Open-Ended Vaults ship together

Lending is restricted to closed-ended vaults because of how share pricing works. In an open-ended vault, anyone can enter or exit at any time, so a depositor could time their entry and exit around a change in price per share and capture yield they did not earn. Closed-ended vaults avoid this by design: once the subscription window closes, no new shares can be minted, so there is no way to enter mid-term.

Enabling lending on open-ended vaults would require a mechanism that prevents this kind of timing capture under continuous entry and exit. That is open design work, to be scheduled for an upcoming release.

The decision was to ship the closed-ended vault first and require it to activate together with the original Lending Protocol and the Single Asset Vault.

What this means for the amendment vote

Three amendments need to activate for lending to go live on mainnet:
LendingProtocolV1_1 goes together with the LendingProtocol and SingleAssetVault. LendingProtocol is the base lending engine: loan brokers, loan origination, repayment, default handling, and first-loss capital. SingleAssetVault is the base vault primitive that both open-ended and closed-ended vaults build on.