Our token custody assessment system classifies token functionality into behaviors that directly affect the safety and predictability of custody. Each behavior represents a purposeful capability of the token contract. Some are well-intentioned design choices, but all must be documented to avoid surprises and manage risks in custodial workflows.
While TestMachine believes these behaviors represent a substantial portion of the risks that asset holders are concerned about, we are always willing to add additional behaviors that are important to our customers.
Critical (12)
Major custody risks
Medium (2)
Operational disruption
Low (2)
Supply/value impact
Info (3)
Contextual awareness
An ERC-20 token has blacklist functionality if an administrator of the token (any privileged account) can execute transactions that block specific, targeted accounts from transferring balance (through transfer or transferFrom) on the token in question.
Required Contract Specification(s):
An ERC-20 token has confiscation functionality if an administrator of the token (any privileged account) can execute transactions that reduce the balance of specific, targeted accounts.
Required Contract Specification(s):
A contract makes an external call when it interacts with another account on the network. Our system watches these external calls and builds the network module, or call graph, that the contract is a member of. This data can be used in many ways, and knowing which contracts a target is interacting with is a crucial aspect of a contract's behavior profile, as external contracts can augment the behavior of the target contract.
Required Contract Specification(s):
A token has insufficient decimals when the decimals() method of the ERC-20 spec returns an insufficient value. What values are insufficient is configurable and changes based on the contract and the context.
Required Contract Specification(s):
A contract's ABI does not comply with the ERC-20 specification, breaking basic token functionality assumptions.
Required Contract Specification(s):
A token has a missing transfer event when a transfer occurs without a Transfer event being emitted.
Required Contract Specification(s):
A token has a misaligned transfer event when a transfer occurs, and there are Transfer events emitted, but the parameters of the events do not align with the state change that occurred in the balances of the accounts.
Required Contract Specification(s):
Contract parameters (decimals, fees, settings) can be changed post-deployment, disrupting value assumptions and integrations.
Required Contract Specification(s):
Transfers are restricted by thresholds, potentially subverting expected deposit and withdrawal behavior.
Required Contract Specification(s):
A token has transfer fees when either transfer or transferFrom siphon some portion of the amount being transferred between the two accounts in question. The receiver of the transfer receives less than the intended amount of the transfer.
Required Contract Specification(s):
Use of unsafe patterns (e.g., tx.origin) allows unintended transfers, undermining standard custody assumptions.
Required Contract Specification(s):
A contract is upgradeable when the implementation of the contract can be changed while the state is preserved. This is most frequently implemented with the Transparent Upgradeable Proxy extension.
Required Contract Specification(s):
A token is pausable when an account can execute transaction(s) on *any* contract that result in a blanket, un-targeted block of the transfer and transferFrom methods. This is distinct from a targeted block which applies to an account or set of accounts, which we call a Blacklist.
Required Contract Specification(s):
A privileged account can execute a selfdestruct action on the contract, which will destroy the contract and any associated storage.
Required Contract Specification(s):
A privileged account can increase supply or arbitrarily mint balances, potentially diluting value or manipulating liquidity.
Required Contract Specification(s):
Signature-based approvals that bypass on-chain controls, potentially allowing unauthorized access if misused.
Required Contract Specification(s):
A contract has management behavior when there are methods in the ABI that allow a privileged account to escalate or de-escalate the privileges of another account.
Required Contract Specification(s):
A token has governance behavior when there are DAO-style or multisig-controlled decision-making facilities in the contract.
Required Contract Specification(s):
A token exhibits X-bit arithmetic (where X is less than 256, the default arithmetic basis in Solidity) when it converts the 256-bit inputs from the ERC-20 specification methods into variables with X bits. X-bit arithmetic is important to consider during integration as it can create unusual behavior when performing arithmetic operations.
Required Contract Specification(s):
Exchanges, custodians, and DeFi platforms rely on tokens behaving in predictable ways. Any deviation from ERC-20 standards, or the presence of privileged capabilities, can create operational, legal, or financial risks. By cataloging and monitoring these behaviors, TestMachine enables platforms to make informed decisions about onboarding, mitigate risks proactively, and maintain user trust.