RWA Token Security: ERC-3643 Controls, Custody and Holder Rights

Identity registry and compliance modules

RWA token security connects the controls on a token with the asset claim the issuer promises to honor. A contract review can establish how transfers and administrative actions work. It cannot establish custody or the holder's legal rights simply by inspecting a balance. Those claims need their own documents and reconciliation evidence.

The ERC-3643 standard defines permissioned token interfaces with identity checks, recovery and administrative controls. Its compatibility with ERC-20 does not make every transfer permissionless. For a reviewer, the useful starting point is a map of the contracts and authorities that determine whether a particular recipient may hold the token.

Separate investor eligibility from offering-specific rules. The ERC-3643 compliance overview treats identity and compliance modules as related but distinct parts of the design. An identity can satisfy the required claims while a transfer still violates a holding limit or another configured offering rule.

Identity registry

Connect a wallet to its identity record and determine which checks make that record acceptable.

Trusted issuer

Identify whose attestations count and who can add or remove that trust.

Required claim topics

List the credentials the token's eligibility rules require rather than assuming that any identity record is sufficient.

Compliance module

Document the offering rule it enforces and the state updates it expects when tokens move.

Test changes to the trust configuration. Remove an issuer, alter a required claim or update an identity record, then repeat transfer and recovery operations. The expected behavior must come from the specification, including when a previously eligible holder becomes ineligible. A successful onboarding test says little about these later transitions.

The audit input should include a role-to-organization map. An address labeled agent does not reveal who operates it, which approval process they follow or how the key is replaced. Keep those operational facts separate from the code's permission check, and make the report state which side of that boundary was reviewed.

Our reference scan found 14 direct role gates

We enumerated the function declarations in a pinned T-REX token implementation to show why modifier counts need interpretation. The scan found directly gated administrative methods and batch wrappers that reach those methods without repeating the modifier in their own signatures. Neither observation is a vulnerability verdict.

Method

Source

contracts/token/Token.sol in the TokenySolutions T-REX repository, at the commit recorded in the result.

Retrieved

September 5, 2026. GitHub marked this repository archived, so the sample is a versioned reference rather than a claim about the latest maintained release.

Population

45 directly declared named functions. Excluding 18 internal or read-only declarations left 27 public or external mutating declarations, including initialization and batch methods.

Automatic signal

Parse signatures and direct call sites after masking comments and strings. Count onlyAgent and onlyOwner separately.

Manual check

Read every batch wrapper that calls a directly gated function. Distinguish a missing local modifier from a missing effective check on a token-moving path.

Results

The manual pass confirmed that all 6 identified batch wrappers call role-gated methods in their loops. An empty batch can avoid entering a loop while moving no tokens. The finding is therefore a call-path distinction, not evidence that an unauthenticated caller can mint or force a transfer.

This reference also distinguishes an ordinary transfer from forcedTransfer. The forced path checks the recipient's identity and notifies the compliance contract after movement, but it does not use the same precheck as an ordinary transfer. That is a scope question about intended agent powers, not a reason to apply a generic transfer rule to every method.

Limits

• No live token was audited.
• Inherited methods, proxy authorization and the implementation of external identity or compliance contracts are outside this declaration population.
• A lexical call inventory does not establish control flow, storage safety or whether deployed role holders are appropriate. The manual wrapper inspection answers only the narrow modifier question.
• Methods can satisfy more than one observation row. Do not add the callback count to the role counts to infer a partition of the contract.

Reproduction files seo/research/rwa-control-survey.py and seo/research/rwa-control-survey-2026-09-05.json are kept in the repository and are not published as site downloads. The result includes the complete source and the evidence for each parsed function.

Transfer-agent and forced-transfer powers

An agent-controlled transfer is a deliberate capability in a permissioned token design. The review question is whether the capability matches the issuer's documented authority and whether an unauthorized path can reach it. A holder should also be able to learn that the capability exists before relying on unrestricted control of the token.

Our pinned implementation inventory shows why a single pause test is insufficient. Ordinary transfers and privileged recovery or transfer operations can follow different checks. Write the intended behavior for each operation under a global pause, an address freeze and a partial balance freeze. Do not infer those behaviors from a function's name.

Recovery deserves a separate approval procedure. Test a replacement wallet that belongs to a different identity, a wallet with an inappropriate key purpose and a recovery request after the investor's eligibility changes. Preserve the rejection reason as evidence. A correct call to an identity contract still depends on that contract's rules and trusted records.

For batch operations, check behavior across the complete sequence. A later failure should have the atomicity the interface promises, and a role check in a called method must remain effective after a refactor. The reference census provides a concrete regression target: verify the token-moving call paths instead of counting modifiers alone.

Ask the issuer to connect each privileged action with an operational record: the initiating authority, approval evidence and reason for intervention. The event log helps reconstruct what the contract did. It does not, by itself, establish that the intervention was justified under the offering documents.

Mint, burn and reserve attestation gaps

A mint check can establish that a recipient is eligible and that the configured token rules permit issuance. It does not establish that a custodian received an asset. The review must identify the separate evidence that authorizes new supply and the point at which that evidence becomes final enough for the issuer's stated process.

Map the full subscription sequence. An investor may submit money, an administrator may confirm settlement and a token contract may issue the corresponding balance. Failures between those steps need an explicit recovery path. Otherwise a retry can duplicate an issuance request, or a completed token issuance can outlive a reversed payment.

1. Identify the authoritative subscription record.
2. Bind each mint authorization to the intended token, recipient and amount. Include a unique request reference and define how repeated requests are handled.
3. Reconcile issued supply with the accounting records that support it. Record the valuation time and any unsettled subscriptions separately, so a timing difference is not silently treated as extra backing.
4. Follow a redemption through cancellation, token burn and external payment. Test which state remains if payment cannot complete after tokens have been committed to the redemption process.

Reserve evidence has its own scope. Record which assets were observed, who supplied the data and when it was measured. Then ask whether the evidence includes liabilities, encumbrances and the legal entity that owes the holder. A report about an asset balance cannot answer an unexamined question about competing claims on that asset.

For an on-chain reserve feed, examine the consumer's response to a missing update or a changed reporting unit. A correct reported figure can be misused by a minting contract that compares it with a differently scaled supply figure. Our oracle review guide separates source integrity from the consuming application's interpretation.

Burning tokens needs the same discipline. The burn event proves a change to token supply under the observed contract rules. It does not prove that a bank payment arrived or that an off-chain register was updated. Require the reconciliation artifact that joins those records, with unresolved requests visible until the process reaches its documented terminal state.

Upgrade and admin key surfaces

The address a holder sees may be a proxy whose behavior depends on another contract. The T-REX proxy documentation describes implementation selection through an implementation authority. A review of the token source alone therefore leaves the upgrade path unanswered.

The factory interface also distinguishes token agents, registry agents and compliance configuration. Include each authority in the deployment manifest. A token owner renouncing a particular role would not establish that every other route to changing behavior had been removed.

Token administration

Identify the methods that change token metadata or replace its registry and compliance dependencies.

Identity administration

Trace who changes investor records, claim requirements and the trusted issuer set.

Implementation authority

Record the selected implementations and every authorized path to replacing them.

Operational custody

Connect each controlling address to its signing process, recovery procedure and transaction verification practice.

Test the upgrade as a state transition. Existing balances, freezes and identity links must retain the meanings the migration promises. Include a holder whose position is partially frozen and an investor with a pending recovery. Those cases exercise persistent state that a fresh deployment test does not contain.

A multisignature policy is only useful if reviewers can establish what signers actually approve. Keep the proposed implementation address and its verified code alongside the transaction payload. If the change also replaces a compliance module, include that dependency in the same review record. An approved token revision can still behave differently when an unreviewed module controls transfer eligibility.

Use the audit report's scope and revision fields to check whether those components were examined. A report that lists a token contract but omits the authority contract should state that limitation plainly.

Off-chain custody and redemption dependencies

A token symbol does not tell a holder what they own. The relevant documents may establish a direct interest, a claim through an intermediary or an instrument that tracks another asset. Identify the legal issuer and the record that determines ownership before assessing whether the token implementation matches the promised product.

The US securities regulator's staff statement of January 28, 2026 distinguishes issuer-sponsored tokenization from third-party structures, including custodial and synthetic models. It explains that holder rights and third-party exposure can differ. This is a staff taxonomy with no legal force, not a classification of a particular token or a new rule.

1. Read the token's implemented rights and restrictions.
2. Identify how the holder register associates the wallet with the entitled person or entity.
3. Locate the issuer obligation and custody arrangement that support the claim, including the party responsible if the intermediary fails.
4. Verify the redemption route, eligibility conditions and treatment of requests that cannot be completed immediately.

Ondo's OUSG overview provides an operational example: it describes tokenized fund shares, onboarding conditions and limits on instant subscriptions and redemptions, with another request path beyond those limits. It also describes updating the fund's net asset value at the end of each business day. This example illustrates dependencies; it does not assert that OUSG uses ERC-3643.

Check the mismatch between transfer availability and asset settlement. A token may move while the underlying fund or payment system follows another timetable. The issuer's process must explain whose claim exists during that interval and which valuation applies. Read the actual offering documents with the appropriate legal reviewer rather than deriving those rights from a successful wallet transaction.

Investor-side checklist

Tokenized asset due diligence should produce an evidence packet, not a row of reassuring badges. Request the documents that connect the asset, issuer and token, then record any link that remains unverified. A missing document limits the conclusion even when the code is publicly readable.

Keep a dated copy of the packet. If the issuer changes its redemption provider or replaces a contract dependency, compare the new arrangement with the evidence previously reviewed. Record the unresolved difference and the person responsible for obtaining the replacement document before treating the old conclusion as current.

For a team commissioning an ERC-3643 audit, provide the same packet to the reviewer. It lets them test a forced transfer against an intended authority model and a mint against a defined issuance process. Without that context, the report may correctly describe the code while leaving the product's central promise unanswered.

Our crypto due diligence checklist covers the wider evidence process. Use the member directory and a published firm analysis to inspect relevant review work, then ask which identity, compliance and custody interfaces the proposed engagement includes. A general smart contract service description does not establish experience with your specific permissioned-token model.

A technically valid transfer proves only the transition the contract accepted. The final review should identify the evidence supporting the holder claim and the dependencies that remain outside the code audit.