In traditional crypto security reviews, seeing that an admin can move user funds is usually an immediate centralization red flag. In RWA systems, however, that conclusion does not always hold.
ERC-7943 explicitly defines capabilities such as forcedTransfer(), setFrozenTokens(), canSend(), canReceive(), and canTransfer(). Freezing, forced transfer, and asset recovery are not necessarily hidden backdoors added by an implementation team; they may be explicit requirements of a regulated-token specification.
This is a class of RWA risk that ScaleBit believes deserves a different audit model. When an “exception” is part of the specification itself, the security question is no longer whether the exception exists. The real question is:
If a privileged path is intentionally allowed to bypass certain rules, which invariants may legitimately diverge—and which invariants must remain non-bypassable?
1. Forced Transfer Creates a Second Legitimate State Machine
A conventional token transfer roughly follows one semantic path:
Holder Authorization → Transfer Conditions → Balance / Ownership Transition
An RWA token may expose another equally legitimate path:
Privileged Authority → Enforcement Conditions → Balance / Ownership Transition
Both modify the same asset state, but they do not necessarily share the same preconditions.
Under some ERC-7943 permission models, for example, forcedTransfer() may legitimately bypass the normal canTransfer() path. But permission to bypass one transfer restriction does not imply that every other safety property may disappear with it.
A more useful review model is therefore to separate invariants into two categories:
An onlyRole(AGENT) check tells us who may enter the privileged path.
It does not tell us:
Which security properties must still hold after that privileged state transition completes?
Privileged-path security is therefore not about eliminating semantic differences between normal and enforcement flows. It is about ensuring that:
Semantic divergence is strictly limited to what the specification actually requires.
2. When frozen > balance Is Not an Accounting Bug
ERC-7943 contains a particularly counterintuitive state requirement: the frozen amount may exceed the account’s current balance.
A Solidity auditor may instinctively assume an invariant such as:
frozen(account) ≤ balanceOf(account)
For a regulated token, however, that assumption may be incorrect.
Suppose an address currently holds 10 tokens, but an enforcement authority intends to restrict not only the current balance, but also future assets received by that address.
If the system only allows:
frozen = 10
and the account later receives another 90 tokens:
balance = 100
frozen = 10
those additional 90 tokens may become transferable.
A valid enforcement state may therefore instead be:
balance = 10
frozen = 100
Here, frozen no longer means merely:
the portion of the current balance that is frozen.
It behaves more like:
a policy constraint over both current and future asset state.
That distinction changes implementation-level security assumptions immediately.
For example:
may underflow or revert whenever frozen > balance.
If permission-query functions are also expected to remain non-reverting under valid states, the implementation must explicitly handle this case, for example:
This illustrates an important RWA audit principle:
Do not infer invariants from variable names. Derive them from the state semantics defined by the specification.
The same rule applies to forced-transfer ordering.
If an ERC-721 or ERC-1155 enforcement path updates frozen accounting and also triggers a recipient callback, the relevant state should be reconciled before the external interaction. Otherwise, reentrancy may observe an intermediate state such as:
Ownership = New State
Frozen Accounting = Old State
The failure here is not excessive administrative power.
It is a violation of state consistency.
Authorization semantics may diverge. State-observation semantics still need to remain coherent.
Or more simply:
Bypass permission does not imply bypass ordering constraints.
3. Revocability Propagates Through the Composability Graph
Forced transfer is not only a property of the token contract itself. It also changes the assumptions made by every downstream protocol that integrates the asset.
Traditional DeFi frequently relies on an implicit assumption:
Assets held by a protocol can only leave through that protocol’s own state machine.
For a revocable RWA, this assumption no longer necessarily holds.
Consider a vault holding $10 million of an RWA token. If the issuer or enforcement authority can alter the vault’s token balance outside the vault’s own logic, then even a perfectly implemented vault may experience:
For a bridge, the implication may be even more fundamental.
Suppose its backing invariant is:
Wrapped Supply ≤ Assets Locked in Custody
If locked assets can leave custody through a privileged token-level path that the bridge does not control, then the bridge’s backing invariant now depends on issuer authority.
This leads to a broader security property:
Revocability is a composability property.
When a protocol integrates a revocable asset, it inherits part of the issuer’s privileged state machine.
That does not mean revocable RWAs are unsuitable for DeFi. It means integration reviews must ask additional questions:
Who can change protocol-held balances externally?
Does internal accounting observe those changes immediately?
Does the protocol assume custody = exclusive control?
Which solvency or backing invariants depend on that assumption?
From ScaleBit’s perspective, this is particularly important because the vulnerability may not exist in either contract independently. It may emerge from a composability assumption mismatch between the RWA token and the downstream protocol.
4. Move From Privileged Roles to a Privileged Transition Matrix
The previous analysis can be translated directly into a more practical review framework.
Instead of stopping at who holds AGENT_ROLE, whether that role is protected by a multisig, or whether the administrator is properly restricted, security reviews should compare the normal and enforcement paths explicitly.
A Privileged Transition Matrix can make those differences visible:
The real objective is to distinguish:
Intentional Enforcement Semantics
from:
Accidental Security Bypass
Implementation note: not every privileged action needs the same delay model
Changes that modify the rules themselves—adding enforcement authorities, upgrading compliance modules, or expanding the scope of forced transfer—generally benefit from high-friction controls such as multisigs and timelocks.
Executing an already-defined emergency freeze may require faster action, because excessive delay can itself create an escape window.
A useful principle is:
Changing authority should be slow; exercising existing authority can be fast only when the execution scope is tightly bounded.
Faster execution should therefore come with narrower limits around recipient, amount, asset, operator, and auditability.
Conclusion
When the exception becomes the specification, the exception needs its own security semantics.
One of the fundamental differences between RWA systems and traditional DeFi is that behaviors considered exceptional in permissionless tokens may be explicit protocol requirements in regulated assets.
forcedTransfer() is not necessarily a backdoor.
frozen > balance is not necessarily an accounting bug.
Bypassing holder authorization is not necessarily an authorization vulnerability.
The real failure occurs when:
A privileged path bypasses an invariant that the specification never intended it to bypass.
This is why ScaleBit believes RWA privilege reviews should not stop at:
Who has privilege?
They should continue with:
What semantics does that privilege create?
Which invariants may diverge?
Which invariants must survive?
Which downstream protocols
silently assume they survive?
Once an exception path becomes part of the protocol specification, it can no longer be treated as a special admin function and reviewed in isolation.
It is a second asset state machine—and it should be audited as one.
For RWA security, the goal is not to eliminate privilege at all costs. It is to ensure that every privileged action has a clear, bounded, and verifiable semantic boundary.