A token can only ever be held by an address the issuer has verified and permitted. Eligibility is not a database flag applied after settlement — it is a precondition the ledger enforces before a transfer clears.
Whitelisting starts by attaching a real, attested holder to an on-chain address before that address can ever hold value.
An address is admitted only after its controlling party clears identity verification against the issuer's onboarding policy. The link between the verified identity and the address is recorded, not just the address.
The ledger stores a claim that verification occurred and who attested it, not the underlying personal documents. Identity evidence remains in the residency jurisdiction; the chain carries only the eligibility fact.
Holders can be admitted at a specific tier — retail, accredited, qualified, or institutional — so a single instrument can distinguish who may hold it and in what capacity.
Whitelist status is a live attribute. If a holder's standing lapses or verification expires, the address can be suspended so it can no longer receive further transfers.
Whitelisting is enforced at the moment a transfer is validated, making non-compliant holding structurally impossible rather than merely detectable.
Before a transfer is admitted to the ledger, both counterparties are checked for current whitelist status. A transfer to an unpermitted address is rejected at validation, so it never settles.
Issuance and redemption follow the same gate as secondary transfers. New units can only be delivered to a whitelisted recipient, closing the path where tokens enter circulation outside the permitted set.
When whitelisting sits inside a delivery-versus-payment settlement, the eligibility check and the value exchange succeed or fail together. There is no window in which an unverified party briefly holds the asset.
The same address and policy state always produce the same admission decision. Enforcement is a rule the validator applies, not a discretionary review that can drift between operators.
The power to change the whitelist is scoped, separated, and recorded so the permitted set cannot be quietly rewritten.
The whitelist is administered under the issuer's or sovereign's own keys. No external operator can add or remove a holder without the key held by the party accountable for the instrument.
The roles that verify a holder, approve admission, and execute the on-chain update can be split across distinct keys, so no single actor both vouches for and admits a party.
Every whitelist change is authorized with ML-DSA-65 (FIPS 204) signatures, so the record of who was admitted and by whom remains verifiable against future cryptographic threats.
Each admission, suspension, and removal is written to the hash-chained ledger. The composition of the holder set at any past point can be reconstructed and proven, not reconstructed from memory.
The permitted set is maintained continuously, not captured once at issuance and left to decay.
Holders can carry an expiry on their verified status, forcing periodic re-attestation. A holder whose review lapses is frozen out of new inbound transfers until renewed.
A verified holder can be permitted on one instrument without being permitted on all. Whitelist membership is scoped per instrument, so eligibility for a bond does not imply eligibility for a fund token.
Redemptions, splits, and conversions respect the whitelist so restructured units land only with permitted holders. The event cannot be used as a route around eligibility.
Because status changes are hash-chained, an auditor can answer whether a given address was permitted on a given date and who authorized it — without trusting the current live state.