---
name: avax-security
description: Review Avalanche value-moving contracts for token, authorization, oracle and cross-chain failure modes.
---

# Contract & integration security

Source review: 2026-09-06. Recheck network-dependent facts before use.

1. Map the assets and privileged operations in the requested scope. Identify upgrade administrators, pause powers, approval spenders and any cross-chain authority. Finish with explicit trust boundaries and the invariants that protect funds.
2. Inspect actual token behavior instead of assuming every ERC-20 returns a boolean or uses 18 decimals. Use the selected library's safe transfer/approval helpers where appropriate, and measure received amounts when transfer behavior can differ from the requested amount.
3. Trace external calls and callbacks through all value-moving paths. Test whether reentrancy, partial accounting or signature replay can violate the invariants. Verify domain/chain separation for signed operations.
4. For pricing and swaps, verify oracle source, decimals, freshness and the operation's slippage bounds. Test manipulated or unavailable inputs. A DEX spot quote is not an independent price oracle.
5. If interchain actions exist, use [Interchain](../interchain/SKILL.md) to review authenticated origin, destination, retries and administrative dependencies. Review each trust boundary rather than treating transport authentication as application authorization.
6. For custom L1 precompile integrations, test the actual call context and configured privileged roles. Stateful precompiles can reject `delegatecall`/`callcode` unless explicitly supported; generic EVM mocks do not prove this behavior.
7. Reproduce suspected defects with a bounded test, then report impact, preconditions and evidence. State what was not reviewed. A checklist pass is not a third-party audit.

**Evidence to return:** scoped findings, executable reproductions for demonstrated issues, unresolved assumptions and tested invariants. Remediation must preserve the user's requested functionality and authorization.

## Primary sources

- [OpenZeppelin ERC-20 utilities](https://docs.openzeppelin.com/contracts/5.x/api/token/erc20)
- [Teleporter implementation](https://github.com/ava-labs/icm-services/tree/main/icm-contracts/avalanche/teleporter)
- [Viem simulation](https://viem.sh/docs/contract/simulateContract)

- [Granite stateful-precompile incident analysis](https://build.avax.network/blog/delegatecall-incident)

## Verify the concrete custody and authorization boundaries

Read [Architecture](../architecture/SKILL.md) for admin/custody/exit assumptions and [Audit](../audit/SKILL.md) for scoped findings. The executable core DepositVault accepts only assets with exact transfers and stable balances; boundary delta checks detect inexact transfers, not arbitrary out-of-band rebases or dishonest balanceOf behavior. Unsupported token economics require separate design.

Run `node examples/core/verify.mjs`. Inspect its contract tests for own-balance withdrawal authorization, explicit receiver/amount, token-return behavior, atomic rollback, callback guard and conservation. Fuzz coverage is a measured property over generated inputs, not a claim of exhaustive verification.

Run `node --test examples/standards/standards.test.mjs` for integer rounding and chain/domain/payee/nonce/budget/expiry checks. `node examples/privacy/verify.mjs` checks root authority, recipient/domain binding and nullifier replay with a real proof/verifier. Registration or valid proof does not authorize a different application action.

Keep fork identities and local funding labeled, inspect protocol-specific return codes, and never equate an unchanged proxy runtime or successful receipt with successful application semantics. Report unresolved assumptions and coverage gaps honestly; independent read-only review and executed regressions are distinct from an exploit evaluation.