How Real fits together

How Real's three layers coordinate around a shared financial record.

A shared financial record

In Real's design, the authoritative financial record lives on Real's own chain. Asset terms, identity checks, settlement events, risk assessments, and validation history can all point to the same asset. This lets different services work on the asset throughout its lifecycle. Connections to other networks give wider access, but Real keeps its own network policy and authoritative state.

Shared records make actions traceable. Contracts apply the rules that someone configured. The parties that submit outside information stay responsible for its accuracy.

Follow an asset

  1. Network — Real Chain executes transactions and records shared state.
  2. Asset — Tokenization Engine applies token, identity, and compliance rules.
  3. Accountability — Business Validators perform assigned services backed by stake and enforcement.

The three layers read the same records, but each has its own permissions. Power in one layer gives no power in another. The example below follows one bond through the layers. Business Validator (BV) assignments and insurance apply only where someone explicitly configures them.

Suppose an issuer represents a bond as a permissioned token. The bond's terms set the rights and obligations. Each Real system supplies a different part of the infrastructure that records and operates the asset.

1. Configure the asset token

The issuer sets up a token suite: a group of contracts covering the token, identity checks, and transfer rules. Authorized participants decide who can operate the suite and which eligibility requirements apply to investors.

2. Establish investor eligibility

The investor's wallet is linked to an identity. Trusted parties issue claims that confirm relevant facts, such as a completed identity check. Each suite decides which claims it requires and which claim issuers it accepts. See why reuse does not mean access.

3. Execute token operations

When a transaction reaches Real Chain, the network executes the relevant contracts. For an ordinary token transfer, the token and its connected contracts check the identity requirements, transfer restrictions, and token state. Balances change only after these checks pass.

A confirmed transaction proves what the contracts did. It does not prove that the real-world facts behind it are true, and it does not complete anything the issuer owes off-chain.

4. Carry out assigned business responsibilities

Some assets connect to the Business Validator Protocol. For these assets, assigned participants take on tokenization, scoring, or insurance duties. The protocol links those duties to stake, rewards, and enforcement. Which participants take part, and what coverage exists, depends on the asset's assignments and the integration in use.

An insurance role does not mean that every tokenized asset is insured. In the protocol design, stake backs the participant's accountability. Insurance payouts are a separate obligation, and the insurance participant funds them.

Keep authority separate

Participant or roleResponsibilityBoundary
Network validatorParticipate in chain consensusGets no issuer or token-management powers from this role
Issuer workspace AdminPerform authorized platform operationsWorkspace access alone gives no contract permissions
Contract owner or agentConfigure or operate contracts within assigned permissionsAuthority is specific to the contract and role
Claim issuerAttest to facts used in identity checksA suite must trust that issuer for the relevant claim
Business ValidatorCarry out assigned protocol responsibilitiesAdmission does not automatically grant token-agent authority

One organization may hold several roles. Each role still needs its own authorization and has its own responsibilities.

Choose the system you need