Security and limitations

Trust assumptions

• Users trust the Ledger owner not to upgrade core contracts maliciously.
• Users trust Mezo Earn, voters, distributors, and CL infrastructure.
• Users trust vote/swap maintainers with operational Mezo actions, not with user ERC-1155 balances.
• ID20 contracts cannot be upgraded; bugs there are permanent.

Launch configuration still incomplete

• Both managers: mTokenId = 0 — managed deposits cannot start.
• veBTC.canSplit(Vault) = false — exact BTC redeem that needs a split fails.
• avBTCm and avMEZOm are not whitelisted on the pool Voter.
• Neither Aurove CL pool has a Mezo gauge.

Behavioural limits

• Managed products only. epochs on deposit is ignored.
• Redeem returns veNFTs, not ERC-20 BTC/MEZO.
• MEZO inventory is indivisible. BTC split depends on Mezo permission.
• Mezo first-hour and one-managed-op-per-epoch rules still apply.
• Grant-backed veNFTs revert until vesting ends.
• Foreign managed deposits into the same mTokenId do not mint Aurove shares.
• Valuation decreases do not burn tranche supply.
• Zero-eligible-supply remainders can sit in reward accounting with no sweep.
• ID20 surplus backing cannot be recovered. Gauge activate is permanent.
• Credit-classified ID20 cannot unwrap until settlement. Transfers can revert on gauge credit rules.
• Zap exact-output leftovers are ID20. The router ERC-1155 callback has no in-flight flag.

Verification coverage

Verification is listed per address in the deployment reference. User-facing ID20 tokens, Id20Gauges, and zap adapters are verified on Sourcify only, not on Blockscout. The two CL pool clones are not independently verified. The Ledger owner is an EOA.