ACT Vulnerability (Approved Controllable TransferFrom) is a security flaw in naive security token implementations where compliance checks applied to the transfer function can be bypassed through the transferFrom function by exploiting the separation between the token owner, the approved spender, and the transfer recipient. The vulnerability arises when a compliance wrapper verifies the destination address but fails to verify the source address or the spender's compliance status, allowing attackers to route regulated tokens through intermediaries that circumvent restriction enforcement.

This vulnerability is particularly dangerous in the context of Real-World Asset (RWA) tokenization because it can render an entire compliance framework ineffective. An issuer who believes their token enforces KYC/AML restrictions may discover that tokens have moved to non-compliant wallets through paths that their compliance logic never evaluated.

How the Attack Works

The ACT vulnerability exploits a fundamental design flaw in the "wrapper trap" approach where teams override ERC-20's transfer function to add compliance checks but apply incomplete verification to transferFrom.

In the standard ERC-20 model, transferFrom involves three parties: the token owner who granted an approval, the spender who calls the function, and the recipient who receives the tokens. A naive compliance wrapper might check that the recipient is whitelisted but fail to verify whether the owner is currently frozen or whether the spender has valid compliance credentials.

Consider a concrete scenario: Alice holds regulated security tokens and her wallet has been frozen by the issuer due to a pending regulatory investigation. Before the freeze, Alice had granted a token approval to a DeFi protocol contract. If the compliance wrapper only checks the destination of transferFrom calls, anyone who can trigger the DeFi protocol to execute a transferFrom on Alice's tokens can move them to a whitelisted address, completely bypassing the freeze. The compliance system checked the recipient and found them valid, but never evaluated Alice's frozen status.

The attack can be extended further. An attacker controlling multiple whitelisted addresses can daisy-chain transferFrom calls through approved DeFi protocols to move tokens through a series of "compliant" hops until they reach a destination that the issuer would never have approved directly. Each individual hop passes the recipient check, but the overall path violates the spirit and intent of the compliance framework.

The Root Cause

The root cause of the ACT vulnerability is treating compliance as a destination check rather than a holistic transaction validation. In traditional finance, compliance is evaluated against the entire transaction context: who is sending, who is receiving, what intermediaries are involved, and what the economic substance of the transaction is.

Naive blockchain implementations reduce this multi-dimensional check to a single boolean: "is the recipient whitelisted?" This creates the Check-Then-Act gap described in security token literature, where the "check" is incomplete and the "act" proceeds based on insufficient verification.

The vulnerability is amplified by ERC-20's approval mechanism because it introduces a third party (the spender) into what might otherwise be a simple sender-receiver relationship. If the compliance system doesn't account for all three parties and their respective compliance states, any one of them can become an exploitation vector.

Mitigation Through Compliance Hooks

The proper mitigation is implementing a compliance hook that verifies both the from and to addresses in every transfer operation, regardless of whether the transfer was initiated via transfer or transferFrom.

1function _beforeTokenTransfer(
2    address from,
3    address to,
4    uint256 amount
5) internal virtual override {
6    // Check BOTH sender and receiver
7    require(
8        identityRegistry.isVerified(to),
9        "Receiver not verified"
10    );
11    require(
12        identityRegistry.isVerified(from),
13        "Sender not verified"
14    );
15    require(
16        compliance.canTransfer(from, to, amount),
17        "Compliance violation"
18    );
19}

ERC-3643 addresses the ACT vulnerability architecturally by using _beforeTokenTransfer hooks that fire on every state change, ensuring that compliance checks are inescapable regardless of the transfer path. The hook receives the actual from address (the token owner), not msg.sender (who might be an approved spender), ensuring that frozen accounts, expired KYC, and revoked identities are always evaluated.

Audit Considerations

When auditing security token implementations, the ACT vulnerability should be a primary focus area. Auditors should verify that compliance checks execute on both sender and receiver for all transfer paths including transfer, transferFrom, and any custom transfer functions. They should also confirm that the from parameter in hooks represents the actual token owner, not the transaction initiator, and test that frozen or non-compliant accounts cannot have their tokens moved through any combination of approvals and intermediaries.

The vulnerability is a clear example of why professional smart contract audits are essential for regulated token platforms. A standard automated scanner is unlikely to flag incomplete compliance logic as a vulnerability because the code is syntactically correct, the flaw is in what the code does not check.