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

If you intend to use Curve's Liquidity Gauge, the CurveLiquidityGaugev3Facet should be connected only after the initial deployment regardless of whether you use DeployVault.sol or DeployVaultWithCoreFacets.s.sol

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.

If you intend to bridge vault shares to another chain, for example, to use in another DeFi protocol, you will need to deploy the OFT on the chain you wish to use it and wire it. See LayerZero docs.

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 (DiamondCutFacet and DiamondLoupeFacet)

  • References to omnichain adapters (LzAdapter and 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

Copy .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:

  1. DeployConfig.s.sol reads your env vars.

  2. getCuts() builds one FacetCut per facet (address, selector array).

  3. DeployVault signs with PRIVATE_KEY and calls deployVault() 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

  1. Execute the following command

  1. Wait for verification.

  2. 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.

The finalization of your spoke's setup requires block finalization on the spoke chain. For supported chains this can vary between a few minutes and 2 hours. For your spoke deployment transaction, check the block finalization on the respective block scanner.

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