2.4 Key Components: Custody, Oracles, Smart Contracts
What custody, oracles, and smart contracts each do in an RWA, why custody splits between the asset and the token, and how the three form a dependency chain that the later risk chapter examines.
Real-world assets do not remove trust. They redistribute it. A tokenized fund spreads trust across a custodian, a fund administrator, a data provider, an issuer, a transfer agent, the developers who wrote the token contract, and the blockchain the token lives on. Three components carry most of that weight. Custody is the control layer, the part that protects the off-chain asset and, in many designs, the token as well. Oracles are the information layer, the part that brings off-chain facts onto the chain. Smart contracts are the execution layer, the part that enforces the rules. This section names what each one does, why an RWA needs it, what good implementation looks like, and where it starts to strain. The full failure analysis belongs to Chapter 5. The job here is to make the dependencies visible first.
Section 2.3 walked through the lifecycle: issuance, exchange, servicing, and redemption. Each of those phases leans on at least one of these three components. The lifecycle described what has to happen. This section describes the machinery that makes it happen.
Custody: The Control Layer
The word "custody" hides a trap, because it can mean four different things at once. It can mean safekeeping the off-chain asset. It can mean safekeeping the private keys that control the token. It can mean maintaining the legal register of who owns what. And it can mean controlling the privileged roles inside a smart contract. Collapse those meanings together and the analysis goes vague. Keep them apart and custody becomes the clearest of the three components.
The BIS Committee on Payments and Market Infrastructures (CPMI) defines custody risk as the risk of loss on assets held in custody because of a custodian's insolvency, negligence, fraud, poor administration, or inadequate recordkeeping 1. For a tokenized asset, that risk can apply to both the token and the underlying asset it represents 1. This is the split that matters. A gold token needs vaulted metal under custody. A tokenized Treasury fund needs securities custody. The token holder may also need wallet or qualified digital-asset custody for the token itself. These are separate jobs, often done by separate parties, and a holder can be exposed on one even when the other is sound.
The Financial Stability Board (FSB) makes the same point from the asset side. Custody and redemption of tokens issued on a distributed ledger may require third-party service providers, and reference assets such as gold may need physical custody 2. Holding a token in a wallet addresses token custody. It does nothing for custody of the underlying asset or the legal title behind it.
Two live products show the split cleanly. When BlackRock launched its tokenized fund BUIDL, it appointed BNY Mellon as custodian of the fund's assets and as administrator, while investors held the tokens through flexible custody options of their own 3. The underlying-asset custody and the token custody are two distinct arrangements. Paxos structures its gold token, PAXG, so that each token represents fractional ownership of London Good Delivery gold bars held by Paxos Trust on a segregated basis in LBMA-approved vaults 4. The metal sits in a vault under a named custodian. The token is a claim on that allocated metal, not a substitute for it.
Good custody, in practice, means a named and accountable party for each layer: who holds the asset, who can prove it still exists, who keeps the authoritative register, and who controls the keys to the token. Where custody is weak or unclear on any one of those layers, the token can be technically perfect and still leave the holder exposed. Section 5.2 returns to custody as a risk surface, including the harder question of legal title.
Oracles: The Information Layer
A blockchain cannot see outside itself. It does not know the price of gold, the net asset value of a fund, an interest rate, a sanctions listing, or whether a bond has paid a coupon. An oracle is the service that fills that gap. The FSB describes oracles as the mechanism that collects off-chain data and stores it on a distributed ledger platform so that smart contracts can use it 2. That is the cleanest one-line definition for the RWA context.
The common mistake is to picture an oracle as a crypto price feed and stop there. Institutional RWAs usually need more than exchange prices. The information an oracle supplies can include net asset values, asset prices, collateral values, reserve attestations, and asset-servicing data. The FSB notes that oracle-provided information can also include corporate activity or market events that trigger smart contract actions 2. A tokenized fund that pays a monthly distribution needs reliable fund data far more than it needs a live spot price.
DTCC's Smart NAV pilot is the useful example here, precisely because it is not a crypto-native price feed. The pilot explored extending DTCC's existing Mutual Fund Profile Service so that net asset value data could be disseminated to and consumed by a blockchain ecosystem 5. The point is the source of the data. A tokenized money market fund does not need a market guess at its value. It needs the same trusted NAV that the fund administrator already publishes, delivered on-chain in a form downstream applications can rely on. That is reference data, not speculation.
An oracle reports selected data into a system under a defined trust model. It does not prove that the off-chain world matches the on-chain record. The FSB warns that reliance on unregulated or non-compliant oracles can hinder accurate assessment of token prices and asset quality 2. Good implementation means a known, accountable data source, a clear update cadence, and data that matches the authoritative off-chain figure. Where the oracle is opaque, stale, or unaccountable, the contract acts on bad facts and does so automatically. Section 5.1 treats that failure mode in full.
Smart Contracts: The Execution Layer
A smart contract is protocol or code that self-executes when defined conditions are met 1. BIS/CPMI describes the platforms these contracts run on as ledgers that host applications able to execute "if this, then that" logic 1. For an RWA, that logic is where the lifecycle rules become operational. The FSB notes that smart contracts can handle the issuance and programmability of a token, as well as its use on the platform 2.
In practice, the contract layer of an institutional RWA performs a specific set of jobs:
- Mint new tokens against an accepted subscription.
- Burn tokens on redemption.
- Restrict transfers to pre-approved holders.
- Distribute yield or route distributions to holders.
- Whitelist or remove eligible wallets.
- Freeze or recover tokens where the legal structure requires it.
- Route redemption requests to the issuer or transfer agent.
- Coordinate delivery-versus-payment-style settlement where a payment leg exists.
Many regulated products encode these controls directly into the token. The ERC-3643 permissioned-token standard, for example, includes mechanisms to verify a holder's identity and eligibility before allowing a transfer 6. That is one common way to make compliance part of the token rather than a separate layer bolted on beside it. It is a useful illustration of permissioned token logic, not a universal requirement, and other designs reach the same controls by other means.
Here is the caveat that keeps smart contracts in their proper place. They enforce process rules, but they do not define legal ownership by themselves. The legal claim still comes from the issuer documents, the fund register, securities law, or property law. A contract can move a token and update a balance. Whether that movement is legally a transfer of ownership depends on the wrapper around it, not on the code. Smart contracts are powerful automation, not legal magic.
The contract design also varies with the product model. RWA.xyz's functional taxonomy separates tokens where users can invest, sell, and receive distributions through on-chain infrastructure from tokens that still rely on traditional financial rails for those steps 7. The first model pushes more logic into the contract. The second keeps more of it off-chain. Neither is inherently better, but they place the execution layer in different positions, which changes what the contract is responsible for.
The FSB adds the preview of risk. Smart contracts are integral to tokenization, but they can create vulnerabilities, because the precision of the code matters and coding errors may be hard to resolve once a contract is deployed 2. That is the bridge to Section 5.5, where the failure modes are examined directly.
The Dependency Chain
The three components are not independent. They form a chain, and a break in any link can break the whole claim. An RWA can have a flawless token contract and still fail if the custodian loses the asset. It can have high-quality custody and still fail operationally if the oracle feeds it stale or manipulated data. It can have good data and good custody and still fail if the transfer logic, redemption logic, or upgrade governance is defective. The token is only as trustworthy as the weakest of its supporting layers.
Most serious RWA designs respond to this by making the components permissioned, governed, and accountable rather than open and anonymous. They use whitelists, transfer restrictions, registered transfer agents, qualified custodians, named administrators, and controlled contract roles. This is not a weakness or a betrayal of the technology. Regulated assets need identity checks, reversibility procedures where the law requires them, compliance controls, and operators who can be held responsible when something goes wrong. The OECD's policy work on tokenization treats custodians, smart contract reliability, settlement finality, and legal certainty as open questions that institutional adoption still has to resolve, not as solved problems 8. Permissioning is how most live products manage that uncertainty today.
An Accountability Map
The simplest way to hold all three components in mind is to read each one as a question about control. Custody asks who controls the asset. Oracles ask who controls the facts. Smart contracts ask who controls execution.
| Component | Question it answers | Who is accountable |
|---|---|---|
| Custody | Who controls the asset, and the token? | Custodian of the underlying asset, administrator, register keeper, and key holder for the token |
| Oracle | Who controls the facts the contract acts on? | Data provider, fund administrator, or attestation source |
| Smart contract | Who controls execution of the rules? | Contract developers, the issuer, and holders of privileged contract roles |
Once a reader can ask those three questions of any tokenized product, the rest of the analysis gets easier. A token is not a single thing to trust or distrust. It is a set of named parties, each controlling one part of the structure, each able to fail in a different way. Chapter 5 takes each component in turn and examines exactly how those failures happen, starting with the oracle problem.
- RWAs do not remove trust. They redistribute it across custodians, data providers, issuers, administrators, smart contract developers, and the blockchain itself. Custody, oracles, and smart contracts carry most of that weight.
- Custody splits into separate jobs: safekeeping the off-chain asset, safekeeping the token's keys, maintaining the legal register, and controlling contract roles. BIS/CPMI confirms that custody risk for a tokenized asset can apply to both the token and the underlying asset.
- An oracle collects off-chain data and records it on-chain so smart contracts can act on it. Institutional RWAs often need trusted reference data such as a fund's published NAV, as in DTCC's Smart NAV pilot, not just market prices. An oracle reports selected data under a trust model. It does not prove off-chain reality.
- Smart contracts enforce process rules such as minting, burning, transfer restrictions, distributions, and redemption routing. They do not define legal ownership by themselves. The legal claim comes from the issuer documents, the register, and the law.
- The three components form a dependency chain, so failure in one can break the whole claim. Reading custody, oracles, and smart contracts as questions about who controls the asset, the facts, and execution sets up the risk analysis in Chapter 5.