The tokenisation of real-world assets has stopped being an experimental promise. By mid-2026, the value distributed in RWA stands at around 26 billion dollars, spread across more than thirty different networks. Real estate, bonds, private debt, commodities: everything that once lived in a notarial register or a bank deposit is beginning to have a digital representation tradable in seconds.
But that promise of instant liquidity conceals a question most issuers would rather not ask aloud: when something fails, who answers for it? And above all, is it the asset that failed, the token, or the bridge between them?
The underlying problem: the token is not the asset
In a conventional DeFi protocol, the smart contract is the product. The code is audited, the private keys are secured and, to a large extent, the system stands on its own. With RWA the position is different: the on-chain token is only a claim over something that exists outside it — a bond in a custodian’s vault, a loan on a debtor’s balance sheet, a deed in a land registry. The attack surface is no longer only the Solidity code. It now includes legal documents, custodians, oracles and human approval flows that no smart contract audit is designed to review.
That gap between the technical and the legal is precisely the ground on which arbitration ought to play a central role, and where there is today more uncertainty than certainty.
Two different ways for the system to fail
It is worth distinguishing two kinds of failure, because the responses — technical, legal and in terms of liability — are entirely different.
When the oracle fails. In February 2026, the lending protocol Moonwell suffered a misconfiguration in one of its oracles deployed on Base: the feed reported the price of cbETH using the raw cbETH/ETH rate without multiplying it by the dollar price of ETH, valuing the asset at 1.12 dollars instead of its roughly 2,200 dollars. Liquidation bots drained more than a thousand cbETH within minutes, producing losses of 1.78 million dollars. This was not a hack in the classical sense — nobody exploited a reentrancy vulnerability or stole a private key. It was an incorrect price input that the contract executed exactly as it had been programmed to. “Code as law” worked perfectly; the problem is that the law had been badly written.
When the underlying asset fails, not the code. RealT, the platform that tokenised some 700 rental homes mostly in Detroit for a value close to 140 million dollars, is the inverse and perhaps more instructive example. In July 2026 the platform entered voluntary liquidation with barely 640,000 dollars on deposit against between 14,000 and 22,000 affected investors. What matters is not an exploit: the legal and technical structure worked exactly as designed throughout. The problem was that dozens of properties stood empty, with taxes, water bills and blight fines unpaid, until the city of Detroit brought one of the largest code-enforcement actions in its history. A court ordered tenants’ rents to be paid directly into an escrow account, and months later the platform itself acknowledged that “the model no longer works”. The token was never hacked. The asset simply stopped generating the value the token promised to represent.
Why this is, at bottom, a liability problem and not merely a coding one
Both cases illustrate the same void from opposite angles: an audit of a smart contract can certify that the code does what it says it does, but it cannot certify that what it claims to represent is true, nor that whoever maintains it has the capacity — or the incentives — to sustain it.
When Moonwell’s oracle failed, who should answer: the team that deployed the wrapper, the feed provider, or the governance that approved the change without a real-time alert on administrative roles? When RealT collapsed, does liability rest with the smart contract auditor, the property manager, the vehicle that issued the tokens, or a legal framework that never anticipated that scenario?
These are not questions that on-chain forensic analysis can resolve on its own. They are questions of contractual liability, of due diligence and, ultimately, of arbitration.
What an RWA contract audits today (and what escapes it)
To see where the gap lies, it helps to look inside a typical RWA contract. Most serious projects in 2026 build on standards such as ERC-3643, also known as T-REX. The design is, in essence, a token connected to two further contracts: an Identity Registry and a Compliance Module. Before any transfer executes, the contract consults both: is the recipient verified? Does the operation comply with the issuer’s regulatory restrictions? Only then does the transfer complete.
It is a sound architecture for solving one very specific problem — preventing a security token from reaching unauthorised hands — and a security audit can verify with reasonable certainty that the permission logic works as expected. But consider everything that perimeter leaves out: the identity registry certifies who may hold the token, not whether the asset it represents still exists or retains its value. The compliance module verifies transfer rules, not whether the bond’s custodian has stopped paying, whether the property is unlawfully occupied, or whether the fund manager has diverted the funds.
That layer — the one connecting the legal fiction of the token to the physical or financial reality of the asset — normally rests on a third party whose solvency and good faith no Solidity audit can certify.
Precision of vocabulary matters here, because the sector too easily conflates three distinct things: code security (does the contract contain an exploitable vulnerability?), operational security (are the administrative keys protected by multisignature and timelock, or can a single person pause or drain the contract?) and the integrity of the legal-technical link (does what the offering document says the investor owns match what the smart contract actually entitles them to claim?).
An audit report covering only the first layer — which is, today, the market norm — can give investors, and potentially an arbitral tribunal lacking the technical context to distinguish between the three, a false sense of complete security.
The regulatory ground: moving, but fragmented
The regulatory response runs, as usual, a step behind the innovation, and the result is a mosaic that is difficult to navigate even for teams acting in good faith.
In the European Union it is worth beginning by dispelling a frequent confusion. Regulation (EU) 2023/1114, MiCA, is not pending entry into force: it has been fully applicable since 2024, and in Spain the transitional period for providers already operating ended on 1 July 2026. What remains open is not its application but its review, whose public consultation closed on 30 September 2026.
And there is a nuance that bears directly on RWA. MiCA regulates crypto-asset service providers — custody and administration included — and the issuance of certain categories of crypto-asset, but it excludes from its scope tokens which, by their configuration, are financial instruments: those fall under MiFID II and, where applicable, under the DLT market infrastructure pilot regime.
For a tokenised property or debt, determining on which side of that line the token falls is the first question to answer, and everything else depends on it: what authorisation is required, what custody obligations apply, and to whom the issuer answers.
Outside the Union the mosaic widens. In the Middle East, Dubai’s Virtual Assets Regulatory Authority and the DIFC have driven specific real-estate tokenisation initiatives including the on-chain representation of title. Singapore, for its part, has advanced through Project Guardian to the publication of operational guidance.
The problem is not an absence of frameworks but their fragmentation. A real-estate token lawful for an investor in Singapore may be inaccessible — or outright unlawful — for one in France, and the transfer restrictions coded into the contract do not always accurately reflect the law of each jurisdiction where each holder resides. Cross-border enforcement of token holders’ rights remains, in practice, almost entirely untested before the courts.
This is precisely the void that institutional arbitration is better placed to fill than traditional litigation: a neutral mechanism, chosen in advance by the parties, that does not depend on first deciding where the dispute is to be litigated.
A practical recommendation
The RWA industry is increasingly adopting standards that connect the token contract to an identity registry and a compliance module before every transfer. It is a necessary step, but an insufficient one if treated as one more technical box to tick.
The security audit of an RWA project ought to be integrated into the legal due diligence preceding issuance — not as an optional seal that reassures investors, but as one more element of the liability framework defined in the offering document. That means auditing not only the contract but the oracle architecture, the privileged administrative roles and whether they are protected by multisignature and timelocks, and above all setting down in writing what happens — and who answers — when the real asset and its on-chain representation cease to match.
In very concrete terms, this translates into arbitration clauses that can no longer be confined to the generic formula that “any dispute shall be resolved by arbitration”. They should specify at least three things: which technical reports — audits, oracle logs, on-chain governance traces — are admitted as evidence and under what standard of authenticity; what happens where the dispute involves both a code failure and a breach by the custodian of the underlying asset, that is, whether it is treated as a single dispute or as two parallel proceedings; and who bears the cost of technical expert evidence when neither party is, at the outset, able to read or verify what happened on-chain.
Without that specificity, arbitration risks inheriting precisely the same ambiguity that exists today on the technical side.
No audit substitutes for a liability framework
Until that integration — between technical audit, legal due diligence and well-drafted arbitration clauses — becomes the norm, every new RealT and every new oracle incident will keep posing the same uncomfortable question:
we tokenised the asset, but did we tokenise the liability?
Sources
coinpaprika.com (RealT analysis, September 2026); codezeros.com and getfailsafe.com (Moonwell incident, February 2026); public documentation on the ERC-3643 standard.
The views expressed in this article are the author’s own. BACS operates a Court of Arbitration specialised in digital assets and has a declared institutional interest in this field. This article is for informational purposes and does not constitute legal advice.
