02 · Core Concepts

The previous chapter explained Project RWA's purpose and integration levels. This chapter starts with one asset and one investor and explains the core objects used throughout the later processes.

2.1 Token: asset units

Each RWA asset has an independent ERC-3643 Token.

It supports common ERC-20 interfaces:

name / symbol / decimals
totalSupply / balanceOf
transfer / approve / transferFrom
Transfer / Approval

It also adds:

• investor eligibility checks;
• compliance-rule checks;
• pausing and freezing;
• Agent minting, burning, and forced transfers;
• lost-wallet recovery.

External applications can read the Token like an ERC-20, but a sufficient balance does not guarantee that a transfer can execute.

Amounts are stored as on-chain integers:

on-chain amount = display amount × 10^decimals

PRWA uses 6 decimals, so 1 PRWA = 1,000,000. Always call decimals() dynamically when integrating another asset.

2.2 Wallet: signing and holding assets

An investor wallet is an EOA address used to:

• sign on-chain transactions;
• pay gas;
• hold Tokens;
• control the investor's ONCHAINID.

The wallet address itself does not store a KYC conclusion. Holding eligibility is determined from the ONCHAINID associated with the wallet and the target asset's IdentityRegistry.

2.3 ONCHAINID: the investor's on-chain identity

ONCHAINID is a smart-contract address, not another regular wallet.

Item	Wallet	ONCHAINID
Type	EOA	Smart contract
Primary purpose	Sign, pay gas, hold Tokens	Manage identity keys and Claims
Stores plaintext KYC directly	No	It should not
Creation entry point	Wallet tool	ONCHAINID Gateway

Investors normally call ONCHAINID Gateway.deployIdentityForWallet(wallet) to create an identity. IdFactory.getIdentity(wallet) indicates whether a wallet already has an associated identity.

2.4 Claim: an institution-signed eligibility conclusion

A Claim means that a qualification institution confirms that an identity satisfies a condition.

Field	Meaning
topic	Qualification type, such as KYC approved
scheme	Signature scheme
issuer	ClaimIssuer contract
signature	Signature generated by the qualification institution
data	Signed qualification data
uri	Optional off-chain reference

A Claim is created in two steps:

1. The qualification institution reviews the investor off-chain and generates a signature;
2. The investor writes the signature and Claim fields to their own ONCHAINID.

The institution generates the signature, while the investor normally submits the on-chain addClaim transaction and pays the gas.

Do not put names, document numbers, addresses, identity images, or other plaintext materials in a Claim. The chain only needs the verifiable eligibility conclusion.

2.5 ClaimIssuer: qualification issuer

A ClaimIssuer represents a qualification institution recognized by an asset.

It is responsible for:

• performing KYC/AML or other reviews off-chain;
• generating Claim signatures with a controlled signing key;
• revoking eligibility when required;
• protecting the signing key.

A signature generated by an ordinary application is not automatically recognized. The target asset must register the ClaimIssuer in TrustedIssuersRegistry and authorize it for the target Topic.

2.6 IdentityRegistry: the eligibility entry point for an asset

After the Claim is written to the ONCHAINID, the investor must also be registered in the target asset's IdentityRegistry.

IdentityRegistry combines four kinds of information:

Distinguish these results:

• contains(wallet): whether the wallet has a registration record;
• isVerified(wallet): whether the wallet satisfies all current requirements of the asset.

Registration does not guarantee valid eligibility. External applications should use isVerified as the final decision.

2.7 Why eligibility is asset-specific

Different assets can require different qualifications:

Therefore:

• one ONCHAINID can be used by multiple assets;
• Claim reuse depends on whether the assets recognize the same Topic and ClaimIssuer;
• registerIdentity is executed on a specific asset's IdentityRegistry;
• participation in multiple independent assets normally requires separate registrations;
• find the correct registry through Token.identityRegistry() before querying eligibility.

Eligibility for Asset A does not imply eligibility for Asset B.

2.8 ModularCompliance: transaction rules

IdentityRegistry answers whether a wallet may hold the asset. ModularCompliance answers whether a transaction may occur.

Rule modules can express:

• country or region allowlists;
• per-address holding limits;
• total-supply limits;
• lockup periods;
• investor categories;
• transfer limits and other restrictions.

Use the target asset's on-chain configuration and public documentation. Do not infer rules from another asset.

2.9 Complete transfer checks

For a partial freeze:

available balance = balanceOf(wallet) - getFrozenTokens(wallet)

2.10 Suite: the contracts for one asset

An asset consists of more than its Token. A complete Suite normally includes:

Contract	Purpose
Token	Asset units and holder operations
IdentityRegistry	Determines whether a wallet is eligible to hold
IdentityRegistryStorage	Stores wallet, identity, and country-code mappings
ClaimTopicsRegistry	Stores required eligibility Topics
TrustedIssuersRegistry	Stores recognized ClaimIssuers
ModularCompliance	Combines transaction rules

External applications most often use Token and IdentityRegistry. The other contracts explain eligibility requirements and rules.

2.11 Proxy addresses

Project RWA business contracts use a proxy pattern:

Store the proxy addresses from the published address table. Do not use an implementation contract as the business address.

2.12 ERC-3643 conventions and terms

Item	Description
T-REX	ERC-3643 reference implementation system; the supporting contracts for one asset form a Suite
Topic	The protocol does not define 1 = KYC; each project must publish Topic name, value, and version
Country code	uint16, normally ISO 3166-1 numeric, such as China 156 and Singapore 702
IR / IRS	IdentityRegistry / IdentityRegistryStorage
CTR / TIR	ClaimTopicsRegistry / TrustedIssuersRegistry
MC	ModularCompliance
IA	Implementation Authority, the implementation-version entry point used by proxies

The chain stores eligibility conclusions, address mappings, asset balances, and rule parameters. It should not store plaintext KYC information such as names, document numbers, or photographs.

2.13 What to read next

The next chapter places these objects in the complete system and explains which contracts are shared by the platform, which belong to a specific asset, and what each role is responsible for:

Continue: 03 · System Architecture and Roles