Deploying Vaults
This walkthrough shows how a strategist can launch a MORE Vault on any EVM network on which the MORE Vaults protocol is deployed using the Solidity scripts that ship with the core repo. To deploy on your target network, you can switch RPC endpoints and explorer links.
Quick links:
There is a single registry on each chain's MORE Vault Factory. The registry is permissionless insofar as anyone can create a vault. However, vaults may only activate facets included in the Vault Registry.
Cross-Chain Hub & Spoke Model
While MORE vaults can be deployed as single chain vaults, the protocol was designed to support omnichain deployments out-of-the-box.
To facilitate omnichain vaults, MORE relies on a hub and spoke model, supported by the core bridge facet. The facet itself is agnostic to underlying bridges and provides a unified interface with any cross-chain messaging infrastructure.
The flagship version of this facet ships with support for LayerZero. Later, it will be extended to include additional bridges with the goal of offering additional breadth and fallback resilience.
Step-by-step deployment guide
There are multiple scripts that can be used to deploy both the Core Vault as well as certain integrations, known as facets.
DeployVault.s.sol – deploys the Core Vault as well as all available and whitelisted integrations.
DeployVaultWithCoreFacets.s.sol – deploys only the Core Vault with core facets.
Other scripts exist to deploy individual integrations such as Aave v3, Curve, Uniswap v3, etc.
Scripts location: /scripts
What you’ll deploy
Diamond proxy – the vault contract which uses existing core and optional facets.
MORE Vaults Composer – handles cross-chain actions within an omnichain vault deployment.
OFT Adapter for Vault Shares - smart contract that handles bridging shares of spoke vaults to the hub.
Environment setup
If forge build fails or the RPC later errors, hop onto Discord and open a #support-ticket for live help.
Deploying the Hub Vault
The hub vault is the root of an omnichain vault network. It acts as the canonical authority for global NAV (Net Asset Value), cross‑chain coordination, and curator actions. While factories and facets are deployed by the protocol, the curator initializes and configures the hub to manage strategies and coordinate spokes.
When the hub is deployed, it contains:
Core ERC‑4626 logic (
VaultFacet)Cross‑chain logic (
BridgeFacet)Access control configuration (
AccessControlFacet)Vault configuration facet (
ConfigurationFacet)Default Diamond facets (
DiamondCutFacetandDiamondLoupeFacet)References to omnichain adapters (
LzAdapterand OFT adapters)Multicall facet
ERC-4626 and ERC-7540 logic to interact with other vaults
From the curator’s point of view, deploying the hub establishes the control center for all cross‑chain actions.
Create .env
.envCopy .env.example to .env and fill in:
Need facet addresses? The Contracts page lists every DAO‑approved facet.
Dry-run
Foundry prints the CreateVaultParams and the array of FacetCut entries it will submit. Check every field: roles, fee, capacity, facet list. Edit .env and repeat until correct.
What happens:
DeployConfig.s.solreads your env vars.getCuts()builds oneFacetCutper facet (address, selector array).DeployVaultsigns withPRIVATE_KEYand callsdeployVault()on the factory.
Broadcast
Add --broadcast to send the transaction:
Save the transaction hash, and once mined, the vault address is printed by Foundry.
Verify
Execute the following command
Wait for verification.
Check the returned URL and ensure your contract was verified.
Execute the following command
Wait for verification.
Check the returned URL and ensure your contract was verified.
Deploying Spoke Vaults and Building the Mesh
Spoke vaults are the chain‑local execution units. Each spoke manages assets on its chain but reports accounting back to the hub. Together, the hub and spokes form a mesh, where the hub commands and spokes respond.
Spokes rely on the same diamond architecture but are initialized with isHub = FALSE. The curator’s task is to ensure that every spoke is registered and connected to the hub. Use the same salt for each chain. For easier management and compatibility, ensure facets match those of the hub.
Request Spoke Registration
Execute this from the spoke chain:
hubEid: LayerZero EID for the hub chain.hubVault: Address of the hub.spokeVault: Address of the new spoke.options: LayerZero executor options (gas limit, refund address).msg.value: Covers LayerZero message fee.
The function emits SpokeRegistrationRequested, notifying the hub.
Bootstrap from the Hub
On the hub chain:
This transmits initialization data and configuration to the spoke.
Broadcast the Full Mesh
If you have deployed more than 1 spoke:
The hub notifies all other spokes of the new connections, ensuring they’re aware of each other.
Verify Connectivity
After bootstrapping:
All should return valid data. A missing entry means registration failed or LayerZero messaging didn’t complete.
Last updated