# Token suites (/docs/tokenization/token-suites)



## What is a token suite? [#what-is-a-token-suite]

A token suite is the group of contracts behind a permissioned asset token. REAL's Tokenization Engine uses the T-REX implementation of ERC-3643 to connect token balances with identity checks and configurable transfer rules.

The token represents the asset according to its terms. The surrounding contracts determine which identities the suite recognizes, which attestations it accepts, and which additional rules apply to operations.

## The parts of a suite [#the-parts-of-a-suite]

| Component                 | Responsibility                                                         |
| ------------------------- | ---------------------------------------------------------------------- |
| Token                     | Records balances and handles transfers and authorized token operations |
| Identity Registry         | Associates wallets with identities and checks the required claims      |
| Identity Registry Storage | Stores wallet-to-identity associations and a country field             |
| Claim Topics Registry     | Defines which kinds of claim the suite requires                        |
| Trusted Issuers Registry  | Defines which claim issuers are accepted for each kind of claim        |
| Modular Compliance        | Applies additional configured rules to token operations                |

The storage contract's country field is part of the underlying suite structure. REAL's jurisdiction rules use trusted jurisdiction claims; the field alone does not determine geographic eligibility.

## How the parts work together [#how-the-parts-work-together]

For an ordinary transfer, the token checks its own operational conditions and consults the identity and compliance contracts. The recipient must satisfy the suite's identity requirements, and the proposed transfer must pass the applicable rules. A valid identity alone is not enough to approve every transfer.

For example, an investor may have the required identity claims but still be unable to receive an asset because the suite's geographic restrictions exclude their jurisdiction.

## Ownership and operation [#ownership-and-operation]

Contract owners and agents have different responsibilities. Ownership generally controls configuration and role assignment where supported by the contract. Agents perform the operations their roles allow, such as registering identities or minting, burning, and freezing tokens.

A role on one contract does not imply the same role on every contract in the suite. Access to an issuer workspace also does not, by itself, establish on-chain authority.

In the platform's deployment flow, the issuer wallet receives ownership of the token, identity registry, and modular compliance contracts and is assigned token and identity-registry agent roles. The platform retains authority over the required-topic and trusted-issuer registries. This is the platform's ownership model, rather than a universal requirement of ERC-3643.

Privileged operations have their own permission checks and can follow different rules from ordinary investor transfers. Asset operators should understand who holds those powers and what the asset's terms permit.

## What is shared across assets? [#what-is-shared-across-assets]

An investor can reuse an [ONCHAINID](/docs/resources/glossary#onchainid) identity across suites. Acceptance remains specific to each suite: its required claim topics and trusted issuers determine which claims count.

This allows shared identity infrastructure while preserving distinct asset rules. Two tokens can recognize the same investor identity and still reach different eligibility decisions.