Permissioned collateral, permissionless liquidity

Several of the largest DeFi lending protocols are moving in the same direction: bring institutions onchain, support tokenized real-world assets, and eventually let those assets serve as collateral. Compound recently launched an institutional market with higher LTVs and a curated collateral set. Aave has already operated permissioned markets around tokenized funds. The direction is clear. Treasuries, funds, equities, and other tokenized assets are expected to become part of onchain credit markets.

But look at what is actually being accepted as collateral today: ETH, wstETH, WBTC, cbBTC. These are still crypto assets, even when they sit behind an institutional market structure. The tokenized treasury held with a qualified custodian, which is much closer to what a bank or institutional borrower may actually want to finance, is still mostly a roadmap item.

I do not think this is only a matter of sequencing. There is a more basic problem that needs a clean answer first: what happens when the loan must be liquidated?

The liquidation problem

A borrower deposits a tokenized fund, borrows USDC against it, and eventually the position becomes undercollateralized. A normal DeFi lending protocol has a straightforward response. It seizes collateral and sells it to a liquidator.

That works because assets such as ETH and WBTC have an effectively open buyer set. Anyone with sufficient capital can participate in the liquidation. A transfer-restricted security is different. Its buyer set is limited to addresses approved under the issuer’s transfer rules. The issuer or transfer agent may have approved eleven addresses, and none of them may be active when the liquidation happens.

The smart contract cannot simply sell the token to somebody else. The token itself may reject the transfer. The protocol is then left with debt it needs to close and collateral it cannot freely dispose of, while suppliers on the other side of the market are still expecting repayment.

Some designs try to solve this with a wrapper. The underlying asset remains restricted while the wrapper becomes freely transferable. This makes the DeFi side easier, but it does not necessarily solve the underlying compliance problem. Whoever acquires the wrapper still holds an economic interest in an asset they may never have been eligible to own. The restriction has been moved to another layer rather than removed.

Separate collateral from liquidity

I think the cleaner model starts by treating the lending market as two separate systems.

The liquidity side is USDC. A supplier depositing USDC into a lending pool is not taking custody of a security, so there is little reason to restrict that side of the market. In fact, doing so would weaken the market by reducing liquidity, utilization, and resilience.

The collateral side is different. If the collateral is a regulated or transfer-restricted asset, then every party that may actually become its holder has to satisfy the issuer’s rules. That group should remain permissioned.

The design principle is therefore simple: permissioned collateral, permissionless liquidity.

Keel, the protocol I am building around this idea, keeps those two sides separate and places the market contract between them. The market contract becomes the holder of record for collateral deposited into that market and is approved by the issuer when the asset is listed.

This changes the liquidation problem. When a borrower goes underwater, the protocol does not first need to transfer the collateral somewhere else. The collateral is already held by the market contract. Seizure becomes an internal accounting change rather than an external token transfer, so the issuer’s transfer restrictions do not block the first step of liquidation.

The remaining problem is converting that collateral back into USDC. That process does not need to depend entirely on an immediate market sale.

The liquidation waterfall

Keel handles liquidation through three stages, each with a defined deadline.

The first stage is an auction available only to addresses eligible to hold the underlying asset. The auction begins slightly below the asset’s reference value and decays over a fixed period, currently six hours, until it reaches a floor. That floor is tied to the haircut already used when the protocol calculated how much could safely be borrowed against the asset.

This connection matters. A lending market should not assume one recovery value when setting LTV and then depend on a completely different value during liquidation. If the protocol lends against an asset on the assumption that it can safely recover ninety cents on the dollar, the liquidation system should be designed around the same assumption.

If the auction does not clear all the collateral, the second stage begins: issuer redemption. The remaining collateral is redeemed according to terms committed when the asset was listed. Those terms include the settlement period, daily redemption capacity, and other relevant constraints.

These commitments should directly affect LTV. An asset that reliably redeems on the same day should support more borrowing capacity than an otherwise similar fund that settles in two days. The protocol’s exposure is not determined by NAV alone. It also depends on the time between deciding that collateral must be monetized and actually receiving cash.

Redemption capacity matters for the same reason. A market should not lend $100 million against an asset whose issuer can redeem only $2 million per day and still treat the collateral as immediately liquid. That mismatch has to appear in the risk model before a liquidation occurs.

The third stage is the reserve. If the issuer fails to settle within its committed redemption period plus a defined grace period, the remaining shortfall is written against the market reserve. The asset is marked impaired, and new borrowing against it stops. Any broader socialization of losses should require an explicit governance decision rather than happening automatically.

The purpose of this waterfall is to give every liquidation a bounded path to resolution. It should still reach a known terminal state if the borrower does nothing, no eligible liquidator submits a bid, and the issuer fails to settle. A permissionless liquidation model cannot make that guarantee when the collateral itself is transfer restricted.

LTV should reflect the path to cash

The liquidation waterfall is the center of the design. Most of the remaining architecture exists to make its assumptions enforceable.

LTV should not be a number chosen in isolation. In Keel, it is derived from several components: a base haircut, valuation confidence, redemption latency, and the market’s exposure relative to the issuer’s committed redemption capacity.

The last component becomes important under stress. Suppose an issuer can redeem $10 million per day. A market with $1 million of exposure does not face the same liquidity risk as one with $50 million of exposure, even if the underlying asset and its NAV are identical. As aggregate exposure approaches the amount that can realistically be redeemed, borrow capacity should fall.

Valuation data needs similar treatment. If the market relies on fund NAV and that NAV becomes stale, new borrowing power against the asset should fall to zero. Existing liquidation processes, however, must continue. Preventing the creation of new risk is different from disabling the mechanism used to resolve existing risk.

Real-world collateral has a lifecycle

Crypto collateral generally does not mature. Treasuries, bonds, private credit instruments, and many other real-world assets do. A lending protocol that accepts them has to account for that lifecycle.

A collateral token may mature while it is still supporting an active loan. In Keel, cash received at maturity is applied to the borrower’s debt first. Borrowing power also decreases before the maturity date rather than remaining constant until the final day. A borrower should not be able to take a large loan against an instrument that is about to stop being collateral and become cash the protocol has not yet received.

Coupon payments introduce related questions. These may look like secondary implementation details when viewed from a crypto lending model, but they become part of the core risk system once the collateral behaves like a financial instrument rather than a perpetual token.

Compliance should produce evidence

Risk and compliance decisions should also be reproducible after the fact.

Keel versions its risk policy. When the protocol allows a borrow, executes a seizure, fills an auction, or processes settlement, the transaction records the policy version used at that moment together with the relevant oracle state and eligibility reference.

If somebody asks six months later why a borrower was allowed to take a particular loan at a particular LTV, the answer should not require reconstructing the decision from governance discussions, dashboards, and PDFs. The execution record should contain enough information to resolve the policy version, retrieve the relevant parameters and oracle state, and recompute the result.

That is what compliance as code means to me. I have spent much of my work on tokenization infrastructure, including coauthoring ERC-7518, and there is a meaningful difference between rules a contract actually enforces and rules that exist only in documentation. A lending layer built for regulated assets needs the same distinction.

Keep liquidity modular

The core protocol does not need to care where its USDC originates. A market can begin with its own supply pool and later connect to a larger liquidity hub as a spoke.

That separation is deliberate. Permissionless stablecoin liquidity is not the difficult part of this system. The difficult part is making restricted collateral predictable enough that open liquidity can safely finance it.

What Keel is not

Keel is not a tokenization platform and does not issue the underlying assets. It lends against assets issued elsewhere. It is also not designed for undercollateralized credit or cross-chain collateral.

There is one legal question I do not think the architecture should try to hide: whether a smart contract can validly act as holder of record for a particular asset, issuer, and jurisdiction. Keel treats that as a listing condition and a question for counsel. Designing around it with a wrapper would make the contract architecture cleaner while leaving the actual legal problem unresolved.

What comes next

The next step is implementation: the core contracts, eligibility adapters, redemption-agent interface, and an invariant suite built around failure cases rather than only the happy path. The system needs to hold when an issuer never settles, eligible liquidators never bid, valuation data becomes stale, redemption capacity is exhausted, or several positions enter liquidation at the same time.

A testnet deployment and a deeper treatment of the risk model will follow.

The larger idea is simple. Real-world assets do not fail in the same way as crypto collateral, so they should not inherit a liquidation model designed for assets that anybody can hold and sell at any time. If tokenized assets are going to become useful collateral onchain, the lending protocol has to model the path from collateral to cash explicitly. Everything else depends on that.