Skip to main content

Monitoring & Automation

Current Phase: Shadow Mainnet Testing

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 describes how the Multyr system is actively monitored and maintained in operation.

Monitoring operates across two distinct layers:

  • Core Layer (vault integrity and user flows)
  • Strategy Layer (allocation and execution)

Automation is primarily handled via Chainlink Automation, with permissionless fallbacks.

Automation Model​

Keeper Infrastructure​

Multyr uses Chainlink Automation as its execution layer.

The system is composed of four independent upkeep contracts:

  • VaultUpkeep — core vault operations
  • LendingStrategyUpkeep — strategy monitoring and rebalancing
  • FeeCollectorUpkeep — fee distribution (collection phase)
  • PeripheryUpkeepAdapter — fee distribution pipeline (split, redeem, fund)

All automation is:

  • fully on-chain
  • deterministic
  • designed to be safe-idempotent

No external bots or off-chain execution layers are required.

Permission Model​

Most critical functions are permissionless, including:

  • queue settlement
  • exit reconciliation
  • fee processing
  • strategy deployment and realization
  • strategy rebalancing

Only buffer-level rebalancing is restricted to authorized keepers.

→ This ensures that the system can continue operating even if automation fails.

Failure Resilience​

If Chainlink Automation is unavailable:

  • all core functions can be executed manually
  • third parties or users may trigger operations
  • the system degrades operationally but does not halt

Keeper Execution Flow​

Automation runs continuously (~15–60 seconds cycle) and prioritizes operations as follows:

Priority 1 — User-critical operations

  • queue settlement
  • exit realization
  • queue reconciliation

Priority 2 — Accounting

  • performance fee crystallization

Priority 3 — Capital management

  • buffer rebalancing
  • strategy rebalancing

Priority 4 — Capital deployment

  • deploy idle funds
  • realize funds when buffers are low

Operations are executed only when their conditions are met.

Fee Distribution Pipeline​

Protocol fees are processed through a multi-step automated pipeline.

Flow Overview​

FeeCollector → OpsCollector → FeeDistributor → EpochPayout

Execution is split across two independent automation layers.

Phase 1 — Fee Collection​

Handled by FeeCollectorUpkeep:

  • runs on a time-based interval (~3 days by default)
  • calls distribute(token) on the FeeCollector
  • transfers accumulated shares to downstream contracts

If not executed:

→ fees accumulate but are not lost

Phase 2 — Periphery Execution​

Handled by PeripheryUpkeepAdapter.

This contract is:

  • fully permissionless
  • stateless
  • condition-driven

It executes three operations in fixed priority order:

1. SPLIT​

  • distributes shares from OpsCollector to recipients
  • triggered when share balance > 0

2. REDEEM​

  • converts vault shares into underlying assets (e.g. USDC)
  • subject to:
    • per-epoch caps
    • cooldowns
    • pause controls

3. FUND​

  • transfers assets into the EpochPayout contract
  • enables user reward claims

Safe-Idempotent Execution​

All operations follow a strict pattern:

  • conditions are re-checked at execution
  • stale or invalid states result in silent return
  • no reverts or execution loops

This ensures:

  • robustness under changing conditions
  • compatibility with Chainlink execution model

Failure Behavior​

If the periphery layer is not executed:

  • rewards are delayed
  • funds remain in intermediate contracts
  • no loss of funds occurs

The pipeline resumes automatically once conditions are met.

Core Layer Monitoring​

The Core Layer ensures system integrity and user fund accessibility.

Monitored Components​

  • withdrawal queue state
  • hot buffer liquidity
  • warm NAV freshness
  • oracle validity
  • epoch progression
  • high-water mark updates

Behavior Under Stale Conditions​

  • stale NAV → deposits are blocked
  • stale oracle → deposits blocked, withdrawals allowed
  • queue backlog → withdrawals delayed but not blocked

The system prioritizes:

→ correctness for deposits → liveness for withdrawals

Strategy Layer Monitoring​

The Strategy Layer evaluates execution quality and allocation efficiency.

Monitored Metrics​

  • adapter APY
  • liquidity availability
  • stability (EMA-based)
  • external TVL
  • risk score
  • adapter failure rate

Data Freshness​

Strategy inputs are periodically updated via keeper calls:

  • liquidity and stability → ~1–2× per day
  • external TVL → ~24h
  • APY → live on-demand during scoring

If data becomes stale:

  • the system uses conservative default values
  • allocation remains functional but less optimal

Rebalancing Automation​

Rebalancing is triggered via Chainlink Automation when conditions are met.

Trigger Conditions​

Rebalancing requires:

  • no active plan
  • cooldown elapsed (~6h default)
  • sufficient number of active adapters
  • minimum movement thresholds
  • positive net benefit after costs

Benefit vs Cost Gate​

Rebalancing only occurs if:

  • expected yield improvement exceeds execution costs
  • net benefit passes a minimum threshold

This prevents unnecessary churn.

Execution Model​

Rebalancing occurs in two phases:

  1. Plan creation

    • compute target allocation
    • generate action list

  2. Step execution

    • execute actions incrementally
    • bounded gas per transaction

Plans expire automatically if not executed in time.

Oracle Monitoring​

Multyr relies on Chainlink price feeds, accessed on-demand.

Validation Mechanisms​

  • staleness checks (min/max bounds)
  • optional secondary oracle validation
  • deviation thresholds

Failure Handling​

ConditionDepositsWithdrawalsStrategy Ops
Primary staleBlockedAllowedBlocked
Secondary downAllowedAllowedAllowed
Both staleBlockedAllowedBlocked
Deviation exceededBlockedAllowedBlocked

Warm NAV Constraint​

Warm NAV acts as a secondary pricing layer:

  • must be refreshed within ~15 minutes
  • stale NAV blocks deposits
  • withdrawals are never blocked

Refresh is permissionless.

Alerting & Observability​

Monitoring includes off-chain observability systems.

Core Alerts​

  • NAV / share price anomalies
  • buffer depletion
  • oracle staleness
  • queue backlog
  • system pause state

Strategy Alerts​

  • adapter failure / quarantine
  • allocation drift
  • abnormal yield behavior
  • loss cap breaches

Alert Severity​

  • P0 — critical (immediate response)
  • P1 — high priority
  • P2 — operational
  • P3 — informational

Example: Strategy Failure​

Strategy Layer​

  • adapter failures detected
  • adapter quarantined
  • score reduced
  • excluded from allocation

Core Layer​

  • withdrawals continue via alternative liquidity paths
  • queue processing continues
  • accounting remains consistent

Result​

The system continues operating even if a strategy fails.

Summary​

Monitoring and automation in Multyr combine:

  • Chainlink-based execution across four independent upkeeps
  • permissionless fallback for all critical operations
  • dual-layer monitoring (core + strategy)
  • deterministic fee processing pipeline
  • safe-idempotent execution patterns

The system is designed to:

→ remain operational under degraded conditions → preserve capital integrity → ensure that all value flows are eventually processed