Who Really Controls an ERC-3643 Token's Agent Keys?
An ERC-3643 agent is an address holding seven privileged functions — forcedTransfer, freezePartialTokens, setAddressFrozen, recoveryAddress, pause, mint and burn — any of which can move or immobilise an investor's holding without that investor signing anything. The standard makes those powers mandatory and their governance optional: it uses the ERC-173 ownership model and imposes no multisig, timelock or quorum requirement, so an agent may be a single externally owned account. The entire Security Considerations section of EIP-3643 reads that the specification was audited by Kapersky and Hacken and no notable security considerations were found. Key custody is therefore outside the standard, and outside what any conformance claim covers.
TL;DR — Key Takeaways
- ✓The Powers: IERC3643 exposes forcedTransfer, freezePartialTokens, setAddressFrozen, recoveryAddress, pause, mint and burn — each able to move or freeze investor holdings without holder consent.
- ✓The Gap: ERC-3643 uses the ERC-173 ownership model and specifies no multisig, timelock or quorum. An agent role can be one EOA holding one private key.
- ✓The Spec's Own Words: The complete Security Considerations section: audited by Kapersky and Hacken, no notable security considerations found. Key risk is not addressed at all.
- ✓The 2026 Context: OWASP added SC10 Proxy and Upgradeability Vulnerabilities in February 2026, driven partly by Kinto Protocol's ~$1.55M July 2025 loss and a $10M+ uninitialized-proxy campaign.
- ✓Why Diligence Misses It: A stolen agent key produces valid, in-specification transactions on a still-conformant token. There is no invariant to violate and nothing for a monitor to flag.
The Features You Buy It For Are the Features an Attacker Wants
Institutions choose ERC-3643 over a plain ERC-20 for one reason: control. A regulated security has to be freezable when a court orders it, transferable when an estate is settled, and recoverable when an investor loses a wallet. ERC-3643 puts all of that on-chain, and that is a genuine advance over a token whose issuer can only ask holders nicely.
The same design decision creates the exposure. Seven functions in the IERC3643 interface — forcedTransfer, freezePartialTokens, setAddressFrozen, recoveryAddress, pause, mint and burn — can each move or immobilise a holding. An address with the agent role can call them. Whoever controls that address controls the register.
EIP-3643 reached Final status after being created on 9 July 2021, and the ERC3643 Association reports over $32 billion of real-world assets tokenized on the standard. What the specification never states is how the keys behind those powers should be held.
“This specification has been audited by Kapersky and Hacken, and no notable security considerations were found.”
— EIP-3643, Security Considerations section, in full
That is the complete section. It is an accurate statement about the contract logic and it is silent on the operational question that decides whether a token is safe. For the standards landscape around this one, see our guide to RWA token standards.
What Each Privileged Function Can Do to a Holder
Seven functions in the IERC3643 interface act on investor balances without the investor signing. Four of them — forcedTransfer, setAddressFrozen, freezePartialTokens and recoveryAddress — change who holds what or whether they can move it. The remaining three change supply or halt the token entirely.
| Function | Legitimate purpose | Effect if the key is not yours |
|---|---|---|
| forcedTransfer | Court order, estate settlement, corporate action | Moves any holding to any eligible address |
| setAddressFrozen | Sanctions hit, KYC lapse, suspected fraud | Immobilises a holder indefinitely |
| freezePartialTokens | Lock-up periods, pledged collateral | Locks part of a balance without freezing the address |
| recoveryAddress | Investor loses their private key | Reassigns a holding to an attacker-controlled wallet |
| pause | Incident response, regulatory suspension | Halts all transfers for every holder |
| mint | Primary issuance, subscriptions | Creates unbacked units against the same asset pool |
| burn | Redemptions, cancellations | Destroys a holder's position |
Read the third column as a description of a compromise. Every entry is the intended behaviour of the function, executed by an address the contract believes is authorised. The security model of a permissioned token is not the code; it is the answer to who is in that address.
The passive counterpart to a deliberate freeze — an expired identity claim locking a holder out without anyone calling a function — is a separate mechanism, examined in programmable compliance and Layer-0 governance.
The Standard Mandates the Powers and Leaves Their Governance Optional
ERC-3643 uses the ERC-173 contract ownership model, and no multisig, timelock, quorum or decentralisation requirement appears anywhere in the specification. A token can be fully conformant with every privileged role assigned to a single externally owned account whose key sits on one laptop.
This is not an oversight so much as a scope decision, and a defensible one: a token standard describes an interface, not an operating model. But it produces an asymmetry that diligence rarely prices. The compliance capabilities are guaranteed by the standard and verifiable on-chain. The controls over those capabilities are guaranteed by nothing and are invisible on-chain, because an EOA and a 4-of-7 multisig both appear simply as an address holding a role.
What conformance does and does not tell you
- Guaranteed by ERC-3643: transfers to unverified wallets revert; the agent can freeze, force-transfer and recover; the identity registry is consulted on every transfer.
- Not addressed by ERC-3643: how many people must approve a forced transfer; whether a freeze can be executed instantly or after a delay; where the agent key is stored; how a departing employee's access is revoked; what record justifies each privileged call.
- Consequence: two issuers can make identical conformance claims while one requires four executives and a hardware security module to freeze an investor and the other requires one stolen laptop.
The same distinction between an audited artefact and an unaudited operating decision runs through smart contract compliance for RWA issuance.
Why OWASP Added an Admin-Role Category in February 2026
OWASP added SC10 Proxy and Upgradeability Vulnerabilities to its Smart Contract Top 10 in February 2026 as an entirely new category, covering upgrade and admin roles, initialization, storage collisions, and governance and timelock design. It ranks tenth, immediately after SC09 Integer Overflow and Underflow.
The evidence behind the addition is the pattern, not a single incident. Kinto Protocol lost roughly $1.55 million in July 2025 through uninitialized ERC1967 proxies carrying a delayed-activation backdoor, and the wider 2025 uninitialized-proxy campaign cost over $10 million across protocols. In none of these was an arithmetic bug or a reentrancy the cause. The privileged surface was.
A permissioned security token has a larger privileged surface than the DeFi contracts that drove SC10 into the list, because compliance requires it. A freeze function is not an upgrade backdoor an auditor can recommend removing — the issuer needs it to satisfy a regulator. The mitigation cannot be to delete the power, so it has to be to govern the key.
“Proxy & Upgradeability Vulnerabilities” — new for 2026, covering upgrade and admin roles, initialization, storage collisions, and governance and timelocks.
— OWASP Smart Contract Top 10:2026, SC10
A comparable case where the audited code behaved correctly and the loss came from a configuration choice outside its scope is covered in the Kelp DAO bridge exploit and the limits of audit scope.
A Stolen Agent Key Produces No Anomaly to Detect
When an agent key is compromised, nothing breaks. Each forced transfer, freeze and recovery is a valid transaction that the contract was written to accept, on a token that still conforms to ERC-3643 in every respect. There is no failed invariant, no reverted call and no unusual gas pattern for a monitoring system to raise.
Compare that with a conventional exploit. A drained lending pool leaves a collateral ratio that no longer holds, a price feed far from its reference, or a balance that cannot be reconciled. Those are detectable states. An attacker calling forcedTransfer with the issuer's own key leaves a register that reconciles perfectly to a new, wrong owner.
The consequence for detection is that the only signal is intent, which the chain does not carry. The question “did the issuer mean to do this?” can only be answered against an off-chain record of authorised actions — a ticket, an approval, a court order reference. An issuer with no such record cannot distinguish its own administration from an attack after the fact, and neither can its auditor.
Detection surfaces, compared
- Logic exploit: leaves a broken invariant. Detectable on-chain, in near real time, by anyone.
- Oracle manipulation: leaves a price divergence from reference feeds. Detectable on-chain with an external comparison.
- Stolen agent key: leaves a valid state transition by an authorised address. Detectable only by comparing on-chain calls against an off-chain authorisation record.
This is why the control has to be preventive rather than detective, and why it belongs in custody design rather than in monitoring. See institutional RWA custody solutions for where issuer keys are meant to live.
The Key Policy Is the Security Model, So Write It Down
Because the standard is silent, every control here is an issuer decision that has to be made explicitly and evidenced in an operating procedure. The useful structure is to separate the powers by how urgent they genuinely are, since the argument against a timelock is always emergency response — and that argument only applies to one of the seven functions.
| Power | Genuine urgency | Control that fits |
|---|---|---|
| pause | Immediate — the point is to stop an incident | Low threshold, no delay, loud alerting, separate key from all others |
| setAddressFrozen | Hours — a sanctions match is urgent but not instant | Multisig, screening-hit reference recorded per call |
| forcedTransfer, recoveryAddress | Days — court orders and estates are never same-hour | Higher multisig threshold plus a timelock; document reference mandatory |
| mint, burn | Scheduled — tied to subscription and redemption windows | Multisig with a per-window cap reconciled against the fund register |
Two further points matter more than the thresholds. First, role revocation needs to be as rehearsed as role grant: a leaver whose signing key is still valid is the most common way a controlled setup decays into an uncontrolled one. Second, every privileged call should carry an off-chain justification recorded at the time, so that the intent question has an answer that predates any incident.
None of this is exotic. It is ordinary key management applied to a surface that most issuers do not classify as one, because the functions arrived described as compliance features rather than as administrative access.
For how ERC-3643 sits against newer permissioned designs, see the evolution of RWA token standards, and for the structural overview our institutional guide to RWA tokenization.
Frequently Asked Questions
Which ERC-3643 functions can move investor tokens without consent?
The IERC3643 interface exposes forcedTransfer, freezePartialTokens, setAddressFrozen, recoveryAddress, pause, mint and burn. Each is callable by an agent or the owner. forcedTransfer moves tokens between holders without the sender signing; setAddressFrozen and freezePartialTokens immobilise a balance; recoveryAddress reassigns a holding to a new wallet; pause halts the whole token. These are compliance features by design and require no holder approval.
Does ERC-3643 require a multisig or timelock on those roles?
No. ERC-3643 uses the ERC-173 ownership model, and no multisig, timelock, quorum or decentralisation requirement appears anywhere in the standard. An agent role can be a single externally owned account controlled by one private key. The standard defines what the privileged functions do; it leaves entirely to the issuer how the keys that call them are held, rotated and approved.
What does the ERC-3643 Security Considerations section actually say?
In full: “This specification has been audited by Kapersky and Hacken, and no notable security considerations were found.” That is the entire section. It records that the contract logic was audited and does not address agent or owner key risk, key custody, role separation, or what happens when a privileged key is compromised. A conformance claim therefore carries no information about key governance.
Why did OWASP add a proxy and upgradeability category in 2026?
OWASP added SC10 Proxy and Upgradeability Vulnerabilities to its Smart Contract Top 10 in February 2026, covering upgrade and admin roles, initialization, storage collisions, and governance and timelock design. The driving evidence included Kinto Protocol, which lost about $1.55 million in July 2025 through uninitialized ERC1967 proxies with a delayed-activation backdoor, part of a broader 2025 uninitialized-proxy campaign costing over $10 million.
Is a compromised agent key different from a normal token exploit?
Yes, in an important way for a regulated issuer. Nothing is broken and no bug is exploited: the contract performs exactly as specified. Every forced transfer, freeze or recovery executed by a stolen key is a valid, in-specification transaction on a token that continues to conform to ERC-3643. There is no invariant violation for a monitoring system to detect, which makes the event look like ordinary issuer administration.
What should diligence ask beyond “do you use ERC-3643?”
Who holds each agent key and in what custody; how many independent signatures a forced transfer or freeze requires; whether a timelock delays anything other than an emergency pause; how roles are revoked when staff leave; and what the recorded justification is for each privileged call. None of these are answered by the standard, so each has to be answered by the issuer's own key policy and evidenced in an operating procedure.
Related Articles
RWA Token Standards: A Complete Institutional Guide
The pillar covering ERC-3643 and its alternatives.
Smart Contract Compliance for RWA: The Layer-0 Guide
How on-chain compliance rules are designed and enforced.
Did the Kelp DAO Bridge Hack Break the Audit Model?
Another loss where nothing in the audited code was wrong.
Institutional RWA Custody Solutions and Compliance
Where issuer keys are actually meant to live.