Addresses & Deployments
Multyr contracts are deployed on Arbitrum One. The system is currently in validation phase. Deposits are not open to the public. Behavior described on this page reflects the protocol's designed behavior; some mechanisms are active in shadow testing, others become active at public launch. See the Status page for details.
This page defines how Multyr contract addresses are structured across deployments and how integrators should interact with them.
⚠️ Important: Address Variability
Contract addresses in Multyr are not globally static.
They may change depending on:
- deployment version (e.g. v6, v9.1)
- system state (pre-seal vs sealed)
- chain / network
- vault instance
👉 Integrators MUST always use the active deployment listed here and avoid relying on previously used addresses.
Network
Current primary deployment:
- Arbitrum One
- chainId:
42161
Deployment Status
Allocation Protocol addresses are not publicly disclosed during the shadow testing phase.
CoreVault, DepositRouter, Strategy, and Adapter addresses are held private until whitelist beta (Phase 4 — public mainnet launch after audit completion). This policy reduces exposure during validation and aligns capital access with the audit and whitelist process.
Publicly available now:
- Governance and treasury Safe addresses — see Reference — Addresses
- External dependencies (USDC, Permit2) — see Reference — Addresses
Available at Phase 4 (public launch):
- CoreVault address
- DepositRouter address
- Strategy and Adapter addresses
- Subgraph endpoints
Integrators preparing for Phase 4 can reach out to partnerships@multyr.fi for early access coordination.
Network
Current primary deployment network:
- Arbitrum One
- chainId:
42161
Integration Roadmap
During shadow testing phase:
- Frontend / SDK integrations — not yet available externally. Contracts are accessible only through the official Multyr UI.
- Early integration partners — reach out via partnerships@multyr.fi for coordination.
At Phase 4 (public launch):
- Active deployment addresses will be published here
- Subgraph and SDK will become publicly accessible
- Integration documentation will include full contract references
Post-sealing:
- Latest sealed deployment becomes the canonical integration target
- Previous deployments will be marked as legacy
Core Integration Surface
Integrators will interact with a minimal subset of contracts:
| Component | Purpose | Availability |
|---|---|---|
| USDC | Input asset (Arbitrum canonical) | Public now — see Reference — Addresses |
| Permit2 | Signature-based approvals | Public now — see Reference — Addresses |
| DepositRouter | Primary deposit entry (Permit2) | Private until Phase 4 |
| CoreVault | Reads, deposits, withdrawal requests | Private until Phase 4 |
All other contracts are internal or governance-controlled.
Stable Addresses
Some addresses are effectively stable across deployments:
| Component | Address |
|---|---|
| USDC (Arbitrum) | 0xaf88d065e77c8cC2239327C5EDb3A432268e5831 |
| Permit2 (Uniswap) | 0x000000000022D473030F116dDEE9F6B43aC78BA3 |
These can be safely treated as constants.
Deployment Model
Multyr uses a modular architecture composed of:
- CoreVault (execution layer)
- delegatecall modules (ERC4626, Queue, Admin, LiquidityOps)
- external components (BufferManager, StrategyRouter, FeeCollector)
- per-strategy contracts
- per-vault instances
Dynamic Components
The following addresses are expected to change over time:
- vault instances
- strategies
- adapters
- routers (in major upgrades)
These are:
- deployed independently
- registered via on-chain registries
- controlled via governance
Vault Instances
Each vault:
- has its own address
- maintains isolated accounting
- can have independent strategy configurations
Address Discovery
Developers should NOT hardcode addresses.
Instead, use:
- deployment registry (if available)
- protocol events
- subgraph indexing
- official docs (this page)
Governance-Controlled Addresses
Critical system components are controlled via governance:
- multisig SAFE wallets
- timelock contracts
- guardian roles
See:
Upgrade & Versioning Model
Multyr follows a staged upgrade flow:
- New deployment (pre-seal)
- Validation phase
- System seal (immutability)
- Migration of integrations
👉 Multiple deployments may coexist during transition phases.
Best Practices for Integrators
- never hardcode contract addresses
- always reference the current deployment
- treat CoreVault as the integration anchor
- use DepositRouter for primary deposits
- monitor events for system changes
Summary
Multyr uses a flexible deployment model with:
- versioned deployments
- dynamic contract addresses
- modular architecture
- governance-controlled upgrades
This enables rapid iteration while preserving safety and upgradeability.