Tokenized Real Estate Custody: Models and Proof of Reserves
Self-custody vs qualified custody, omnibus vs segregated accounts, proof of reserves and attestations, and how custody fits the full lifecycle of a token trade.
In tokenized real estate, who holds the keys is a regulatory question as much as a security one. Institutional investors expect qualified custody, clear segregation of client assets and evidence that the assets are really there. This guide covers the custody models, how proof of reserves and attestations work, and how custody fits into the full lifecycle of a trade.
Self-custody vs qualified custody
Who holds the keys isn’t just a security question—it’s a regulatory one.
Tokenized real estate can be held in different ways: users control their own wallets, or a licensed custodian holds on their behalf. The choice affects regulation, insurance, and who bears risk. Here’s how to think about self-custody vs qualified custody, omnibus vs segregated accounts, and how to match the model to the asset and the investor.
Self-custody
Self-custody means the user controls the keys—their wallet, their responsibility. Pros: full control, transparency, no custodian run risk. Cons: key loss is on them; many regulators and institutions don’t accept self-custody for certain assets or investor types. For retail or crypto-native users and some products, self-custody is a fit. For institutional or regulated real estate tokens, it’s often not enough on its own.
Qualified custody
Qualified custody means a licensed custodian holds the assets. Regulatory expectations (safeguarding, segregation, insurance) apply. Investors get protection; issuers and platforms get a model that satisfies auditors and regulators. The custodian may be the platform itself or a third party; either way, the custody layer needs to support the right account types, attestations, and proof of reserves so that “qualified” is demonstrable.
Omnibus vs segregated
Omnibus = pool many clients’ assets in one or a few accounts; the custodian tracks who owns what internally. Segregated = each client (or each mandate) has a distinct account. Regulation and client preference often dictate which is required or preferred. Tokenized real estate and institutional money tend to push toward segregated or at least clearly allocated omnibus with strong record-keeping. The platform should support both so you can serve different client types and jurisdictions.
Security layer
Regardless of model, custody needs a security layer: multi-signature where appropriate, HSM-backed key storage, proof of reserves, and insurance or bonding. Attestations—third-party or internal verification of balances and controls—build trust. When custody is API-driven, attestations can be produced from the same data that runs the platform, so “proof of reserves” isn’t a one-off report but a repeatable, auditable output.
Matching model to investor and asset
Retail, accredited, institutional; real estate vs liquid tokens—each combination may point to a different custody model. One platform can support multiple models: self-custody for some products, qualified for others; omnibus for some clients, segregated for others. The goal is to let issuers and investors choose the right level of control and protection without rebuilding infrastructure for each choice.
Proof of reserves and attestations
Trust, but verify—especially when you hold someone else’s assets.
Custodians hold tokens on behalf of clients. The question is: can you prove that you actually hold what you say you hold? Proof of reserves and attestations are how you answer that. They’re becoming table stakes for regulators and institutional allocators. Here’s why they matter and how to build them into a custody platform.
Why proof of reserves matters
Run risk—the fear that a custodian can’t return assets—is real. Transparency is the antidote: show that liabilities (what you owe clients) are covered by assets (what you hold). That’s different from “we have insurance.” Insurance pays after a loss; proof of reserves is about showing that the loss shouldn’t happen in the first place because the assets are there. Regulators and institutional due diligence are increasingly asking for both.
What attestations are
Attestations are formal statements that balances and controls are correct. They can be internal (ops or risk sign-off) or third-party (auditor or specialist). They run on a regular cadence (e.g. monthly) and have a defined scope: which accounts, which assets, which controls. Attestations turn “we hold X” into “we attest that we hold X, and here’s the evidence.” When that’s part of the custody API, you can automate the inputs and produce consistent, auditable reports.
Technical building blocks
Under the hood you need balance snapshots (point-in-time holdings per account and asset), Merkle trees or similar structures for verifiable aggregation, and optionally public verification so that anyone can check that the numbers add up. The custody domain should expose attestation APIs: create an attestation run, attach balances and metadata, and output a report or proof that auditors and clients can use. That makes proof of reserves a product feature, not a one-off project.
What good looks like
Good means frequency (e.g. monthly or better), scope (all client assets in scope, or a clear subset), and a decision on public vs private reporting—some institutions want public proof; others need private reports for compliance. Institutions use this in due diligence: they want to see that the platform takes custody seriously and can prove it. A custody API that supports attestations and proof of reserves is what turns “we’re a custodian” into “we’re a provable custodian.”
Integration with platform
Attestations shouldn’t live in a spreadsheet. They should be first-class in the platform: same data that drives custody drives the attestation. That feeds into compliance (evidence for regulators) and reporting (dashboards, investor letters). When attestations are built in, proof of reserves becomes a repeatable, scalable practice instead of a manual exercise.
From trade to custody: the full lifecycle
One trade touches six systems—here’s how they fit together.
A single tokenized real estate trade doesn’t live in one system. It flows through the exchange, settlement, custody, transfer agent, and sometimes treasury and fiat rails. When those systems are designed to work together, you get a clear, auditable lifecycle. When they’re not, you get reconciliation hell. Here’s the full path and why one platform makes the difference.
Map the lifecycle
- Order — Participant submits an order (or RFQ/OTC/auction response).
- Match — Exchange (or marketplace) produces a trade.
- Trade — Trade is recorded with price, size, counterparties.
- Settlement — Tokens and cash move; DvP, netting, failure handling.
- Custody / registry update — Custody balances and transfer agent (cap table) are updated.
- Withdrawal (optional) — Client withdraws to external wallet or bank.
Every step should be traceable: same trade ID, same identity, same org. That’s the lifecycle in one sentence.
Exchange
The exchange (or marketplace) is where the trade is created. Orders, RFQs, or auction fills become trades with a clear status. Trades are the contract: “A sells X to B at price P.” Everything downstream consumes that trade.
Settlement
Settlement takes the trade and moves assets. It runs netting where applicable, enforces DvP, and handles failures and retries. It updates custody and registry so that ownership changes are atomic with the trade. Without settlement, you have a trade on paper but no movement of tokens or cash.
Custody
Custody holds the tokens. Settlement credits and debits custody accounts; custody exposes balances, deposits, withdrawals, and attestations. For tokenized real estate, custody might be qualified (licensed custodian) or self-custody; either way, it’s the system of record for “where are the tokens.”
Transfer agent / registry
The transfer agent is the registry of record—who owns what, with restrictions (Rule 144, lock-ups) and corporate actions (dividends, splits). Settlement and custody must stay in sync with the registry so that legal ownership and holding location never diverge. When they’re on the same platform, that sync is built in.
Why one platform
Single identity: one set of credentials, one org, one audit trail. Consistent compliance: KYC and transfer restrictions enforced at every gate. No reconciliation gaps: exchange, settlement, custody, and registry speak the same language. That’s why “one platform” isn’t marketing—it’s the condition for a clean, institutional-grade lifecycle from trade to custody to withdrawal.
Custody decisions to make early
- Match the custody model to the investor base: self-custody for sophisticated holders, qualified custody for institutions and most retail offerings.
- Decide between omnibus and segregated accounts, and document how ownership is tracked inside omnibus pools.
- Set an attestation schedule and decide what you will publish, and how often.
- Make sure custody, settlement and the registry reconcile to the same positions every day.
Further reading: VARA inspection readiness · Supervisors want evidence, not policies