Bizantine Labs Docs

Technology & Infrastructure

Monitoring, dependency mapping, smart contract upgradeability, and disaster recovery for bizUSDT0.

Technology & Infrastructure

This document covers the technical infrastructure supporting bizUSDT0: monitoring systems, dependency mapping, smart contract upgradeability, incident response procedures, and disaster recovery.


Monitoring Dashboard

Real-Time Monitoring

The vault's operational state is monitored in real-time, covering:

  • TVL and reserve ratio (updated per block)
  • Sleeve allocation (Mystic Core USDT0 V2 balance vs target)
  • WFLR accumulation (pending harvest balance in USDT0 equivalent)
  • Mystic utilization rate (withdrawal queue risk indicator)
  • SparkDEX pool liquidity (WFLR/USDT0 depth at ±25 bps range)
  • FLR price volatility (FTSO oracle feed, hourly and daily)

Alert Routing

  • Alerts are routed to the operations team via encrypted messaging (primary channel) and email (secondary channel).
  • SEV0 alerts trigger immediate phone/page notification to the primary manager.
  • SEV1 alerts trigger notification within 15 minutes.
  • SEV2/SEV3 alerts are queued for the next business day review.

Allocator Access

Status: Read-only access to the monitoring dashboard for allocators is planned. A URL and access credentials will be provided upon request once the system is deployed.


Dependency Map

DependencyTypeFailure ModeImpact on VaultMitigation
SuperformVault platformContract exploit, platform downtime, governance changesDeposits and redemptions halted; existing Mystic position unaffectedMonitor Superform governance proposals; maintain emergency withdrawal path
Mystic Core USDT0 V2Yield sourceSmart contract exploit, utilization spike, governance pauseSleeve funds at risk (up to 92% of TVL); yield generation stopsMonitor utilization and audit status; 8% reserve provides partial buffer
SparkDEX V4DEX / reward conversionPool drained, router exploit, liquidity migrationWFLR harvest paused; FLR exposure drifts above policy bandMonitor pool TVL; maintain alternative OTC conversion path as backup
USDT0 (LayerZero OFT)Deposit assetDepeg on Flare, bridge failure, contract exploitAll vault operations and NAV impactedMonitor USDT0 peg on Flare vs other chains; no cross-chain exposure beyond OFT
FordefiCustody / key managementPlatform outage, MPC failure, key compromiseVault operations halted until custody is restored3-of-5 quorum provides redundancy; secondary managers have independent keys
Flare FTSO OraclesPrice feedsOracle manipulation, stale prices, downtimeSlippage calculations degraded; harvest may execute at unfavorable prices25 bps slippage cap provides hard stop; volatility circuit breaker halts swaps during price anomalies

Smart Contract Upgradeability

Superform Vault Contract

  • The bizUSDT0 vault is deployed through Superform's factory system.
  • Upgradeability Status: Pending documentation. If the vault uses a proxy pattern (e.g., UUPS or Transparent Proxy), the admin/governance key that controls upgrades must be identified.
  • Governance Process: Any upgrade to the vault contract would be subject to Superform's governance process (timelock, community review, etc.).

Mystic Core USDT0 V2

  • Standard: ERC-4626 tokenized vault.
  • Upgradeability Status: Pending documentation. The Mystic vault's upgradeability (or immutability) should be verified.
  • Immutability Preference: If the Mystic vault is immutable, smart contract risk is limited to the initial deployment. If upgradeable, the governance/admin key represents an additional trust assumption.

Bizantine Position

  • Bizantine does not have the ability to unilaterally modify the Superform vault contract or the Mystic Core USDT0 V2 contract.

Monitoring Rules

The following rules are enforced by the monitoring system with automated alerting:

MetricThresholdAlert LevelAction
Sleeve Allocation Drift±1 percentage point from targetSEV2Trigger rebalance
Reserve LevelBelow 7% or above 9% of TVLSEV1Immediate rebalance
Harvest ExecutionLast harvest more than 4 days agoSEV1Investigate and execute harvest
Swap SlippageAny swap exceeding 20 bps (within 25 bps cap)SEV2Log and review
Swap SlippageAny swap aborted at 25 bps capSEV1Investigate SparkDEX pool conditions
FLR ExposureWFLR value exceeds 3% of NAVSEV1Trigger immediate harvest
FLR ExposureWFLR value exceeds 5% of NAVSEV0Emergency harvest regardless of market conditions
FLR Volatility≥10% price move within 1 hourSEV1Pause harvest swaps
Mystic UtilizationAbove 85%SEV2Monitor withdrawal queue
Mystic UtilizationAbove 92%SEV1Consider increasing reserve target
TVL Cap ProximityTVL exceeds 95% of $25M capSEV3Notify operations team
Unauthorized ActionAny transaction from vault not in authorized action setSEV0Immediate investigation and escalation

Incident Response

SEV0 Triggers

  • Loss of funds (any amount)
  • Unauthorized transaction from vault
  • FLR exposure exceeding 5% of NAV
  • All operator keys compromised or unavailable
  • Mystic Core USDT0 V2 contract exploit suspected

15-Minute Playbook

TimeAction
T+0SEV0 alert received by on-call operator
T+2 minAcknowledge alert; assess severity and scope
T+5 minIf funds are at risk: initiate emergency withdrawal from Mystic to reserve (if possible)
T+10 minNotify primary manager via Fordefi; request authorization for emergency action
T+15 minExecute emergency action (withdraw, pause operations, or escalate to Superform team)
T+30 minPost initial incident report to allocator communication channel
T+2 hoursPost detailed incident report with timeline, root cause analysis (preliminary), and remediation plan

Escalation Path

  1. On-call operator (first responder)
  2. Primary manager (Fordefi MPC - can authorize any vault action)
  3. Secondary managers (can execute emergency operations)
  4. Superform governance (if vault-level response is insufficient)

Disaster Recovery

Operator Unavailability Fallback

ScenarioResponse
Primary manager unavailable (Fordefi MPC)Secondary manager executes operations using individual key
All operators unavailable for 24 hoursVault enters auto-pilot: no rebalancing, no harvesting, deposits and redemptions continue per smart contract logic
All operators unavailable for 7+ daysDepositors may coordinate with Superform governance for emergency fund recovery

Fordefi Disaster Recovery

  • Fordefi maintains encrypted key share backups with geographic distribution.
  • Full key recovery is possible within 24 hours in the event of hardware failure.
  • Fordefi's disaster recovery procedures are documented in their platform documentation and tested quarterly.

Key Rotation Procedures

  1. Scheduled Rotation: Annual rotation of secondary manager keys, or upon personnel changes.
  2. Emergency Rotation: Initiated immediately if any key is suspected of being compromised.
  3. Process: Primary manager initiates rotation through Fordefi dashboard; requires 3-of-5 approval.
  4. Communication: All rotation events are logged on-chain and communicated to allocators within 24 hours.

Evidence Pack

The following artifacts are available for allocator and auditor review upon request:

Owner Roster

  • Full list of vault operator addresses with role descriptions (documented in the strategy specification).

Allowlists

  • Authorized sleeve addresses (Mystic Core USDT0 V2 only)
  • Authorized swap path (WFLR → USDT0 via SparkDEX V4 only)
  • Authorized router and pool addresses

Policy Snapshots

  • Current reserve target: 8%
  • Current TVL cap: $25M USDT0
  • Current fee structure: 0% management, 10% performance (HWM)
  • Current harvest triggers: 3 days / $500 USDT0
  • Current FLR exposure policy: 2-3% of NAV

Monitoring Coverage

  • All metrics and thresholds listed in the Monitoring Rules section are actively enforced.
  • Historical alert logs are retained for 12 months.

On this page