Skip to content

Real-World Asset Tokenization

Land, securities, and public assets are recorded in registries that the law recognizes as the source of title. Many are slow to update, hard for outside parties to verify, and separate from the systems that move money, so a property sale needs checks by several agencies and banks, and fractional ownership is costly to administer. Tokenization makes ownership divisible and lets transfer rules run as code, but a token issued outside the registry adds a second record of ownership that can drift away from the legal one.

Our model is registry-centric tokenization, a way into the tokenized economy that keeps the law in charge. The government registry remains the legal source of title, and the token is a programmable representation synchronized with it. Identity, compliance rules, evidence, and settlement come from the rest of the SIGN Stack.

A token is minted only on the registry’s authorization and refers to the registry entry it represents. Changes recorded in the registry, such as a transfer, a new encumbrance, or a court order, are reflected on the token, and a transfer that starts on-chain is submitted to the registry for recording. If the two records ever differ, the registry’s record prevails. Adapters connect the token ledger to land title, cadastral, tax, and municipal property systems, which the government continues to operate.

Each program chooses its token standard by asset and regulatory profile, from the Ethereum token standards known by their ERC numbers. ERC-3643 permissioned security tokens carry on-chain identity and transfer-compliance checks for regulated real estate and investment products. ERC-1400 partitioned tokens, an industry specification that was never finalized as an Ethereum standard, add tranches, lock-ups, and forced transfers under court or regulatory order. ERC-4626 vaults hold pooled assets and pay out rental or other yield. ERC-721 and ERC-1155 tokens represent unique and semi-fungible items such as art, collectibles, and certificates of authenticity, with off-chain media referenced by content hash. Depending on the jurisdiction’s preferred ledger, a program can run on a public chain or on a permissioned network compatible with the Ethereum Virtual Machine (EVM), which runs the same contracts as Ethereum.

Compliance, Evidence, and Settlement

Identity credentials establish who may hold an asset. Sign Protocol attestations and national digital identity credentials support know-your-customer and anti-money laundering checks and whitelist eligible parties for each asset class. Transfer rules in the token enforce cooling-off periods, investor accreditation, and jurisdictional restrictions, and reports to tax authorities, land registries, and financial regulators are generated from the same records.

Lifecycle events such as mint authorization, transfer restriction, redemption, and burn can be anchored to the DataHub, so registries, regulators, and courts can verify the ownership history independently and rely on it in disputes. For art, national museum collections, and other high-value goods, the same history is evidence of provenance and authenticity, and helps protect against forgery and illicit trade. Ownership records can be made public where the law allows.

Purchases, redemptions, and income payments settle in a regulated stablecoin on a public chain, in Sign CBDC, or in fiat currency where a program requires it. Rental income and other yield are paid through the same distribution service that pays government benefits (Benefit and Asset Distribution).

From Verified Facts to Contract Actions

A smart contract cannot see a land registry. Before it mints a property token or releases a payment, it needs to know facts that only institutions can confirm: who owns the property, whether it is encumbered, whether the buyer is eligible, and which tax applies. Our design keeps each decision with the institution that holds it and lets contracts act only on facts those institutions have signed.

A contract acts only on facts that institutions have signed A contract acts only on facts that institutions have signed
Figure 14: A contract acts only on facts that institutions have signed

Four roles divide the work (Figure 14). Institutions sign facts and keep the original documents. The DataHub preserves the signed facts, anchors their fingerprints, and releases permitted records with their proofs. An independent oracle network, triggered by a request on the ledger, fetches the evidence it is allowed to see, checks signatures, proofs, and freshness, and returns a signed report. The contract authenticates the report, checks the record’s proof against the anchored root, and only then acts within the rules it was approved for.

In owner-initiated issuance, the owner proves control of a wallet with an identity credential, and the registry signs a check of current ownership and restrictions, which the DataHub records and anchors. The owner then asks the minting contract to issue the token. The oracle verifies the evidence and its freshness, and the contract issues the property’s tokens to the owner’s wallet. A property can be tokenized only once, so a second request for the same property is rejected. The confirmed mint returns to the DataHub as a new signed record. If ownership does not match, the evidence has expired, or the proof fails, nothing is minted and the reason is recorded.

A sale settles the same way. When the buyer pays, the contract asks for evidence of the buyer’s eligibility, the asset’s status, and the approved payment instructions. One transaction then transfers the token to the buyer and places the payment, the agent’s commission, and the tax due in escrow. The transfer is submitted to the registry for recording. When the registry records it, the escrow pays the seller, the agent, and the tax authority; if the registry declines, the token transfer is reversed and the payment returns to the buyer, so the token never departs from the legal record. If any check fails, the whole settlement stops. If an outside fact changes, such as a new encumbrance at the registry, the token’s next action is held until the records are reconciled.

Accountability follows the layers. The responsible government authority sets policy and approves the workflows, each institution answers for the accuracy of its own facts, operators answer for the contracts and the oracle service, and validators confirm transactions without deciding ownership, tax, or whether an asset may be issued. The same pattern serves other programs: payment from escrow once an inspector certifies a construction milestone, gold or commodity tokens issued within an audited custody allocation, subscriptions to restricted investments by verified eligible investors, and the release of a funded benefit to a verified resident who has not yet claimed it.

For this pattern, our direction is to start on a permissioned EVM-compatible network where the anchoring, the oracle’s delivery point, and the asset contracts share one network, and later to publish approved proofs or state to public chains through a verified connection, once disclosure and trust rules for that connection are agreed.

A token has legal effect only where the law recognizes it, so a program starts with an assessment of the registry, cadastre, encumbrances, escrow, and identity integration, a legal review, and then a pilot under a regulatory sandbox or government sponsorship. The securities regulator decides whether a token is a security. Where it is, securities law governs its issuance and trading, trading runs only on licensed venues, and the token’s transfer rules block unlicensed ones. Switzerland’s DLT Act, the European Union’s DLT Pilot Regime, and the Monetary Authority of Singapore’s Project Guardian pilots inform the legal design.

Our direction runs from real estate pilots toward government securities, public infrastructure, natural resources, and sovereign wealth assets. Over time, tokenized assets are intended to serve as collateral and as settlement assets alongside CBDC. The design is also built to extend to cross-border recognition, where a foreign bank or investor verifies a registry-backed ownership record against the registry’s published keys, without a separate integration with each registry. Supervisors would follow issuance, transfer restrictions, and holdings directly on the ledger (Real-Time Supervision).