Euler Vaults
One immutable meta-adapter that reports an account's position in any Euler V2 ERC-4626 vault — both the EulerEarn aggregator vaults and the core eVaults (EVK, the lend/borrow product).
One immutable meta-adapter that reports an account's position in any Euler V2 ERC-4626 vault — both the EulerEarn aggregator vaults and the core eVaults (EVK, the lend/borrow product). Which vaults it queries is a governed instance set on the NAV Calculator; the adapter holds no per-vault state.
Type: Meta-adapter
protocolSubId:
keccak256("euler-vaults")Instance key: the vault address, widened to
bytes32
Positions returned
Up to two legs per vault, both denominated in the vault's underlying asset:
Supply
Supplied or Collateral
false
convertToAssets(balanceOf); Collateral if enabled as EVC collateral, else Supplied
Borrow
Borrowed
true
debtOf(account) — core eVaults only
A vault returns an empty result when its asset is unregistered, excluded by assetFilter, or the account has neither supply nor debt. Because an Euler vault's debt is denominated in the same asset as its supply, an unregistered asset already suppresses both legs together — so this adapter is structurally exempt from the collateral-without-debt suppression the mixed-asset adapters need.
debtOf and the EVC lookups are read through bounded, ABI-validated staticcalls rather than try/catch, so EulerEarn aggregators (which lack them) and non-Euler ERC-4626 tokens degrade gracefully — no debt leg, supply classified as Supplied. The distinction matters: try/catch does not intercept a call to a code-less address (Solidity's extcodesize precheck reverts in the calling frame) nor a return-data decode failure (the decode also runs in the calling frame, after the call returned), and either would otherwise drop the whole instance — supply and debt legs — silently suppressing a real debt and over-reporting NAV.
A debtOf that reverts and one that runs out of gas are treated differently, and the difference is load-bearing. A revert is an answer: an EulerEarn aggregator has no debtOf at all, and reading 0 for it is correct. Starvation is not an answer, so the read fails closed rather than recording zero debt. In Euler's core topology that matters beyond the one vault: an account borrows from a controller vault while its collateral sits in others, so on the controller balanceOf is 0 — suppressing its debt leg leaves that instance with no legs at all, while sibling vaults still report their collateral in full. The result is unoffset collateral and an over-reported NAV that nothing inside the instance can correct; only refusing to answer can. See a starved read is not an empty read.
Balance calculation
Supply classification: Collateral if vault appears in IEVC(vault.EVC()).getCollaterals(account), otherwise Supplied.
Identity
positionId:
abi.encode(address vault)— the vault address (both legs share it)positionKind:
Supplied·Collateral·Borrowed
There is no labels field on the position. The adapter implements positionLabels(positionId), which returns ["Vault", "<ERC4626 name()>"] from the vault's on-chain name — surfaced only by the verbose reads (getAccountPositionsVerbose / getAccountNavVerbose); the full breadcrumb is [protocolName, ...labels].
Constructor
navCalculator_
NAV Calculator contract (asset registry + instance set)
Registration
Meta-adapter. Register once and seed its vaults with addMetaBalanceAdapter(adapter, instances), then adjust with addMetaInstances(adapter, instances) / removeMetaInstances(adapter, instances) (MANAGER-gated). Each instance coordinate is a vault address widened to bytes32 (decoded via _toAddress). Adding a new vault is a config call — no new deploy.
Last updated