AVALANCHE / Integrations
Verified deployment identity
Resolve Avalanche token and protocol deployments with provenance and chain-specific onchain checks.
Open raw MarkdownMARKDOWN SOURCE
--- name: avax-addresses description: Resolve Avalanche token and protocol deployments with provenance and chain-specific onchain checks. --- # Addresses & asset identity Source review: 2026-09-06. Recheck network-dependent facts before use. 1. Key every deployment by chain ID, protocol, version and role. Start with the issuer or protocol's maintained registry, not a remembered address or token symbol. Preserve the source URL and observation date. 2. On the intended chain inspect deployed code. Resolve proxies and their current implementations where relevant; compare ABI and administrative roles with the intended release. Nonempty bytecode alone is not identity verification. 3. For an ERC-20, read metadata and required behavior from the contract. Treat a bridged representation as a distinct asset from issuer-native tokens until verified. AVAX is native currency; WAVAX is an ERC-20 wrapper, so their transfer/approval paths differ. 4. For a router or lending integration, validate the address's role and version before any allowance. Simulate the precise call and return the source-backed evidence record. 5. Mark entries as documentation-sourced, onchain-checked or unresolved. Do not upgrade documentation evidence into a claim of runtime verification. ## Documentation-sourced example Circle lists native USDC on Avalanche C-Chain (43114) at: `0xB97EF9Ef8734C71904D8002F8b6Bc66Dd9c48a6E`. This is an issuer-registry reference, **not a live bytecode/implementation attestation**. Recheck before integration. Use [SnowScan](https://snowscan.xyz/address/0xB97EF9Ef8734C71904D8002F8b6Bc66Dd9c48a6E) for this C-Chain address; do not use its page as proof of token ownership or risk. **Evidence record:** chain ID, address, asset/protocol role, version, registry URL, observed block/hash, code/implementation checks and verification status. ## Primary sources - [Circle USDC registry](https://developers.circle.com/stablecoins/usdc-contract-addresses) - [LFJ Avalanche deployments](https://developers.lfj.gg/deployment-addresses/avalanche) - [ERC-20 metadata and behavior](https://docs.openzeppelin.com/contracts/5.x/api/token/erc20) ## Runtime-checked protocol manifests The executable bundle includes `examples/protocols/<slug>/manifest.json` and inspect/plan modules for [Pharaoh](../pharaoh/SKILL.md), [Aave V4](../aave-v4/SKILL.md), [LFJ](../lfj/SKILL.md), [Blackhole](../blackhole/SKILL.md), [Silo](../silo/SKILL.md), [Euler](../euler/SKILL.md) and [BENQI](../benqi/SKILL.md). Resolve the actual proxy pattern: EIP1967 where applicable, custom implementation getter, factory-managed proxy or minimal clone. Hash proxy AND effective implementation, then prove role-specific links: router→factory, pool→tokens/spacing, vault→asset/EVC/Hub, market→Comptroller. A nonzero code hash alone is not semantic provenance or an audit. Current Pharaoh differs from historical search results; Blackhole's helper is upgradeable; Silo clones bind implementation3.8.0; Euler's factory exposes proxy configuration; AaveV4 asset/reserve IDs are mappings rather than addresses. These are checks to rerun, not evergreen guarantees. `node research/parity-standards/capture-live.mjs` additionally verifies native-USDC domain/nonce state and ERC8004 Identity/Reputation linkage. A registry entry does not prove an offchain service is available or safe. Label documentation-only, runtime-checked and local-executed entries separately.