> For the complete documentation index, see [llms.txt](https://docs.infraredtrading.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.infraredtrading.com/learn/protocols/aave/deployments.md). # Deployments Unlike protocols that use a single deterministic address everywhere, **Aave V3 is deployed independently on each chain**. Every deployment has its own `PoolAddressesProvider`, `Pool`, access-control manager, oracle configuration, and asset list. Do not hardcode addresses or assume they match across chains. ## Resolve addresses from the address book The canonical source of truth is the [Aave address book](https://github.com/aave-dao/aave-address-book) (published on npm as `@bgd-labs/aave-address-book`), which exposes typed constants per deployment — for example `AaveV3Ethereum.POOL`, `AaveV3Arbitrum.POOL`. The robust pattern is to read the immutable `PoolAddressesProvider` for a chain and resolve the live `Pool` and other components from it. The official address dashboard is at [aave.com/docs/resources/addresses](https://aave.com/docs/resources/addresses). ### Ethereum mainnet (core market) anchors | Contract | Address | Role | | ------------------------ | -------------------------------------------- | ------------------------------------------------ | | PoolAddressesProvider | `0x2f39d218133AFaB8F2B819B1066c7E434Ad94E9e` | Immutable registry; resolve everything from here | | Pool | `0x87870Bca3F3fD6335C3F4ce8392D69350B4fA4E2` | Main entry point (proxy) | | ACLManager | `0xc2aaCf6553D20d1e9d78E365AAba8032af9c85b0` | Role-based access control | | Executor Level 1 (short) | `0x5300A1a15135EA4dc7aD5a167152C01EFc9b192A` | 1-day governance timelock | | Executor Level 2 (long) | `0x17Dd33Ed0e3dD2a80E37489B8A63063161BE6957` | 7-day governance timelock | On Ethereum, the Lido/"Prime", EtherFi, and Horizon markets are **separate pool deployments** with their own addresses (see [Ecosystem](/learn/protocols/aave/ecosystem.md)). ### Avalanche V4 Hub and Spoke Aave **V4 on Avalanche** (live July 15, 2026 — the first V4 deployment beyond Ethereum) uses the V4 **Hub-and-Spoke** architecture rather than the V3 `PoolAddressesProvider`/`Pool` layout: one Core Hub holds unified liquidity, and Spokes are the market entry points. Addresses are from the address book's [`AaveV4Avalanche.sol`](https://github.com/aave-dao/aave-address-book/blob/main/src/AaveV4Avalanche.sol); every address below returns deployed bytecode on Avalanche C-Chain (verified August 21, 2026). | Contract | Address | Role | | ---------------------------- | -------------------------------------------- | ----------------------------------------------------------- | | Core Hub | `0xd07369fAE4A5BB13c9Ce446B052c7867B1AbDf6e` | Unified-liquidity Hub (proxy) | | Main Spoke | `0x435272CefF93a1E657E8ABfdf0A13e95900A3a56` | Main Market Spoke (proxy) | | AVAX-Correlated Spoke | `0x3b517594277c67307CF2d7CBE6FE1D4399B68c41` | AVAX-Correlated Market Spoke (proxy) | | Forex Spoke | `0x6a37776B5E026dBdF043b4F933c323C84DD1B514` | Forex Market Spoke (proxy) | | Main Spoke Oracle | `0x84B50B131a82dA689C0205C00d603c1c92A5f8a4` | Oracle for the Main Spoke | | AVAX-Correlated Spoke Oracle | `0xB2216B2B2DC77e027AfEaaAf965E323012757fA0` | Oracle for the AVAX-Correlated Spoke | | Forex Spoke Oracle | `0xECA623E8c923A103Eef75cd127Cc8Bf8fF886cf5` | Oracle for the Forex Spoke | | Access Manager | `0xe069096bDAfF9bAD15b2f1079EaF0f1685a24522` | V4 role-based access control (replaces the V3 `ACLManager`) | | Hub Configurator | `0xbdf92ed96FF6D678469aFAFFa1e7d37B25beaa33` | Hub parameter admin | | Spoke Configurator | `0x8F72573F1Aa0A1e39fFD2a2A69e9EDAa8B982642` | Spoke parameter admin | | Native Token Gateway | `0xE4C7183A5f22c365140F41d733d8A8baD5A1a6bA` | Native AVAX wrap/unwrap entry | The same file also lists per-asset tokenization spokes (wAVAX, sAVAX, BTC.b, WETH.e, USDC, USDt, EURC), position managers, a signature gateway, the treasury spoke, the config engine, and the liquidation-logic library — resolve those from the address book rather than copying them. ## Chain coverage Aave V3 runs on **20+ independent mainnet deployments**, including Ethereum (Core, Lido/Prime, EtherFi, Horizon), Arbitrum, Optimism, Polygon, Avalanche, Base, BNB Chain, Gnosis, Scroll, Linea, Metis, zkSync Era, Celo, Sonic, Soneium, Mantle, Plasma, and others; **Monad** is the newest addition (July 2026, `AaveV3Monad` in the address book); Fantom and Harmony are deprecated. Ethereum holds the large majority of value. **Aave V4** runs on Ethereum (since March 2026) and Avalanche (since July 2026 — see the table above). For the complete, current list and per-chain addresses, use the [address book repository](https://github.com/aave-dao/aave-address-book). ## Upgradeability Aave V3's core contracts are **upgradeable proxies** (`InitializableImmutableAdminUpgradeabilityProxy`), with the `PoolAddressesProvider` acting as factory and admin (`setPoolImpl`, `setPoolConfiguratorImpl`, `setAddressAsProxy` — all owner-only, and the owner is governance). Governance can therefore upgrade Pool logic, the configurator, and reserve parameters, and has shipped real upgrades this way (for example V3.0.0 to V3.0.2 across chains). The trade-off — adaptability versus governance as an attack surface — is covered in [Security](/learn/protocols/aave/security.md). [PoolAddressesProvider docs](https://aave.com/docs/aave-v3/smart-contracts/pool-addresses-provider) ## Access-control roles The `ACLManager` (built on OpenZeppelin `AccessControl`) governs operational permissions. The original deployers have resigned `POOL_ADMIN`; per network it is held by the guardian multisig or the governance bridge executors. The canonical who-holds-what reference is the [permissions book](https://github.com/bgd-labs/aave-permissions-book). | Role | Capability | | ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | `DEFAULT_ADMIN_ROLE` / `ACL_ADMIN` | Root; manages role admins; held by governance | | `POOL_ADMIN` | Full operational control (update implementations, pause/activate/freeze reserves); superset of risk and asset-listing powers | | `RISK_ADMIN` | Adjust risk parameters (LTV, threshold, reserve factor, caps, eMode, rate strategy); cannot pause | | `EMERGENCY_ADMIN` | Pause/unpause the pool or individual reserves; held by the Emergency Guardian | | `ASSET_LISTING_ADMIN` | Update oracle sources and fallback; list assets | | `FLASH_BORROWER` | Exempt from flash-loan premiums | [ACL Manager docs](https://aave.com/docs/aave-v3/smart-contracts/acl-manager) ## Governance Voting power is AAVE + stkAAVE + aAAVE on Ethereum mainnet; proposal power and voting power are independently delegatable. Under **Governance Framework V2** — proposed in a [July 2026 ARFC](https://governance.aave.com/t/arfc-governance-framework-v2/25348) and adopted by a [binding Snapshot vote](https://snapshot.box/#/s:aavedao.eth/proposal/0x3e91a954f13f3b65cd4b87b4aaf56ba4f8dc91bfac9f9f1ce03fd619e9ea38f5) that closed August 9, 2026 (392,126.8 AAVE for, none against) — the mandatory temperature-check stage was retired and proposals now follow one of **three tracks**: * **Standard** — an ARFC forum post, a binding ARFC Snapshot, an on-chain AIP and vote, then timelocked execution (about 13 days end-to-end, down from 19). * **Direct-to-AIP** — a forum post straight to an on-chain AIP, reserved for minor, non-contentious changes submitted by active service providers. * **Steward** — delegated authority over a narrow, hard-coded parameter range (see Stewards below). (The [official governance docs page](https://aave.com/docs/ecosystem/governance) still described the earlier temperature-check flow as of late August 2026; the Snapshot result is the governing record.) **Aave Delivery Infrastructure (a.DI)** carries governance messages cross-chain over a multi-bridge consensus (never a single bridge) between the core network (Ethereum), voting networks, and every execution network. Two timelock tiers gate execution: **Level 1** (1 day, standard changes) and **Level 2** (7 days, core changes). **Stewards** hold bounded, parameter-only power for fast in-range adjustments without a full vote: the [Aave Generalized Risk Stewards](https://governance.aave.com/t/arfc-aave-generalized-risk-stewards-agrs-activation/19178) for reserve risk parameters (the parameter provider was Chaos Labs until its April 2026 departure; LlamaRisk is the sole continuing external risk provider, and the framework's ongoing operation had not been confirmed as of August 2026), and the **GHO stewards** (a 3-of-4 multisig over GHO rate, bucket, and stability-module parameters, with at least a 1-day delay and immutable steward contracts). ## Emergency guardians Two emergency multisigs bound the upgradeability risk above: * **Protocol Emergency Guardian** — holds the emergency-admin role and can pause reserves immediately across V2/V3. Set to **4-of-7** in the [May 20, 2026 signer rotation](https://governance.aave.com/t/aave-emergency-guardian-protocol-signer-rotation/24944), which tightened membership to actively-engaged stakeholders across Aave's network deployments. Signer identities are intentionally not disclosed, to reduce personal risk. * **Governance Emergency Guardian** — can cancel a malicious proposal within its lifecycle; **5-of-9**. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.infraredtrading.com/learn/protocols/aave/deployments.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.