The Four Plumbing Problems of Tokenised Finance

Tokenised real-world assets have reached $29.297 billion in on-chain market cap, with $2.53 billion deployed in DeFi as collateral or vault supply. And that works out to a DeFi utilisation rate of roughly 8% across the whole category.

The remaining 91.6% sits in permissioned wallets, earning yield, transferable but inert. They are on-chain, the way a car is in a garage, but parked. This right here is why I believe the gap between issuance and utilisation is the next phase RWAs have to solve. And the challenge of solving it isn’t a single problem. It’s four.

Problem One: Valuation

How does the blockchain know the price and value of a RWA, especially since it can only see its own state?

The answer to that is called NAV, an acronym for Net Asset Value. Usually, a smart contract on Ethereum has no idea whether a T-bill paid its coupon, a property’s tenant defaulted, or the Fed has done anything at all. However, with the help of NAV, a pricing unit computed daily (for some asset classes), and linked to an Oracle-like chainlink, which shows the price of the said asset, a blockchain can now emit the most updated prices of the asset per NAV update.

Here’s an illustration I like a lot: a traditional fund administrator (typically a large bank like BNY Mellon, which custodies BlackRock’s BUIDL) gets to compute net asset value daily through a process that involves pricing vendors, custodians, and a refined regulatory framework. The number is then pushed onto the blockchain via an oracle, which is essentially a signed message saying “the NAV of this fund is $1.0023 as of this timestamp, and here’s the cryptographic proof”.

Smart contracts read from this oracle, and that’s how we attempt to solve the valuation problem. But the hard part isn’t the technology. The oracle itself is a simple cryptographic pipe. The risk question is, what happens to the plumbing behind a daily NAV calculation that relies on a series of telephone calls/chats between fund administrators, custodians, and pricing vendors under market stress? And since the cadence, typically once a day, this means it has to be fast enough to keep the on-chain price meaningfully close to the off-chain price?

Truth is, as of the time of writing this, what happens to NAV reliability under stress is genuinely unknown; it’s still uncharted because the architecture hasn’t been stress-tested to such a scale. While current NAV solutions don’t magically solve problem one, it’s solved it enough that the rest of the stack can be built on top.

And that brings us to the next problem.

Problem Two: Cash

Once you know what the asset is worth, thanks to the NAV x Oracle sync, you have a second problem: how do you actually pay for it at the speed of the chain?

This is the problem that, until recently, very few people talked about because there was no existing solution, it had to be manual, and it definitely causes speed problems. Here’s what I mean: Tokenised T-bills trade 24/7 on the blockchain. The token can move from one wallet to another in seconds. But the cash that backs the transaction, the actual US dollars that need to flow when somebody redeems, still moves through banking rails that settle on T+1 or T+2. So that means the token is instant, the cash is usually not.

Tokenised T-bills could be held, transferred, and earn yield, and that, for many institutional users, was enough. But the moment anyone wants to use the tokenised position, pledging it as collateral, rotating it into another trade, or deploying it into a hedge, the two-day gap becomes an actual problem.

Why? Well, it’s because a two-day liquidation cycle is incompatible with anything that wants to operate at on-chain speed. This is the gap that Grove Basin and Upshift Clear, in their different ways, have tried to solve. I think it is a timely solution:

• Grove Basin, built by Grove Labs, a Steakhouse Financial subsidiary, operating as a “Star” in the Sky ecosystem, uses Sky’s balance sheet as principal. It commits up to $1 billion in daily liquidity, draws inspiration from Sky’s PSM3 (Peg Stability Module) architecture, and recently launched with BUIDL ($2.58B), JTRSY ($1.24B), and institutional access via Anchorage, Galaxy and FalconX.
• Upshift Clear runs an agency model: per-asset vaults where USDC LPs explicitly buy the redemption-premium spread as a yield product. Their solution was built on August Digital’s prime-brokerage rails. They launched with Superstate’s USCC ($267M AUM, now managed by Bitwise) and use Chainlink oracles to verify redemption triggers.

These two systems are actually designed to solve problem two, and both are, in TradFi terms, the redemption leg of prime brokerage that is reimplemented on-chain. It is, in fact, the principal versus agency distinction, and that is the next piece I will write on, so I won’t belabour it here.

What matters for the framework is that the cash problem is suddenly being solved by multiple teams, in multiple ways, with real capital committed. However, the cash layer also extends downward into stablecoin design itself. USDC, USDT, USDS, PYUSD and the rest are the prerequisites. Without stablecoin rails that can absorb redemption volume at scale, none of the Basin/Clear architecture makes sense. The fact that there is now over $300B in stablecoin float, with daily settled volumes that have started to rival the traditional payments giants, is what makes the cash layer’s recent breakthroughs possible. But that $300B is just a headline number; a meaningful share of stablecoin supply is itself locked up: posted as collateral in other stablecoin systems, frozen in bridge escrows, parked in protocol reserves, or sitting in yield wrappers.

The economically active float, the stablecoins genuinely free to absorb a redemption surge, is smaller than the topline. And this means it likely has the same inert-capital problem as the layer it supports. Still, none of these matters if the asset can’t legally move to the wallet trying to redeem it, which is the next problem.

Problem Three: Identity

Almost every meaningful tokenised real-world asset is permissioned. BUIDL can only be held by KYC’d investors who have completed Securitise’s onboarding. JTRSY has its own permissioning, layered through Centrifuge. Tokenised private credit is restricted to accredited or qualified investors in most jurisdictions. Tokenised equities can only be held by investors in specific countries who satisfy specific suitability requirements.

The token contract enforces these restrictions through transfer logic: try to send BUIDL to a non-whitelisted wallet, and the transaction reverts. Securities regulation in essentially every developed jurisdiction restricts who can hold what, regardless of whether the security is recorded on paper, in a transfer agent’s database, or as an ERC-3643 token.

The identity problem is therefore: how do you express off-chain investor status as an on-chain state that smart contracts can enforce automatically?

The current state solution is essentially “the issuer maintains a list of approved wallets, and the smart contract checks the list before allowing transfers”. It works, but sadly, it works just the way airport security works: robustly enough most of the time, brittle in ways that nobody wants to examine too closely.

The deeper irony is that while identity is technically ‘solved’ via these managed allow-lists, the way it is solved is precisely what strangulates downstream composability. An allow-list does not bridge to DeFi; it walls it off. Because these compliance frameworks are implemented natively by individual issuers or siloed tokenisation platforms, identity remains entirely fragmented.

Here’s what I mean: If an investor passes KYC on Securitize to hold BUIDL, that on-chain identity credential does not inherently permit them to touch a Centrifuge pool or a WisdomTree asset. This fragmentation means that instead of a unified, open-market liquidity pool, we have a brittle archipelago of permissioned garden walls, where the hurdle is in getting two different platform smart contracts to agree on the proof of who the user is. The infrastructure for compliant permissioning works. What it doesn’t do, by design, is let tokenised RWAs interact freely with permissionless DeFi, which is what creates the fourth problem.

Problem Four: Composability

Composability is what happens when tokenised assets can be combined and used as components by other on-chain protocols without bilateral integrations.

For native crypto-assets, DeFi has largely delivered this: any ERC-20 can be collateral in Aave, swapped on Uniswap, deposited into Yearn, and hedged on Hyperliquid. With RWAs (many of which are ERC-3643 or ERC-1400), can this level of composability be possible?

• Well, yes, to some extent, like Janus Henderson Anemoy JAAA, has $398M deployed in DeFi against $424M in on-chain market cap, a utilisation rate of 250.97%. The number is above 100% because the asset is being recursively deployed, posted as collateral, borrowed against, redeployed, and stacked through leverage loops.
• And No in other extent like, BlackRock BUIDL, the largest tokenised treasury by some distance at $3.226B, which has 0.58% utilisation.

The difference isn’t the underlying risk profile; both are institutional debt wrappers from world-class managers. The difference is the product intent at genesis. JAAA was engineered to be a live, programmable money-lego; BUIDL was architected to be an institutional parking spot.

The point is, the downstream infrastructure exists. Morpho, Aave, and Kamino can list anything. What determines whether a tokenised asset actually composes is the upstream design decision at issuance (from problem three, all the way up to problem one).

Where this leaves us

My first thought is that the utility cannot be retrofitted. You cannot launch a permissioned, static asset wrapper and expect DeFi to figure out how to use it.

Composable RWAs are, in fact, one of the most interesting topics. But valuation is largely solved for liquid assets. Cash is being solved by multiple teams, with real capital committed. Identity isn’t broken so much as deliberately constrained, which constrains composability downstream. And composability, for the most part, is still the cherry on top for a full DeFi experience.

I am keen to write more on Real World Assets, and my thoughts do take this framework as their starting point.