Whitelist (Compliance Token Architecture)
A whitelist is the on-chain registry of investor wallet addresses authorised to hold or receive a regulated security token — the technical implementation of investor eligibility verification in compliant token architectures.
A whitelist in the context of tokenized securities is the curated set of blockchain wallet addresses that have been verified, approved, and granted permission to hold, receive, or transfer a specific regulated token. Only whitelisted addresses can be the recipient of a compliant security token transfer. Attempts to transfer tokens to non-whitelisted addresses are rejected by the smart contract before the transaction settles on-chain — making illegal transfers technically impossible rather than merely prohibited.
The whitelist is the on-chain expression of the issuer’s investor registry: the list of persons who have completed required KYC/AML verification, satisfied investor eligibility requirements (accredited investor status, qualified investor status, or equivalent), and agreed to the token’s terms and conditions.
How ERC-3643 Implements Whitelisting
In the ERC-3643 (T-REX Protocol) architecture, whitelisting is implemented through two interacting components:
Identity Registry: A smart contract maintaining the mapping between investor wallet addresses and their ONCHAINID contracts. Only addresses entered in the Identity Registry — by an authorised agent (typically the issuer or its designated transfer agent) — are eligible to receive tokens. The registry records each eligible address and links it to an on-chain identity that holds verified compliance claims.
ONCHAINID and Claims: Each eligible investor’s ONCHAINID must hold one or more active claims issued by trusted claim issuers. Claims attest to facts about the investor (e.g., “KYC completed,” “accredited investor as of [date],” “not a US person,” “eligible investor under Reg D”). The token contract verifies that the recipient’s ONCHAINID holds valid, unexpired claims from trusted issuers before permitting the transfer. Expired claims automatically invalidate eligibility — a continuous compliance mechanism.
Transfer Manager (Compliance Module): Even where both counterparties are whitelisted, additional compliance rules may block specific transfers — for example, during a holding period lock-up, if a jurisdictional restriction applies to the recipient’s country, or if the transfer would cause the token to exceed its maximum-holder count.
Jurisdictional Restrictions
Whitelist architectures enable jurisdictional blocking by encoding country of residence or nationality as a claim parameter. Transfer compliance rules can be configured to block transfers to investors in sanctioned jurisdictions, US persons (for Reg D issuances not open to US persons), or any other excluded class. When an investor’s country of residence changes (e.g., following regulatory reclassification of their jurisdiction), the claim can be updated or revoked, removing their eligibility without requiring manual intervention in each token contract.
Interaction with Transfer Agent Records
The on-chain whitelist must remain synchronised with the legal register of token holders maintained by the issuer’s transfer agent. Under US securities law, the transfer agent (a registered SEC function) maintains the official register of security holders. In tokenized securities systems, the transfer agent is the authorised agent responsible for maintaining the Identity Registry — approving and revoking whitelist entries based on KYC/AML status, investor eligibility, and regulatory requirements.
For EU issuers, the identity registry performs an analogous function to the shareholder register (registre des actionnaires) or bondholder list maintained by the issuer or its paying agent. Reconciliation between the on-chain registry and off-chain legal records is an operational requirement that must be addressed in the token’s governance documentation.
Privacy Considerations
Storing investor identity data on a public blockchain raises GDPR and data protection concerns. Two approaches resolve this:
- Off-chain personal data: The whitelist stores only wallet addresses and claims (yes/no attestations from trusted KYC providers), without personal data. Personal data is held off-chain by the claim issuer and the issuer’s KYC provider.
- Zero-knowledge proofs: Investors prove eligibility (e.g., “I am an accredited investor”) without revealing personal data. See Zero-Knowledge Proofs in Compliance.
Related entries: ERC-3643 (T-REX Protocol), KYC/AML in Tokenization, Zero-Knowledge Proofs in Compliance, Security Token
Primary source: ERC-3643 Association | ESMA on Identity in Token Systems