ERC-3643 (T-REX) Security Audit Checklist

ERC-3643, also known as T-REX, turns a plain ERC-20 into a permissioned security token. Every transfer has to clear an identity check and a compliance check before it settles, and a small set of privileged roles can freeze, force, mint, burn, and recover tokens. That extra machinery is what makes these tokens usable for regulated real-world assets, and it is also where most of the risk lives.

This checklist walks the whole T-REX stack one contract at a time. Each item is something to confirm during a review, written so you can hand it to an auditor who is new to the standard. If you want a refresher on how the pieces fit together first, our ERC-3643 standard breakdown covers the architecture and interfaces in detail.

Treat this as a floor, not a ceiling. A real engagement still needs manual review, a threat model built around the issuer's specific compliance rules, and tests written against the actual deployment. The point of the list is to make sure nothing structural slips through, not to replace judgment.

How the system fits together

Here is the whole system in one picture. The token never decides anything on its own. It asks the Identity Registry whether an address is allowed to hold the asset, and it asks Modular Compliance whether a specific transfer is allowed. Everything else exists to answer those two questions.

Read it top to bottom. An investor holds the token, an Owner configures it, and an Agent runs day to day operations like freezes and forced transfers. On every transfer the token checks identity through the registry stack on the left and rules through the compliance stack on the right. If either side says no, the transfer reverts.

Before you start

Collect the full deployment, not just the token. A T-REX system is only as safe as its weakest linked contract. Work through the prep in order so you are reviewing code with the full picture in hand.

Full contract set gathered. You have the token, the Identity Registry, the Identity Registry Storage, the Trusted Issuers Registry, the Claim Topics Registry, the Modular Compliance contract, every compliance module, and the ONCHAINID identity contracts in scope.
Wiring diagram confirmed. You know which token points to which registry and compliance, and which storage is shared across tokens. Draw it out. Most configuration bugs hide in the links, not the code.
Roles mapped. You have a list of every Owner and Agent address, what each can do, and whether each sits behind a multisig or a single key.
Intended behavior documented. You have the issuer's answers for the judgment calls below, like whether burns work while paused, so you can flag deviations instead of guessing.

Token core

This is the compliance-aware ERC-20 at the center of the system. Almost every finding of consequence traces back to a check that one code path skips. The overview below shows the operations you will review and what each one has to do.

The transfer pipeline

Every ordinary transfer runs the same gauntlet of checks in order. The diagram below is the shape you are verifying, and the checklist items make sure each gate is really there on both transfer and transferFrom.

Both transfer paths gated. transfer and transferFrom each run the full set of checks: contract not paused, sender and receiver not frozen, enough free balance, receiver identity verified, and compliance approves. It is common to see one path carry a check the other forgot.
Free balance, not total balance. Transfers spend balanceOf minus frozen tokens. A holder should never be able to move tokens that are frozen.
Compliance state updates cannot be skipped. Every successful move calls the compliance hook (transferred) after the balance change, so modules that count holders or track volume stay in sync.
Allowance logic is standard. transferFrom decrements the spender allowance exactly like ERC-20, and the receiver identity check still applies even when a third party moves the tokens.
Failures are explicit. Reverts name the reason (identity not verified, compliance failure, frozen wallet) rather than failing silently or with a bare revert.

Mint and burn

Mint checks the receiver. New tokens only go to a verified identity, and minting calls the compliance created hook.
Burn keeps accounting clean. Burning calls the compliance destroyed hook, and if the target has frozen tokens, the frozen count is reduced correctly so it can never exceed the actual balance.
Only the right role can mint or burn. Supply changes are restricted to the intended Agent or Owner, never left open.
Batch mint and burn validate inputs. Array lengths match, and per-item checks are not dropped in the batch version.

Forced transfer

Receiver still verified. forcedTransfer overrides compliance rules, but the destination must remain a verified identity. This is the one guardrail the standard keeps even on the admin override.
Frozen tokens handled deliberately. A forced transfer can move frozen tokens by design, so confirm the frozen accounting on the source wallet is updated and does not leave a stale frozen count behind.
Restricted to Agents. Only the Agent role can force a transfer, and the batch version enforces matching array lengths.
State stays consistent. Holder counts and compliance counters update on this path too, since forced transfers bypass canTransfer but still change balances.

Freezing

The freeze feature has two shapes, a full address freeze and a partial token freeze, and both change what a holder can move. The lifecycle below is what the accounting has to keep straight.

Address freeze blocks both directions. A frozen wallet can neither send nor receive.
Partial freeze cannot overshoot. You cannot freeze more than a holder's balance, and unfreezing cannot push the frozen amount below zero.
Frozen accounting survives every path. Mint, burn, forced transfer, and recovery all keep the frozen token count accurate for the affected wallets.

Pause

Pause covers the intended operations. Transfers, mints, and forced transfers halt when paused, and resume cleanly on unpause.
Pause is role-restricted. Only an Agent or Owner can pause or unpause.
Edge behavior is intentional. Confirm with the issuer whether burns, freezes, or recovery should still work while paused, and check the code matches that answer.

Recovery

Recovery migrates a holder from a lost wallet to a new one without breaking their legal position. Everything tied to the old wallet has to follow.

Recovery moves everything. recoveryAddress transfers the balance, the frozen token count, and the identity link from the lost wallet to the new one.
New wallet is legitimate. The replacement wallet is tied to the same ONCHAINID and is verified, so recovery cannot be used to move tokens to an unauthorized address.
Old wallet is retired. After recovery, the lost wallet cannot receive or send tokens again.
Recovery is authorized. Only an Agent can trigger it, and the caller has to prove the lost wallet belongs to the claimed identity.

Token information and links

Metadata setters are guarded. setName, setSymbol, and setOnchainID are access-controlled and emit events.
Registry and compliance swaps are protected. setIdentityRegistry and setCompliance replace the entire trust basis of the token in one call. Confirm they sit behind a multisig or timelock and are logged.

Identity Registry

The Identity Registry answers one question for the token, is this address allowed to hold the asset. If its answer can be wrong, nothing downstream is trustworthy. The isVerified call below is that answer, and it quietly reaches across three other contracts to produce it.

Registration is restricted. Only an Agent can register, update, or delete an identity, and batch registration checks array lengths.
isVerified is strict. It confirms the identity holds a valid claim for every required topic, from an issuer trusted for that topic, and that the claim is not expired or revoked. Unregistered addresses return false.
Country data is consistent. Country codes follow the same convention the compliance modules expect, so jurisdiction rules read the right value.
Deleting a holder is handled. Confirm what happens when an identity that still holds tokens is removed. Usually those tokens become non-transferable, which may be intended, but it should be a decision and not a surprise.
Registry swaps are guarded. Changing the storage, claim topics, or trusted issuers registry rewrites the compliance basis and is protected accordingly.

Identity Registry Storage

Storage is often shared by several tokens or registries, which makes binding mistakes quietly dangerous. One storage contract can feed the verification of many tokens at once.

Binding is access-controlled. Only authorized owners can bind or unbind a registry, and only bound registries can write identity data.
Shared storage stays isolated. A change made through one token's registry does not corrupt the identity view another token relies on.
Removal is clean. Removing an identity from storage leaves no dangling reference that a registry could still read as valid.

Claims and on-chain identity

Claims are the signed statements (KYC passed, accredited, AML cleared) that back verification. Forged or reused claims are the classic way into a permissioned token. Every claim has to survive the checks below before it counts.

Signatures recover to trusted issuers. Claim validation recovers the signer and checks it against the actual trusted issuer address for that topic, with no shortcut that accepts any signer.
Topic scoping is enforced. A claim issued for one topic cannot be reinterpreted to satisfy another. A KYC claim should not pass as an accreditation claim.
Expiry and revocation respected. Expired claims and revoked claims are rejected during verification.
Claims are bound to their subject. A claim signed for one identity cannot be replayed on a different identity or a different chain. Look for nonces, timestamps, or a domain binding that ties the claim to its context.
Identity key management is sound. On the ONCHAINID contract, management keys and claim keys are separated as intended, and adding or removing keys is properly restricted.

Trusted Issuers Registry

This registry decides whose word counts. Whoever controls it controls the whole compliance boundary. The key property is scoping, each issuer is trusted only for the topics assigned to it.

Issuer changes are restricted. Adding, removing, or re-scoping an issuer is access-controlled.
Issuers are scoped to topics. An issuer is only trusted for the specific claim topics assigned to it, never for all topics by default.
Removal takes effect immediately. Dropping an issuer instantly invalidates any verification that leaned only on that issuer's claims.
The list is bounded. There is a sane limit on issuer count so verification does not loop over an ever-growing list and run out of gas.

Claim Topics Registry

The list of required topics is the definition of eligibility. Changes here silently loosen or tighten who can hold the token. Every topic on the list must be satisfied for a holder to pass.

Topic changes are restricted. Adding or removing a required topic is access-controlled.
Consequences are understood. Removing a topic weakens the gate, and adding one can lock out existing holders who lack the new claim. Confirm each change is intended and communicated.
The topic list is bounded. The number of required topics stays small enough that verification loops cannot become a denial of service.

Modular Compliance

Compliance is where the issuer's real rules live, holder caps, jurisdiction limits, lockups, transfer ceilings. Every module runs on the hot path, so a bug here can block legitimate trades or let bad ones through. The token asks a read-only question before a move and reports back after.

Token binding is exclusive and guarded. Binding and unbinding a token is access-controlled, and the reference implementation ties one token to one compliance contract. Confirm that holds.
canTransfer stays read-only. The eligibility check does not mutate state. State changes belong in the hooks that run after the transfer.
State hooks are caller-restricted. transferred, created, and destroyed can only be called by the bound token. If any address can call them, module counters can be desynced at will.
Module management is restricted. Adding or removing a module is access-controlled.
Each module's logic is correct. Max balance, holder count, country caps, lockups, and time-based limits do what they claim and cannot be gamed with dust amounts, self-transfers, or rounding.
Counters update on every path. Modules that track holders or balances stay accurate through mint, burn, forced transfer, and recovery, even when those paths skip canTransfer.
No unbounded loops. A module that iterates over holders or other modules cannot grow large enough to make transfers revert.
A bad module cannot brick the token. A single reverting or misbehaving module should not be able to permanently freeze all transfers, and any external calls a module makes are safe against reentrancy.

Roles and access control

T-REX gives its operators real power over other people's assets. The audit has to be clear-eyed about who holds that power and how it is contained. The map below is the typical split. Confirm the actual deployment matches it, and that each arrow sits behind a key you trust.

Owner and Agent are separated as intended. The split between ownership and day-to-day operator actions matches the issuer's design.
Agent management is owner-only. Only the Owner can add or remove Agents.
Ownership transfer is safe. Ownership moves through a two-step process or a multisig, so it cannot be handed to the wrong address in one transaction.
No unguarded privileged function. Every function that should be restricted actually is. Compare similar functions across the stack and flag any that is missing a modifier its siblings have.
Powerful actions are contained. Forced transfer, freeze, mint, burn, and recovery are all sensitive. Confirm they sit behind multisigs or timelocks, and document the trust assumptions plainly for token holders.

Upgradeability and proxies

T-REX is deployed behind proxies so issuers can evolve rules without redeploying. Proxies add their own well-known failure modes. Calls hit the proxy, run implementation logic by delegatecall, and read and write storage that lives in the proxy.

Initializers run once. Each upgradeable contract can only be initialized a single time, and it actually was initialized after deployment.
No logic stranded in a constructor. Setup that belongs in an initializer is not sitting in a constructor where the proxy will never run it.
Storage layout is preserved. Upgrades do not reorder or retype existing storage, and reserved gap variables protect against future collisions.
Implementations cannot be hijacked. The logic contract behind the proxy cannot be initialized or taken over directly.
Upgrade authority is contained. Whoever can upgrade sits behind a multisig or timelock, and Diamond deployments are checked for selector clashes.

Deployment and configuration

A perfectly written system can still be wired wrong. These checks catch the mistakes that only show up in the live setup. The order matters, since the token needs its registry and compliance to exist before it can point at them.

Deploy order is correct. Identity and compliance contracts are deployed and initialized before the token, and bindToken is called to finish the link.
Registries point the right way. The registry links to its storage, trusted issuers, and claim topics, and the token points to the intended registry and compliance.
No leftovers. No test issuer, placeholder topic, or debug address remains in any registry.
Launch state matches intent. The set of verified addresses and any starting balances line up with the intended cap table.

General smart contract hygiene

The usual fundamentals still apply, and a security token is a bad place to skip them. These are the baseline checks that sit under everything above.

External token calls are safe. Any interaction with other tokens handles missing return values and reverts correctly.
Events cover every state change. Freezes, forced transfers, registry updates, and role changes all emit events, since monitoring and off-chain compliance depend on them.
Casts are safe. Narrowing casts, such as country codes into uint16, cannot truncate or wrap into a valid-looking wrong value.
Batch operations are bounded. Large arrays in batch functions cannot be used to grief the contract with out-of-gas reverts.
Edge cases are covered by tests. Self-transfers, zero-amount transfers, and transfers to and from the same holder do not corrupt holder counts or module state.

Where to go from here

Use this list as the structural pass, then dig deeper where a given engagement calls for it. Our interactive Tokenization 101 is the natural companion, calling out the audit angle for each RWA standard, cataloging the incidents that have actually broken these systems, and running a short audit-readiness self-check that pushes on the same things this list does, starting with who holds the privileged functions. For the deeper reference, the RWA Development Handbook goes interface by interface through ERC-3643 and the identity, compliance, and jurisdiction layers these tokens sit on.