Smart contracts applied to real-world assets

When a physical-world asset becomes a token, someone has to write the rules that say who may hold that token, how it moves and what happens when there is a payment, a court-ordered freeze or an error. Those rules live in a smart contract, a program recorded on the network that runs by itself when certain conditions are met.

How these programs work in general is explained in what smart contracts are. The focus here is different: what changes when the program controls the representation of a property, a receivable or a debt security, and where it still depends on people, documents and the law.

Why a real-world asset needs a different contract

A network-native token, such as a cryptocurrency, exists only there. A real-world asset token is different: it represents something outside the network, such as a credit right, a fraction of a property or gold stored in a vault. For the basic concept, see what asset tokenization is.

That link to the outside world brings requirements an ordinary token does not have:

• Investor identification. Securities and many financial products may only go to identified people, sometimes only to qualified investors.
• Compliance with orders. A court decision may order someone’s position to be frozen or transferred.
• Asset events. Interest, amortization, rent and maturities need to be reflected in the token.
• Error correction. If the investor loses the access key, the right to the asset should not disappear.

That is why contracts used for real-world assets are usually permissioned: the code checks conditions before letting a token change hands.

What the code usually does

A public example helps show the typical functions. ERC-3643, a technical standard on the Ethereum network created in 2021 and with final status, describes a token for regulated markets. It is cited here as an illustration of what exists, not as a recommendation of a technology or issuer. According to the text of the standard:

• Identity registry. Each wallet is linked to a verified identity and a country. A transfer fails if the recipient is not verified.
• Compliance rules. A module checks limits set by the issuer, such as the maximum number of holders or of tokens per investor.
• Freezing. Authorized agents can freeze an entire wallet or only part of its tokens.
• Forced transfer. Agents can move tokens between wallets without the holder’s signature, as long as the destination is verified.
• Recovery. If the investor loses access to the wallet, the tokens can go to a new wallet, with that recovery recorded on the network.
• Pause. The whole token can be paused, which halts all transfers.

Notice what this means. With a token of this kind, you have the token in your wallet, but other people have power over it. That is not necessarily a flaw: it is what makes it possible to comply with a court order or return the asset to someone who lost their key. But it changes the question you should ask. Knowing that it is “on the blockchain” is not enough. You need to know who the agents are and what each one can do.

Payments and events: the part that looks most automatic

The most cited promise is automating payments: the contract would distribute interest or rent to holders on the right date. The Financial Stability Board (FSB), a body that brings together regulators from the major economies, describes this programmability as the ability to write code that “executes automatically” in response to predefined conditions or data.

The limit lies in where the money and the information come from. The contract only distributes what it has received. If the debtor of a receivable does not pay, or the tenant is late, no code can create that money. Automation organizes the pass-through; the credit risk stays the same. This point is developed in why tokenizing an asset does not eliminate risk.

In practice, many events depend on someone telling the network that something happened: the payment arrived, the holders’ meeting approved a renegotiation, the property was sold. Debt and equity models have different flows, as explained in equity tokens and debt tokens.

Oracles: how code learns about the outside world

A network like Ethereum does not access external data on its own. The ethereum.org documentation explains why: every computer on the network must reach the same result from the same data, and a query to an external website could return different answers to each of them.

The solution is the oracle, a service that writes data from outside onto the network, such as a price, an interest rate or confirmation of a payment. It solves one problem and creates another. The documentation itself lists the risks: the oracle may deliver wrong data, may be manipulated and, if it is a single source, becomes a single point of failure.

The FSB adds a regulatory point. The rules that apply to data providers in traditional markets may not fully cover oracles, and oracles can be targets of attacks that exploit code flaws. In a real-world asset, the oracle is often the issuing company itself or a provider it hires. Knowing who feeds the contract is as important as knowing what the contract does.

Upgrading the contract: fixing bugs or too much power

A contract published on the network cannot be edited directly. ethereum.org describes the most common pattern for getting around this: an intermediary contract, called a proxy, holds the data and points to another contract with the logic. To “upgrade”, the proxy is pointed to new logic.

This makes it possible to fix bugs but, as the documentation says, whoever controls the upgrade function can change the contract’s behavior, and users have to trust that this person will not make arbitrary changes. The mitigation measures cited are:

• Multisignature, which requires approval from several keys for a change.
• Timelock, a delay between approval and execution, which gives those who disagree time to exit.
• Access control restricted to authorized parties.

The FSB notes that security practices for these contracts are “still evolving” and that code errors can be hard to fix after deployment. A bug can freeze transfers, distribute wrong amounts or open the way to attacks.

Code and legal contract: which one prevails

In real-world assets, there is almost always a legal document behind the token: an issuance deed, a securitization agreement, an assignment contract, fund regulations. The code enforces some of those rules, not all of them.

In England and Wales, the Law Commission concluded in 2021 that existing law can deal with smart contracts “in much the same way” as traditional contracts. In Brazil there is no specific law on the subject. What applies is the rule for the asset: if the token is a security, the rules of the CVM (Comissão de Valores Mobiliários, Brazil’s securities regulator) apply; if it is a virtual asset outside that scope, the rules of the Banco Central (Brazil’s central bank) apply.

CVM Guidance Opinion 40, from 2022, recommends that offerings of tokens that are securities disclose, among other points, the protocol’s governance rules, the roles of network participants and whether the investor will control the private key. It also recommends supporting material on technology-related risks when the asset has complexities, such as compulsory liquidation imposed by the protocol. In the newsroom’s assessment, this information is precisely what shows what the smart contract does and who is in charge of it.

On the central bank side, BCB Resolution 520, in force since February 2, 2026, prohibits virtual asset custodians from using safekeeping mechanisms that create obstacles to the “immediate fulfillment of court orders” concerning the assets in their custody. In the newsroom’s assessment, functions such as freezing and forced transfer are one of the technical ways to meet this kind of requirement.

For the full regulatory picture, see tokenization and capital markets: regulatory limits. Official tests are still under way: in September 2026, CVM staff delivered to the Board the proposal for a pilot to test the issuance, bookkeeping, custody and settlement of securities on distributed ledger networks. It was a draft under internal review as of the date of the news item.

Questions to ask before investing

If an offering uses a smart contract to represent a real-world asset, the answers to these questions say more than the name of the network:

• Who can freeze, pause or transfer tokens without my signature? In what situations?
• Who can upgrade the contract? Is there a multisignature and a delay before a change takes effect?
• Who reports payments and events to the contract? What happens if that information is wrong?
• Has the code undergone an independent audit? Is the report public?
• If the code and the legal document diverge, which one prevails, according to the document itself?
• What happens to my right if the company that manages the contract shuts down?

Vague answers to these questions are, in themselves, relevant information. Remember that investments in real-world asset tokens may have low liquidity and may result in partial or total loss of the amount invested.

Key takeaways

• In real-world assets, the smart contract enforces rules on who may hold the token and how it moves. It does not create the asset’s value or pay in place of the debtor.
• Freezing, forced transfer and upgrade functions exist for legitimate reasons, but they give power to administrators. Knowing who they are is part of the analysis.
• The code depends on oracles and on legal documents. In Brazil, the applicable rules are those of the asset: the CVM for securities, the Banco Central for virtual assets.