---
name: avax-concepts
description: Explain or design Avalanche app state, incentives, token accounting and authorization before choosing contracts.
---

# Turn concepts into explicit behavior

1. Describe the application's states and permitted transitions. For each transition write caller, inputs, authorization, asset movement, failure conditions and emitted event. Separate submitting a transaction from reaching the intended state. Finish with a transition table that exposes who performs every delayed action.
2. Identify the actor and incentive behind maintenance. Contracts do not wake themselves up: liquidation, rewards distribution, relaying, expiration processing and rebalancing need an initiating transaction. Define payer, fee budget, retry bound and what happens when the actor stops. Use [Interchain](../interchain/SKILL.md) for destination delivery rather than assuming source acceptance causes execution.
3. Name the accounting unit at every boundary. Native AVAX is value; WAVAX is an ERC-20; native USDC and bridged USDC representations are distinct contracts. Keep raw integer amounts, token decimals, shares, debt units and fixed-point ratios separate. Complete one worked conversion against a contract preview or observed balance delta.
4. Identify the authority being granted. ERC-20 allowance authorizes a spender; NFT approval authorizes an operator/token transfer; EIP-712 signs typed data whose verifying contract decides the action. Bind owner, spender, asset, amount, recipient, chain/application domain, nonce and expiry as applicable. Do not describe signing as merely connecting a wallet.
5. Select a price source suitable for the decision. A DEX quote answers what an exact route may return; an indexer price is analytics; a lending oracle values collateral under protocol rules. Treat missing prices as unavailable, not zero, and test manipulation/staleness before using a spot pool for risk decisions.
6. Explain failure and exit paths in the user's units. For a swap show minimum output and gas; for lending show debt, collateral, liquidation threshold and available cash; for queued staking show shares, cooldown and redemption window. Finish with the action a user can actually take if the frontend or automation disappears.

## Work through these accounting traps

- DEXs: Pharaoh CL ticks, LFJ bins and Blackhole stable/volatile AMMs use different liquidity models. Pharaoh CL uses int24 tickSpacing, LFJ V2_2 is enum 3, and Blackhole RouterV2 has a six-field route. Choose a [protocol recipe](../defi/SKILL.md), not a generic Uniswap tuple.
- Lending: BENQI qiTokens have 8 decimals and exchange-rate mantissas; sAVAX represents non-rebasing shares. Aave V4 main-spoke supply is not a V3 aToken workflow; its tokenization spoke is a separate ERC-4626 surface. Silo collateral modes and Euler vault/controller relationships change what a deposit permits.
- ERC-4626: deposit(assets) returns shares while mint(shares) consumes assets; withdraw(assets) burns shares while redeem(shares) returns assets. A preview is not an enforced minimum or a guarantee of available liquidity.
- Governance: Pharaoh voting uses a user address and staked xPHAR context; Blackhole voting uses a veNFT tokenId. Similar incentive vocabulary does not imply compatible ownership checks.

## Reproduce a state transition

Paths and commands below resolve from the executable bundle root. Run `node research/parity-dexes/fork-execution.mjs`. It creates an isolated C-Chain fork, deposits synthetic AVAX into WAVAX, applies exact approvals, executes three swaps, and asserts token deltas and failure paths. The resulting local receipts illustrate the transition model; they are not mainnet transactions.

Read [Standards](../standards/SKILL.md) for token/signature interfaces, [Security](../security/SKILL.md) for adversarial transitions, and [Architecture](../architecture/SKILL.md) for custody/admin assumptions. Sources: [EIP-712](https://eips.ethereum.org/EIPS/eip-712), [ERC-4626](https://eips.ethereum.org/EIPS/eip-4626), primary deployments linked by each protocol recipe.