Tokenized Real-World Assets: An Executive's Due Diligence Checklist

Tokenized real-world assets are real enough to deserve diligence and hyped enough to need it, and six questions do most of the sorting.

The six questions

Ask these of any platform before you move an asset onto it. First, where does final settlement happen, and what must you trust for it to be final? Second, who can freeze, censor, or reverse a transfer? Third, is there a federation, signer set, or bridge between you and the asset? Fourth, is it in production, and for what? Fifth, who holds custody, and who can move funds without the holder's signature? Sixth, what is the regulatory posture of the platform and of the issuer?

Ask for evidence, not assurances. For each answer, request a document, a code reference, an audit report or a live demonstration, and mark any answer that rests on the vendor's word alone. Vocabulary won't help you here. Terms like layer 2, sidechain, bridge, and wrapped asset describe very different trust arrangements and get used loosely. The checklist cuts through the labels by asking what can happen to a holder.

The questions apply to the architecture. They do not replace the diligence on the asset itself. A tokenized claim is only as good as the legal claim underneath it, and no platform changes that.

Here is how a filled row should look. The question is who can freeze or reverse a transfer. The answer names the party, for example, the issuer under a specific clause of the terms, and says plainly that the operator cannot. The evidence is a link to the terms and to the code path that enforces the rule. The owner is legal and security together. If the answer is nobody, ask what the compliance story is. If the answer is the operator, ask under what process.

Order matters too. Start with the questions that can end the conversation, which are usually the second and third. If you cannot accept who can freeze a transfer or what sits between you and the base ledger, the rest of the diligence is wasted effort. Decide in advance what a pass looks like, such as no unexplained party in the settlement path and an independent review of custody, so a charismatic demo cannot move the goalposts. Record the load each answer was tested at as well, because a platform can be sound at pilot scale and fragile at ten times the volume.

The landscape, with pros and cons

RGB keeps contract state with the participants and uses Bitcoin as an anchor, according to its consensus paper. The pro is privacy and scale, since validation sits with the parties. The cons are that the paper is a preprint and that participants must hold and check their own data. Freezing or censorship is hard to impose centrally, which is a feature or a problem depending on your regulator.

Taproot Assets keeps assets in Bitcoin UTXOs transferred in regular Bitcoin transactions, with proofs held off-chain and served by universes. The pro is that settlement is Bitcoin's. The cons are that custody depends on who holds which keys, and that the issuer defines the asset's rules, including supply. The FAQ says plainly that a pocket universe operator can make the relationship custodial, so ask who operates the universe.

Liquid is the most institutional option. It is a federated sidechain with 15 functionaries and an 11-of-15 quorum, one-minute blocks and confidential transactions, and the federation processes peg-outs. The pro is speed and privacy with named operators. The cons are that you trust the federation for the peg, and that a body signing every block is a party you should question about censorship and recovery.

Stacks and sBTC run on a separate chain, with the Bitcoin backing held by a signer set that needs a 70 percent threshold to move funds. The pro is a rich smart contract environment and a named, rotating set of institutional signers. The cons are the extra consensus layer and the threshold you must trust. Ask how a signer rotation or failure affects your holdings.

OroBit uses a deterministic engine that replays Bitcoin transactions. The pro is that the core path has no federation or bridge and no wrapped coin. The cons are what I'll dig into below.

OroBit through the same checklist

Settlement. Contract state is derived from Bitcoin transactions, and asset settlement on Lightning is gated on confirmations, with three as the default. That is a strong answer to the first question. Granted, determinism does not prove an issuer's honesty, an asset's backing, legal ownership, custody controls, application security, or audit completion, and the 144-block reorg journal is the model and not a proven production recovery.

Freeze or censor. The Lightning hub is operated by OroBit, and its asset-bound channels use a co-signed allocation. That makes the operator a party to ask about liveness and refusal to cooperate. The hub can ask the signer to sign but never signs for the user, and the keys stay client-side in the browser signer.

Federation or bridge. None in the core replay path by design. The hub is a separate piece and deserves its own diligence.

Production. Lightning payments live on Bitcoin mainnet, and SCL on Lightning is under active development. I do wonder about maturity as this aligns with the question I raised when I wrote about paying for the pilot: know whether you are buying a product or funding an experiment.

Custody. Users hold their own keys in the signer, according to the documentation, and the operator can request signatures but not forge them.

Taken together, the checklist gives OroBit strong answers on settlement and on the number of parties in the core path. That is a fair profile for a young platform, and I'm excited to see where it goes from here.

How I read the results

No design wins every bullet. It's always about tradeoffs and what they get you. A federation gives you named parties and recourse. A client-side design gives you privacy and puts the burden on holders. A replay design gives you a small trusted base and ties you to Bitcoin's speed. The right answer depends on whether your hard problem is regulation, privacy, throughput, or recoverability.

The pattern I trust most is the boring one. Count the parties between the holder and the base ledger, and for each party write down what it can do and what stops it. Platforms with fewer parties and clearer answers are easier to defend to a board and an auditor.

A few questions travel well to every vendor. Can you show me the unilateral exit, in writing, for a holder whose operator disappears? Who has run an independent node or independent review, and where is the report? What changed in the last twelve months that could change a past result? Which claims on your website are measured, and which are intended? A vendor who answers these quickly and specifically is usually one you can work with.

Disclosure: I'm an investor in OroBit.