Deployment addresses
Per-chain contract addresses for the Onchain Accounting System (NAV) — the canonical CREATE2 layer, the chains it runs on, and per-chain feeds and adapters.
The Onchain Accounting System (NAV) is deployed on 24 chains. On 5 of them the funds hold positions, so those carry registered assets — with custom price feeds and balance adapters as needed; the other 19 run the canonical layer (implementation + proxy) only. Configuration is incremental and per-chain: coverage varies (some chains carry many assets, others only a few), and it expands as the funds' strategies do. New custom price feeds and balance adapters are developed and/or deployed as needed — bringing a new protocol, asset, or chain into a strategy means shipping its feed/adapter (if one doesn't exist yet) and registering it on the NAV Calculator.
The one address every integrator calls: the NAVCalculator proxy at 0x80eD5cc6cEbAe4fEE1eD8687279aa492A50afa8d — the same address on every chain.
Read addresses from this page at integration time — never pin them in code. Every address here describes the deployment that is live now, and the whole stack is redeployed behind a new proxy rather than upgraded in place whenever a change reaches code inlined into ERC20Default (the reason is under the canonical layer below). So the proxy is stable, not permanent, and the per-chain counts move with each redeploy. Re-read this page, or the canonical JSON, before trusting a cached address.
The machine source of truth is the contracts repo, one file per chain:
script/config/deployments/{chainId}.json — written by the deploy scripts as each contract lands. The tables below mirror that state; the JSON is canonical if they ever diverge.
Canonical layer (CREATE2 — identical on every chain)
These contracts are deployed deterministically via CREATE2, so each has the same address on every chain.
NAVCalculator proxy (UUPS)
The address every consumer should call. Permanent across upgrades. Verbose label reads (getAccountNavVerbose / getAccountPositionsVerbose) live here.
NAVCalculator implementation
UUPS impl, immutable post-deploy.
PriceFeedLib
External library linked into the implementation.
NAVRegistryLib
External library linked into the implementation.
ERC20Default balance adapter
Created inside NAVCalculator.initialize(); identical everywhere and cannot be removed.
Always call the proxy address. The implementation may change on upgrade; the proxy survives those upgrades.
"Permanent" means across implementation upgrades — it does not mean the stack can always be migrated in place. The ERC20Default adapter above is minted inside initialize(), its setter is set-once with no admin path, and the registry refuses to remove it by name. So no upgrade, no config transaction and no admin call can repoint a live proxy at a different ERC20Default.
That matters because ERC20Default prices every wallet balance on every chain, and its bytecode is reachable from shared code that is internal — inlined at compile time rather than linked at an address. A fix in that shared code therefore only reaches the adapter when the adapter is itself recompiled, which an implementation upgrade cannot do. When such a change ships, the whole stack is deployed afresh behind a new proxy address rather than upgraded, and integrators move to it. Treat the proxy as stable, not as immortal, and read it from this page rather than hard-coding it.
So a redeploy is a new proxy whenever ERC20Default's bytecode changes — that is the trigger, not a schedule.
The two external libraries above are linked at an address rather than inlined, so their addresses are pinned pre-deploy from a clean whole-program build and change whenever their own compilation output does. A library pin is only final once the deploy tree is — any change reaching a library's own source moves it again, including work for a feature deliberately kept out of the NAV, since the enabling code may edit the libraries regardless. Take the library addresses from this page or the canonical JSON after the redeploy, never from a pre-deploy figure.
Chains
These 5 chains carry the assets registered for the funds' strategies — priced by direct feeds and (where needed) custom price feeds, plus balance adapters. The set registered so far was chosen to cover the first funds' initial strategies — a deliberate superset rather than an exact fit — and it grows per-chain as positions are added, so the counts below vary:
Chain
Chain ID
Registered assets
Custom price feeds
Balance adapters (excl. ERC20Default)
Ethereum
1
43
24
26
Optimism
10
6
0
2
Arbitrum
42161
11
8
7
Base
8453
11
4
6
Gnosis
100
11
3
3
Registered assets is the NAV's total priced-token count for that chain (getAssetCount()) — every token the NAV values, most of them via direct feeds. It is therefore larger than the two right-hand columns, which count only the custom composite price feeds and the non-ERC20Default balance adapters. A 0 in custom price feeds means that chain's assets are all priced by direct feeds (Chainlink / Redstone / API3) registered straight on the NAV — no custom composite feed is needed. See Price feeds.
The NAV implementation + proxy (canonical layer only — no registered assets yet) are also live on 19 further chains: BSC (56), Polygon (137), Berachain (80094), Ink (57073), Linea (59144), opBNB (204), Sonic (146), Unichain (130), Scroll (534352), X Layer (196), Celo (42220), Avalanche (43114), Mantle (5000), World Chain (480), Monad (143), Plasma (9745), Hemi (43111), 0G (16661), HyperEVM (999). Custom feeds and adapters are registered on each as assets land there.
Balance adapters (per chain)
These are plain CREATE deployments, so their addresses are unique per chain.
Assisted adapters (ether.fi, Nexus, StakeWise exit) report $0 until the position owner feeds its coordinates — permissionlessly, on-chain, typically via the paired delegatecall assistant. They provide correctness-on-exit coverage, not steady-state value.
The assisted adapters' assistants (delegatecall action modules — see Assisted balance adapters) are listed under their chain, below the adapter table. They are not registered on the NAV Calculator.
Ethereum (1)
AaveV3InstancesMeta
CompoundV3CometsMeta
AaveV3SafetyModule
AaveUmbrella
MorphoVaultsMeta
MorphoMarketsMeta
EulerVaultsMeta
GearboxV3MarketsMeta
BalancerV3PoolsMeta
BalancerV3GaugesMeta
CurvePoolsMeta
CurveGaugesMeta
ConvexCurveLPStakingMeta
FluidFTokensMeta
FluidVaultsMeta
StaderWithdrawalQueue
KelpWithdrawalQueue
LidoWithdrawalQueue
EthenaCooldown
StakeWiseV3VaultsMeta
EtherFiWithdrawalQueueAssisted
NexusMutualStakingPoolsAssisted
StakeWiseV3ExitQueueAssisted
UniswapV3PoolsMeta
Assistants — Ethereum:
NexusMutualStakingPoolsAssistant
EtherFiWithdrawalQueueAssistant
StakeWiseV3ExitQueueAssistant
Optimism (10)
AaveV3InstancesMeta
CompoundV3CometsMeta
Arbitrum (42161)
AaveV3InstancesMeta
CompoundV3CometsMeta
MorphoVaultsMeta
MorphoMarketsMeta
BalancerV3PoolsMeta
BalancerV3GaugesMeta
FluidFTokensMeta
Base (8453)
AaveV3InstancesMeta
CompoundV3CometsMeta
MorphoMarketsMeta
BalancerV3PoolsMeta
BalancerV3GaugesMeta
FluidFTokensMeta
Gnosis (100)
AaveV3InstancesMeta
StakeWiseV3VaultsMeta
StakeWiseV3ExitQueueAssisted
Assistants — Gnosis:
StakeWiseV3ExitQueueAssistant
Custom price feeds (per chain)
These are plain CREATE deployments, so their addresses are unique per chain. Chains not listed below have no custom price feeds — their assets use direct feeds.
Ethereum (1)
ezETH (CrossRate)
ETHx (CrossRate)
osETH (CrossRate)
rETH (CrossRate)
Arbitrum (42161)
wstETH (L2)
syrupUSDC (L2)
weETH (CrossRate)
ezETH (CrossRate)
rsETH (CrossRate)
Base (8453)
wstETH (L2)
weETH (CrossRate)
Gnosis (100)
Last updated