MORE
  • Introduction
  • MORE Vaults
    • Vaults Framework
      • Diamond Standard (EIP-2535)
      • Component Interactions
      • Upgrade & Governance Flow
    • Core Protocol Components
      • Factory
      • Core Facets
      • Registries
      • Internal Libraries
      • Accounting
    • Connectors
      • AMMs & DEXes
      • Staking
      • Lending
      • Leverage
      • Oracles
      • External Interfaces
      • Multicall
    • Security & Governance
      • Roles & Access Control
      • Upgrade Flow & Timelock
      • Configuration Guard Rails
      • Registries as Boundaries
      • Error & Event Catalogue
    • Developer Workflows
      • Deploying a New Vault
      • Extend with New Facets
      • Indexer Integration
    • Reference & Glossary
      • Event Index
      • Capabilities
      • Terms & Abbreviations
      • Contracts
  • MORE Markets
    • Markets Framework
      • Liquidity Protocol
      • Supply
      • Borrow
      • Repay
      • Withdraw
      • Liquidations
      • Flash Loans
      • Risks
    • Markets
      • Liquidity Pool
      • Reserve
      • Incentives
      • Oracles
    • Contracts
    • Build
  • Resources
    • Code, Licenses & Audits
    • Brand Assets
  • Privacy Policy
  • Terms of Use
Powered by GitBook
On this page
  • What Multicall Does
  • Why It Matters for MORE Vaults
  • Built-in Guard Rails
  1. MORE Vaults
  2. Connectors

Multicall

The Multicall facet gives a MORE Vault the power to bundle multiple operations (e.g. add liquidity, borrow, swap, rebalance leverage, etc.) atomically — into a single transaction transaction, yet still give depositors or the guardian time to inspect the strategy update before it hits the chain.


What Multicall Does

Step
Purpose inside a vault

Submit (submitActions)

A manager posts an ordered list of encoded function calls. The facet timestamps it and returns a new nonce that uniquely identifies the batch.

Pending period

Until the optional vault-wide timelock expires, anyone can read the batch with getPendingActions to see exactly what will run, and when.

Execute (executeActions)

After the timelock expires, the same (or another) the execution is triggered. The facet loops through every payload with delegatecall. If any one reverts, the whole bundle rolls back, leaving the vault unchanged.

Veto (vetoActions)

A guardian can delete the batch before execution, acting as an emergency brake without pausing the vault.

All three public functions emit events: ActionsSubmitted, ActionsExecuted, ActionsVetoed so dashboards can track progress without decoding storage.


Why It Matters for MORE Vaults

  • Atomic strategy shifts: Complex moves (e.g. migrate LP, repay debt, swap rewards) settle in one state transition, so the vault never sits half-rebalanced.

  • Predictable risk window: The timelock guarantees a fixed period, set at the registry level, for depositors or automated monitors to react.

  • Cleaner gas profile: Batching cuts signer interactions to a minimum, reducing gas and coordination overhead for multi-sig operators.

  • Transparent audit trail: Because the calldata is published at submission, anyone can replay the proposed calls against a fork to verify outcomes before they go live.


Built-in Guard Rails

  • Role gating: Only addresses with the vault’s manager role can submit or execute; only guardians can veto.

  • Re-entrancy shield: Execution runs under ReentrancyGuard, so an external call in step N can’t re-enter and tamper with step N + 1.

  • Error bubbling: If any payload fails, MulticallFailed(index, reason) surfaces the revert data and rolls back the entire batch so partial state is impossible.

PreviousExternal InterfacesNextSecurity & Governance

Last updated 15 days ago