Fungible Asset Security

Skill: FUNGIBLE_ASSET_SECURITY

Trigger: FA_STANDARD flag detected (protocol uses FungibleAsset standard) Used by: Breadth agents, depth-token-flow Covers: FungibleAsset metadata validation, zero-value exploitation, store ownership, dispatchable hooks, Ref safety, Coin-to-FA migration

Purpose

Audit FungibleAsset standard usage for Aptos-specific vulnerabilities. The FA standard introduces object-based token management with capabilities (MintRef, BurnRef, TransferRef, FreezeRef) and optional dispatchable hooks. Incorrect usage creates counterfeit token acceptance, forced transfers, reentrancy, and accounting mismatches.

Methodology

STEP 1: Metadata Validation Audit

For EVERY function that accepts a FungibleAsset parameter or reads from a FungibleStore:

How metadata validation works:

// CORRECT: validates the asset is the expected type
let metadata = fungible_asset::metadata(&fa);
assert!(metadata == expected_metadata, ERROR_WRONG_ASSET);

// VULNERABLE: no validation - accepts ANY FungibleAsset
public fun deposit(fa: FungibleAsset) {
    // Attacker can pass a worthless FA created from their own metadata
    fungible_asset::deposit(store, fa);
}

MANDATORY SEARCH: Grep all .move files for:

1. FungibleAsset in function signatures (parameters)
2. For each hit: trace whether fungible_asset::metadata(&fa) is called and compared
3. Functions that ONLY use fungible_asset::amount(&fa) without metadata check -> FLAG

Severity: Accepting unvalidated FungibleAsset = accepting counterfeit tokens. If the function credits the user or modifies protocol state based on the FA amount -> HIGH/CRITICAL.

STEP 2: Zero-Value Exploitation

Analyze zero-value FungibleAsset paths:

Check for each:

1. Can fungible_asset::zero(metadata) be used to trigger code paths that modify state? (e.g., register a user, set a flag, emit an event)
2. Does fungible_asset::destroy_zero(fa) clean up properly, or does it leave dangling state?
3. Can zero-value deposits/withdrawals:
   • Register a new FungibleStore where one shouldn't exist?
   • Trigger reward distribution checkpoints?
   • Bypass minimum deposit requirements (checked after or before deposit)?
   • Create entries in tracking data structures (SmartTable, vector)?
4. Does amount == 0 get explicitly checked and rejected at entry points?

Pattern: Zero-value operations often bypass amount > 0 checks that were assumed but never written, allowing state modifications without economic cost.

STEP 3: Store Creation and Ownership Analysis

Audit FungibleStore creation, ownership chains, and access control:

3a. Store Creation Inventory

CRITICAL: primary_fungible_store::ensure_primary_store_exists(addr, metadata) is permissionless. An attacker can create a primary store for ANY address for ANY metadata. If the protocol assumes a store's existence means the user has interacted with the protocol -> FINDING.

3b. Transitive Ownership

Check: If Object A owns Object B which owns a FungibleStore, the owner of Object A can withdraw from B's store through the ownership chain. Trace all object ownership hierarchies for unintended fund access paths.

3c. Store Address Confusion

Pattern: Protocol calculates expected store address but user can supply a different store address. If the function doesn't verify the store belongs to the expected object/address -> FINDING.

STEP 4: Dispatchable Hook Analysis

If the protocol uses dispatchable FungibleAsset (custom withdraw, deposit, or derived_balance hooks):

4a. Hook Inventory

4b. Reentrancy via Hooks

For each registered hook:

1. Does the hook call back into the registering module's public functions?
2. Does the hook call into any other module that reads/writes shared state?
3. Is #[module_lock] applied to the registering module? (prevents indirect reentrancy but NOT direct)
4. What state has been modified BEFORE the hook executes? Can the hook see inconsistent state?

Reentrancy sequence:

Module::transfer() {
    1. Read balance (CHECK)
    2. Deduct from source store → triggers withdraw hook (INTERACTION before EFFECT completion)
    3. Withdraw hook reenters Module::another_function()
    4. another_function() sees partially-updated state
    // ...
}

4c. Deposit Hook Blocking

Can a deposit hook unconditionally revert to prevent deposits into a specific store?

• If YES: can this be used to DoS the protocol? (e.g., prevent liquidations, block reward distribution)
• Who controls the hook? (protocol, user, external party)

4d. Derived Balance Manipulation

If derived_balance hook is registered:

1. Does the protocol call fungible_asset::balance(store) expecting the real balance?
2. balance() calls derived_balance hook if registered - the returned value may differ from actual stored amount
3. Can the hook return inflated values to trick the protocol? (e.g., appear to have more collateral)
4. Can the hook return deflated values? (e.g., trigger incorrect liquidation)

STEP 5: Ref Safety Analysis

Audit the lifecycle and access control of FungibleAsset capability references:

5a. Ref Inventory

MANDATORY CHECK for each Ref:

1. Is the Ref stored in a resource with key only? (safe - not extractable)
2. Is the Ref stored in a struct with store ability? (dangerous - can be moved out)
3. Is the Ref stored in an Object? Who owns the Object? Can ownership be transferred?
4. Are there public functions that return the Ref or pass it to external code?