01 — Architecture
What's actually there
Meridian deploys six interconnected subsystems. The architecture is genuinely sophisticated — this is not a simple lending protocol clone. But several subsystems are dormant or incomplete.
Six subsystems, three tiers of readiness
We classify each subsystem by its on-chain status: Active means real transactions and state changes exist. Dormant means deployed but never exercised beyond setup. Stub means deployed with zero meaningful state.
Core Credit Engine
Pool, PoolFactory, TrancheVault, ForgeVault, Tranche Tokens (SR-01, MZ-01, EQ-01)
The heart of the protocol. A Pool contract manages deposits/withdrawals with ERC4626-like share accounting. TrancheVault orchestrates a 3-tranche waterfall (70/20/10 Senior/Mezz/Equity). ForgeVault holds the USDC and distributes yield using a Synthetix-style accumulator pattern.
One Position created (0x836e1a9e). Pool has non-zero state. ForgeVault holds 206K MockUSDC with 200K SR-01 and 6K EQ-01 minted to test user 0x1e3f. Waterfall math is correctly implemented. The core invest flow has been exercised.
CDS & Flash Loans
CDSRegistry, CDS #0, CDS #1, FlashLender, FlashBorrower
CDSRegistry is a factory that deploys standalone CDS contracts via CREATE. Each CDS has a full lifecycle: fund → buyProtection → payPremium → settle/expire. Flash loans allow atomic arbitrage between pool positions.
CDS #0 is genuinely active: 13 transactions including 9 premium payments. CDS #1 is funded but has no buyer. However: premium rate is a fixed 250 bps — no AMM, no bonding curve, no dynamic pricing despite the marketing claim.
Collateral & Liquidation
VaultRegistry (Hub), CollateralManager (Spoke), Liquidator, AccountMonitor
Hub-and-spoke model with VaultRegistry as the hub. 110% collateral ratio, 5% liquidation penalty. AccountMonitor tracks and ranks accounts by priority for liquidation.
One account created by test user 0x1e3f. Zero deposits, zero liquidations. The liquidation waterfall has never been exercised. AccountMonitor has never flagged an account.
Cross-Chain Messaging
Messenger, CrossChainParams
Custom Teleporter-compatible messenger (implements ITeleporterReceiver but is NOT the standard Avalanche Teleporter). Designed for hub-spoke collateral synchronization with 3-layer message authentication.
Messenger.messageCount() = 0. Zero messages have ever been sent. Hub and spoke are deployed on the same chain (Fuji 43113) — a loopback test configuration, not actual cross-chain deployment. The marketing claim of "cross-chain margin engine via ICM/Teleporter" is significantly overstated.
Governance & AI Agents
StrategyRouter, Governance, Reporting, RiskScorer
StrategyRouter manages investment strategies with open/close/rebalance. Governance handles AI proposal approval/rejection with timelock. Reporting provides AI credit event detection with rate limiting and governance veto.
Three strategies were created during deployment. Zero AI proposals submitted. Zero credit event detections. Zero governance votes. The entire AI monitoring layer — a key marketing differentiator — has never produced a single on-chain action.
Pricing, Oracles & Rewards
AssetRegistry, Oracle/Threshold, Pricer, RewardDistributor, MockUSDC, MRD Token
AssetRegistry tracks supported assets with admin-set prices (no external oracle feed). RewardDistributor uses checkpoint-based MRD token distribution reading Pool share data.
4 assets registered. Oracle thresholds configured. MRD tokens minted to RewardDistributor. MockUSDC has the most activity of any contract (27 Transfer events). Prices are admin-set, not oracle-fed.
The yield waterfall: genuinely well-engineered
Credit where it's due. The tranched yield distribution is the most complete and well-implemented part of the protocol. The math is correct, the reentrancy protections are in place, and the Synthetix-style reward accumulator pattern is gas-efficient.
excess = balanceOf(vault) - totalPoolDeposited yieldPerShare accumulator. _updateYield() called atomically within invest() and withdraw() to prevent dilution attacks.
This is real financial engineering. The waterfall correctly implements priority of payments — Senior gets paid first up to its rate cap, then Mezzanine, then Equity absorbs whatever remains (including losses). The implementation uses O(1) gas per claim regardless of participant count.
26 contracts, not 57
The deployer address 0xD243eB302C08511743B0050cE77c02C80FeccCc8 used 47 nonces. Of these, 26 resulted in contract deployments (the rest were configuration transactions). Additionally, 3 contracts were created dynamically at runtime (1 Position + 2 CDS instances), bringing the verifiable total to 29.
How might Meridian arrive at 57? If we generously count each contract plus its interfaces, libraries, and abstract base contracts as separate entries in their codebase, it's plausible. But "57 smart contracts" as a marketing stat implies 57 deployed, functional contracts — which does not match on-chain reality.
See the full breakdown on the Contract Registry page.