Behaviors

Behaviors

TestMachine’s token custody assessment system classifies token functionality into behaviors that directly affect the safety and predictability of custody.

Each behavior represents a purposeful capability (or standard deviation) of the token contract. Some are well‑intentioned design choices, but all must be documented to avoid surprises and manage risks in custodial workflows.

Behaviors are returned by the API as stable identifiers in the behaviors array (see Tokens).

If there are behaviors that matter to your custody workflows that aren’t listed here, contact TestMachine—new behaviors can be added.

Severity levels

Each behavior is assigned a severity level to help you prioritize review and controls.

• Critical (score 5) — major custody risks

• Medium (score 4) — operational disruption

• Low (score 3) — possible supply/value impact

• Info (score 2) — contextual awareness

Counts (current taxonomy)

• Critical: 12

• Medium: 2

• Low: 2

• Info: 3

Critical behaviors (score 5)

Blacklist (blacklist)

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): ERC‑20

Confiscation (confiscation)

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): ERC‑20

External calls (external_call)

A contract makes an external call when it interacts with another account on the network.

TestMachine tracks these external calls and builds the network module (call graph) that the contract is a member of. Knowing which contracts a token interacts with is a crucial aspect of a contract’s behavior profile—external contracts can augment the behavior of the target contract.

• Required contract specification(s): None

Insufficient decimals (insufficient_decimals)

A token has insufficient decimals when the decimals() method of the ERC‑20 specification returns an insufficient value. What values are insufficient is configurable and can change based on the contract and the context.

• Required contract specification(s): ERC‑20

Invalid ABI (invalid_abi)

A contract’s ABI does not comply with the ERC‑20 specification, breaking basic token functionality assumptions.

• Required contract specification(s): ERC‑20

Missing Transfer event (missing_transfer_event)

A token has a missing Transfer event when a transfer occurs without a Transfer event being emitted.

• Required contract specification(s): ERC‑20

Misaligned Transfer event (misaligned_transfer_event)

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): ERC‑20

Reconfiguration (reconfiguration)

Contract parameters (decimals, fees, settings) can be changed post‑deployment, disrupting value assumptions and integrations.

• Required contract specification(s): ERC‑20

Transaction amount limit (transaction_amount_limit)

Transfers are restricted by thresholds, potentially subverting expected deposit and withdrawal behavior.

• Required contract specification(s): ERC‑20

Transaction fee (transaction_fee)

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): ERC‑20

Transfer fee reconfiguration (transfer_fee_reconfiguration)

The token’s transfer-fee settings can be changed post‑deployment, which can disrupt integrations and custody assumptions.

• Required contract specification(s): ERC‑20

Unauthorized transfer (unauthorized_transfer)

Use of unsafe patterns (for example tx.origin) can allow unintended transfers, undermining standard custody assumptions.

• Required contract specification(s): ERC‑20

Upgrade (upgrade)

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 pattern.

• Required contract specification(s): None

Medium behaviors (score 4)

Pausable (pause)

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): ERC‑20

Self-destruct (self_destruct)

A privileged account can execute a selfdestruct action on the contract, which will destroy the contract and any associated storage.

• Required contract specification(s): ERC‑20

Low behaviors (score 3)

Minting (mint)

A privileged account can increase supply or arbitrarily mint balances, potentially diluting value or manipulating liquidity.

• Required contract specification(s): ERC‑20

Off-chain signatures / Permit (EIP‑2612) (permit)

Signature-based approvals that bypass on-chain controls, potentially allowing unauthorized access if misused.

• Required contract specification(s): ERC‑20

If your API uses a different key than permit for this behavior, tell me what it returns and I’ll align this page to the exact identifier.

Informational behaviors (score 2)

Management (management)

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): None

Governance (governance)

A token has governance behavior when there are DAO-style or multisig-controlled decision-making facilities in the contract.

• Required contract specification(s): ERC‑20

X-bit arithmetic (x_bit_arithmetic)

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 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): ERC‑20

Why these behaviors matter

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.