---
name: avax-architecture
description: Review Avalanche app custody, censorship, source access, privacy, admin powers and credible exit paths.
---

# Architecture and trust review

1. Define the review boundary: prototype, existing deployment or release candidate; chain and VM; contract addresses/revisions; UI/API/indexer; signers and external dependencies. Record what was inspected and what is unavailable. Use [Why](../why/SKILL.md) if chain choice is still open.
2. Trace custody and authorization along every asset path. Identify who can move principal, alter allowances, change the recipient, upgrade code, admit validators, set roots/oracles or pause withdrawals. Resolve proxy implementations and real administrative roles through [Addresses](../addresses/SKILL.md). Finish with a power map tied to actual contracts, not labels such as decentralized or noncustodial.
3. Test censorship and independent access. Ask whether a user can read state, submit a valid transaction and withdraw without the preferred frontend/RPC/operator. Separate protocol access restrictions from a site's restrictions. On a sovereign L1 include validator admission, transaction admission, node availability and any forced inclusion/exit mechanism that actually exists; do not invent a rollup-style escape hatch.
4. Check source accessibility and reproducibility. Identify licenses per component, compiler inputs, deployment configuration and verification evidence. A public ABI is not complete source, an explorer label is not reproducible bytecode, and an unlicensed upstream file is not permission to redistribute it. Describe proprietary dependencies precisely instead of silently replacing them.
5. Model privacy by observer and data field. Include calldata/events, balances, public inputs, RPC queries, IP/timing metadata, wallet connection and offchain retention. For proof-based apps distinguish hidden witnesses from public recipients and nullifiers. Continue with [Noir](../noir/SKILL.md) only when a proof changes a stated privacy requirement.
6. Exercise failure and exit scenarios: admin compromised, frontend offline, RPC stale, oracle unavailable, relayer absent, liquidity exhausted and upgrade changed. Use [Audit](../audit/SKILL.md) for contract vulnerabilities and [QA](../qa/SKILL.md) for observed UI failure states. Finish each finding with impact, demonstrated evidence and a concrete repair or explicitly accepted tradeoff.

## Worked boundary: a C-Chain swap interface

The frontend prepares calldata but does not need custody. The user's WAVAX allowance belongs to a specific router and the swap recipient is explicit. A compromised frontend can request different calldata, so the product must expose the spender, token pair, amount and minimum output at the wallet boundary. A quote service outage blocks new quotes; it should not fabricate a price. Existing users may interact directly with the router, but only if its actual permissions and token approvals allow that route.

For Blackhole, RouterHelper is upgradeable even when RouterV2's address stays fixed. The executable recipe records helper implementation identity and verifies its current router binding. This is a real extra trust dependency, not proof of an exploitable vulnerability. For an Avalanche L1 version of the app, include that L1's validator/VM/operator powers; C-Chain protocol presence does not carry over.

## Worked boundary: private membership gate

The [Noir example](../noir/SKILL.md) hides a depth-two membership witness, while recipient and consumption timing remain public. The issuer chooses approved roots. An issuer who refuses a root can deny membership; calling the app fully private and censorship resistant would exceed the demonstrated guarantees. Domain binding and nullifier persistence address different threats: cross-application replay and repeat consumption.

**Deliver:** scope; asset/authority diagram; findings grouped by custody, censorship, source access, privacy and security; evidence and severity rationale; concrete next actions; residual trust. Count resolved findings only after the relevant proof passes.

Sources: [Avalanche L1 architecture](https://build.avax.network/docs/avalanche-l1s), [ACP-77](https://build.avax.network/docs/acps/77-reinventing-subnets), [OpenZeppelin proxies](https://docs.openzeppelin.com/contracts/5.x/api/proxy), primary sources in [Blackhole](../blackhole/SKILL.md).