Claims vs. reality

29 contracts exist on-chain (26 deployed by the deployer + 3 created dynamically at runtime). The 57 figure likely counts all Solidity source files including interfaces, libraries, and abstract contracts — a common way to measure codebase scope. For a protocol this complex, 57 .sol files is plausible.

Deployer nonce analysis: 47 nonces, 26 contract creations, 3 dynamic

Not publicly verifiable. No source code repository is linked from the website, and no Meridian smart contract repo exists on the founder's GitHub profile or under any discoverable org. Build Games Stage 2 required a GitHub submission, so judges likely had access — but the repo appears to be private. These claims may be accurate but cannot be independently confirmed.

GitHub search: brookejlacey profile, meridian-protocol org (different project), keyword search — no matching repo found

The frontend at app.meridianprotocol.xyz redirects to /waitlist with "Access is currently invite-only." The contracts themselves are on a public testnet and can be called directly. The team may be doing a staged rollout — finals were March 27, four days before this audit.

Direct navigation to app.meridianprotocol.xyz on March 31, 2026

Both CDS contracts use a fixed premium rate of 250 basis points (2.5%) per year, set at creation time. No AMM contract, no bonding curve math, and no dynamic pricing logic found in decompiled bytecode (CDSRegistry is not verified on Snowscan). Notably, Avalanche's own winner announcement tweet also describes 'credit default swaps with AMM pricing.'

CDSRegistry + CDS #0/#1 decompiled bytecode and on-chain storage reads; @avax winner tweet March 31, 2026

Custom Messenger contract (2,053 bytes) implements ITeleporterReceiver but is NOT the standard Avalanche Teleporter. messageCount=0, pendingCount=0. Hub and Spoke are both on Fuji 43113 — a same-chain loopback test configuration. Deploying to a second chain in a 6-week hackathon may not have been feasible.

Messenger.messageCount()=0, constructor chainId=43113 on both contracts

The Pool contract uses ERC4626-like share math (convertToShares, convertToAssets) but does NOT implement the full ERC4626 interface — missing key functions like maxDeposit, maxWithdraw, previewDeposit, previewWithdraw. May be ERC4626-inspired rather than compliant.

Pool decompiled bytecode function analysis vs ERC4626 spec

Governance and Reporting contracts are deployed with well-designed AI agent timelocks and rate limits. The AI agent contracts (AIKeeper, AICreditEventDetector, AIStrategyOptimizer) and StrategyRouter have verified source on Snowscan confirming the architecture. However: zero AI proposals submitted, zero credit events detected, zero governance votes cast. The on-chain infrastructure exists but has not been exercised.

AI agent verified source on Snowscan + Governance, Reporting, StrategyRouter event logs: empty

No contract named HedgeRouter or matching its described functionality was found among the deployed contracts. It may exist in the source code but was not deployed to Fuji testnet during the Build Games window.

Full deployer contract inventory, function selector scan

ForgeVault holds 206K MockUSDC with 200K SR-01 and 6K EQ-01 minted — real tranche investments exist. However, the actual testnet TVL ($206K) is far below the $1.7M shown in the mockup. The specific breakdown ($1.0M/$500K/$200K) does not match on-chain state. The numbers shown are illustrative, not live data.

balanceOf() and totalSupply() calls on MockUSDC, SR-01, MZ-01, EQ-01

The waterfall architecture IS correctly implemented in bytecode. The 70/20/10 allocation, priority-of-payments logic, and Synthetix-style reward accumulator are all present and well-engineered. This claim is accurate at the code level.

TrancheVault + ForgeVault decompiled bytecode and Tenderly traces