SKIP TO CONTENT
TOKENIZATION6 minBuilding the RWA Chain / Ep. 4 · Stage 4-3

ERC-3643 Agent Powers: Who Holds Them and How to Check

You can’t remove the agent powers and stay ERC-3643, but you can choose who holds them. Which choices should you check before you comment?

XIN
Pixel-art night scene: a brass key locked inside a glass vault on a rooftop, while from a taller tower next door a magenta crane arm lowers a hook toward the gold token coin sitting beside the vault.

IN 30 SECONDS

The ERC-3643 agent role is a set of addresses that can freeze, force-move or recover a position. The owner appoints them, and in a typical deployment an upgrade authority can rewrite the rules. Who holds each role is a deployment choice you can check on-chain.

KEY TAKEAWAYS · 3

  • In a typical deployment, above the wallet key sit the token agent, the registry agent, the owner and an upgrade authority.
  • Multisigs, timelocks, separate agents and a guarded upgrade authority change who decides. They’re my proposals, and none settles the legal question.
  • Map the controls on the deployed token and take the agent set-up to counsel before relying on key custody.
On this page

Who else can move a permissioned token?

IN SHORT More parties than the key holder can move the position, and they sit in layers.

WORDS TO KNOW

Upgrade authority
Whoever can point the token to new code, and so change its rules.
Multisig
A wallet that needs a set number of signatures before it acts.
Timelock
A built-in delay: queued actions are public before they run.
WHO CAN CHANGE THE POSITION
Layered stack diagram: 6 layers, top to bottomLayered stack diagram: 6 layers, top to bottom. Layer 1, UPGRADE AUTHORITY: Can change the token’s logic, and so the rules for every role below. Layer 2, OWNER: Appoints and removes agents; can name itself agent. Layer 3, TOKEN AGENT: Freeze, partial freeze, pause, Forced transfer, recovery, create and destroy tokens. Layer 4, REGISTRY AGENT: Adds and removes wallets; a listed wallet with valid claims counts as verified. Layer 5, ONCHAINID MANAGEMENT KEYS: Decide which new wallet a recovery may target, for the identity the agent names. Layer 6, WALLET KEY (CUSTODIAN): Signs ordinary transfers, subject to checks.UPGRADE AUTHORITYCan change the token’slogic, and so the rules forevery role belowOWNERAppoints and removes agents;can name itself agentTOKEN AGENTFreeze, partial freeze,pauseForced transfer, recovery,create and destroy tokensREGISTRY AGENTAdds and removes wallets; alisted wallet with validclaims counts as verifiedONCHAINID MANAGEMENT KEYSDecide which new wallet arecovery may target, for theidentity the agent namesWALLET KEY (CUSTODIAN)Signs ordinary transfers,subject to checks
Roles in a typical ERC-3643 deployment, top to bottom by reach. Based on the spec and the T-REX reference contracts.

IN PLAIN WORDS

Each layer is a key or a contract, controlled by someone, under some process. A custodian that only secures the bottom layer secures one path out of several.

Two combinations matter. An address that is agent on both the token and the identity registry can list a wallet. If that wallet’s identity holds valid claims, it can then force tokens into it.

WATCH OUT

The token agent alone gets close: in the reference factory setup, the token contract is itself a registry agent. And per the spec, burning (destroying tokens) bypasses all eligibility checks, so an agent can also reduce a balance to zero.

ADAM says: Picture a managed building: the manager’s master key opens your flat. But it can’t hand the flat to someone else. A token agent can move the balance to another verified wallet.

These powers can go to the issuer, a transfer agent, a fund administrator or the custodian. That’s a deployment choice, not a property of the standard.

Coming up next: So which choices change who decides?

Design choices that change how much the key decides

IN SHORT You can’t remove these functions and stay ERC-3643, but you can decide who holds them and how they’re used.

These options are my proposals, not part of the standard, and none of them settles the legal question.

Agent is one issuer or transfer-agent key
One key can freeze, force, recover and burn
Simplest. That key matters as much as the custodian’s.
Agent is a Multisig A wallet that needs a set number of signatures before it acts. See the glossary with defined signers
Agent actions need its threshold; signers visible on-chain
Slower. Who signs is a contract question.
Agent actions behind a Timelock A built-in delay: queued actions are public before they run. See the glossary
Queued actions are public before they run
A delay may not fit an order that must take effect at once.
Separate token agent and registry agent
No outside address can both list a wallet directly and force tokens into it
In the reference setup, recovery still runs on the token agent alone. Two-party recovery needs its own approval step.
Upgrade authority Whoever can point the token to new code, and so change its rules. See the glossary under its own multisig or timelock
Logic changes are slowed and visible
Every guarantee above depends on this one.

Request for comment no. 174 (91 FR 63924) is about DeFi receipt tokens, not tokenized securities. It asks if limits on recovering a deposited asset should be:

… enforced by the smart contract’s code and not subject to the discretion of any person or group of persons.

SEC proposal, request no. 174

Some DeFi deposits hand back a receipt token, so the holder can later recover the asset. Same engineering line: a rule in code versus a role with discretion. By design, the ERC-3643 agent role allows discretion; whether it’s used that way depends on who, or what, holds it.

Coming up next: So how do you see who holds these powers on a live token?

A control check to run before you comment

IN SHORT Before you write a comment letter or a custody memo, map the controls on the deployed token, not the docs.

STEP BY STEP

Flow diagram: 4 stepsFlow diagram: 4 steps. Read the basics, then List the agents. List the agents, then Same check on the registry. Same check on the registry, then Count past recoveries.1Read the basics2List the agents3Same check on theregistry4Count past recoveries

Step 1. Basics. Read the owner, the upgrade authority, the identity registry’s address, and whether the token is paused or the wallet frozen.

Pick a step to see it move
  1. Basics Read the owner, the upgrade authority, the identity registry’s address, and whether the token is paused or the wallet frozen.
  2. Agents The spec gives no list of agents. Rebuild it from past “agent added” events, confirm each is still one, and note what it is: a plain key, a multisig, a contract, or an EIP-7702 delegated key, which can still sign.
  3. Registry Run the same agent check on the identity registry: its agents decide who can receive.
  4. History Count past recovery events since the block you start from.
My checklist, illustrative: not part of the standard, not the SEC’s framework. Run it on the deployed token, not the docs.

ITEM GET

The key you custody may not decide

If one key holds agent, registry and upgrade rights, raise it with the issuer and counsel before relying on key custody. The checklist gives you questions, not a legal answer.

Comments are due by 7 December 2026, via the SEC’s internet comment form or rule-comments@sec.gov, with file number S7-2026-35 in the subject line.

Sources: Federal Register, 91 FR 63870, full text PDF, SEC press release 2026-100, ERC-3643, T-REX Token.sol.

STAGE CLEAR

What you now know

  • Which roles above the wallet key can move a position or rewrite its rules.
  • How to map the controls on a deployed token before you comment.

Check yourself

Tap or click a question to see the answer.

Illustrative case: an issuer puts every agent action behind a timelock but leaves the upgrade authority on a single key. Is the delay safe from being bypassed?

No. Whoever controls the upgrade authority can change the token’s logic, and so the agent rules. The timelock is only as strong as the controls on the upgrade authority.

You finished every stage published so far in this series. Back to the series map

Adam Boudjemaa
Adam Boudjemaa

Web3 x AI engineer, former CTO of Integra. Named author (1 of 5) of ERC-3643, first author of ERC-6960, co-author of ERC-7410, and co-author of ERC-8203, which is still a draft.

Have a project to ship or a role to fill?

Discuss your project or role

My work at the web3 x AI intersectionOpen-source tools I build

LinkedInTwitterGitHub
Follow the engineering notes

Get new articles on production AI and smart contracts by email.