Metric
Metric is a DEX that introduces the active pool standard, instead of having liquidity sit at fixed prices like passive pools, its liquidity follows an asset's real price wherever it actually trades. A major on a CEX, a stock on the NYSE, even another pool, so a fraction of the capital does the same work. Pools are programmable, with extensions like stop-loss running natively on the liquidity, and anyone can deploy pools or provide liquidity to earn yield. Built to bring real-world assets onchain and make professional market-making a public good.
Details
Scope
On what chains are the smart contracts going to be deployed?
Ethereum, Base, HyperEVM
If you are integrating tokens, are you allowing only whitelisted tokens to work with the codebase or any complying with the standard? Are they assumed to have certain properties, e.g. be non-reentrant? Are there any types of weird tokens you want to integrate?
Any standard ERC-20 — no token whitelist at the contract level. Pool creation is permissionless for any token0 < token1 pair. Curation is at the pool level (classification tiers + optional per-pool address allowlist extensions), not a token allowlist.
Standard: ERC-20 only. USDC and USDT should be considered in scope. If the users create a pool with non-standard ERC20 tokens, the issues related to these are out of scope
Are there any limitations on values set by admins (or other roles) in the codebase, including restrictions on array lengths?
Factory Owner — trusted. Sets protocol fee defaults and fee caps, poolDeployer (once), protocol-level pause, treasury sweeps.
Pool Admin — semi-trusted, bounded. Sets admin fees (capped), proposes PP changes (timelock-gated), pauses own pool (level 1), configures bin/extension params. Cannot exceed caps or bypass timelocks. If they can exceed caps or bypass timelocks and it leads to Medium or higher severity issue, then it can be valid. Pools are expected to be set up correctly and non maliciously (by both the pool creator and the Pool admin), without abnormal values, and users are expected to apply due diligence when deciding whether they want to deposit in the pool or not. The finding can be valid only if the Pool admin can bypass the caps or honestly configured timelocks and it qualifies for Medium or higher severity.
Oracle ADMIN_ROLE (providers/OracleBase) — trusted. Blacklist, integrators, approved factories, registration fee, withdrawEth.
PriceProvider / AnchoredProvider factory (AccessControl) — trusted, but provider params are bounded (below).
Are there any limitations on values set by admins (or other roles) in protocols you integrate with, including restrictions on array lengths?
No — we trust the governance of the protocols we integrate with and impose no limitations on their admin-set values
Is the codebase expected to comply with any specific EIPs?
A few examples used within codebase:
ERC-20 — all pool tokens, fees, and transfers (via SafeERC20). Intention: standard token compatibility. Alignment: the protocol trades arbitrary ERC-20 pairs (majors/RWAs). Note: LP positions are NOT tokenized — they're internal salt/share accounting, so the pool itself isn't an ERC-20/721.
EIP-2612 + EIP-712 (Permit) — the router exposes selfPermit / selfPermitAllowed (DAI-style) / selfPermitIfNecessary. Intention: gasless / single-transaction approvals (permit + swap batched via multicall). Alignment: better UX for wallets/aggregators (a core flow-partner audience), no separate approve tx.
EIP-1153 (transient storage) — the pool's transient reentrancy guard (MetricReentrancyGuardTransient) and transient swap/callback context. Intention: cheap per-tx reentrancy protection + callback routing without persistent storage. Alignment: gas efficiency and safety on the swap-callback path; requires Cancun+ (foundry evm_version = prague).
EIP-1014 (CREATE2) → CREATE3 deployment — the router (and the deterministic deploy) use CREATE3. Intention: identical contract addresses across chains. Alignment: one address set for ETH + Base (confirmed in the live deployment), simplifying multi-chain integration.
Issues related to EIP violations can be considered valid if they lead to Medium or higher impact and qualify for Medium or higher severity definition.
Are there any off-chain mechanisms involved in the protocol (e.g., keeper bots, arbitrage bots, etc.)? We assume these mechanisms will not misbehave, delay, or go offline unless otherwise specified.
Price updates in many cases can happen off-chain and get sent to the oracle. Especially for compressed oracles. It's considered that these price updates and oracles will always be correct, and not stale.
What properties/invariants do you want to hold even if breaking them has a low/unknown impact?
Solvency: pool token balances always cover all LP claims + owed fees; every LP can withdraw their proportional share. Withdraw (remove-liquidity) must work even when the pool is paused (pause only blocks swaps).
Swap conservation: exact settlement — the pool receives the owed input (else IncorrectDelta revert) and never creates/leaks value; a trader never receives more than the bin curve allows.
Quote sanity: bid > 0 and bid < ask always (hard invariant; BidIsZero / BidGreaterThanAsk).
Anchored band: every AnchoredPriceProvider quote — including source mode — stays within mid ± (u + floor); an unreviewed source can never push price outside the band.
No trade on bad oracle: swaps revert on stale price (maxTimeDelta/maxRefStaleness), excessive Chainlink deviation, or (L2) sequencer down.
Issues related to Invariant violations can be considered valid if they lead to Medium or higher impact and qualify for Medium or higher severity definition.
Please discuss any design choices you made.
Pure oracle-anchored pricing — no internal price discovery. Price follows the oracle, not reserves; there's no DEX cross-check (the only sanity guard is the Chainlink deviation check). Trade-off: manipulation risk shifts entirely to the oracle/price-provider layer; mitigated by the deviation guard, staleness checks, and the per-swap drift cap. If those guards are mis-tuned, bad-price execution is possible.
Rounding always favors the pool. Fees/baseFee/band edges use ceil; share math rounds against the user. Deliberate (no dust drain on the pool), but creates intentional rounding asymmetry — worth checking it can't be amplified. If rounding is not in favour of the protocol and qualifies for Medium or higher severity impact, it can be considered a valid issue.
Anchored band clipping: AnchoredPriceProvider lets a curator supply arbitrary bid/ask but clips it into mid ± (u + floor). Deliberate: "the band bounds how wrong a source can be." The band math (floor/uMax, ceil rounding) is the entire safety boundary — an error there is the high-impact case. If the band math is incorrect and can lead to Medium or higher severity impact, it can be considered a valid issue.
Please provide links to previous audits (if any) and all the known issues or acceptable risks.
- https://ams3.digitaloceanspaces.com/sherlock-files/additional_resources/Metric%20OMM%20-%20Zellic%20Audit%20Report%20Draft.pdf
- https://ams3.digitaloceanspaces.com/sherlock-files/additional_resources/contest-known-issues.pdf
- https://ams3.digitaloceanspaces.com/sherlock-files/additional_resources/2026-07-06_Metric-Collaborative_Audit_Report.pdf
Please list any relevant protocol resources.
Additional audit information.
This contest will use the following severity definitions:
Critical severity:
Direct loss of funds without limitations of external conditions, and the issue can be exploited at any moment. The loss of the affected party must exceed 20% and 100 USD. This excludes loss of to-be-claimed yield/rewards by users.
Examples:
- Users lose more than 20% and more than $100 of their principal.
- The protocol loses more than 20% and more than $100 of the fees.
High severity:
Direct loss of funds without (extensive) limitations of external conditions. The loss of the affected party must exceed 1% and 10 USD.
Causes a loss of to-be-claimed yield/rewards exceeding 20% and 100 USD of lost rewards of the affected party.
Examples:
- Users lose more than 1% and more than $10 of their principal.
- Users lose more than 20% and more than $100 of their yield/rewards.
- The protocol loses more than 1% and more than $10 of the fees.
Medium severity:
Causes a loss of funds but requires certain external conditions or specific states, or a loss is highly constrained. The loss of the affected part must exceed 0.01% and 10 USD.
Causes a loss of to-be-claimed yield/rewards exceeding 1% and 10 USD of lost rewards of the affected party.
Breaks core contract functionality, rendering the contract useless or leading to loss of funds of the affected party that exceeds 0.01% and 10 USD.
Note: If a single attack can cause a 0.01% loss but can be replayed indefinitely, it may be considered a 100% loss and can be medium or high, depending on the constraints.
Examples:
- Users lose more than 0.01% and more than $10 of their principal.
- Users lose more than 1% and more than $10 of their yield/rewards.
- The protocol loses more than 0.01% and more than $10 of the fees.
Severity weights:
- Critical - 10 points
- High - 5 points
- Medium - 1 points
Total Rewards
Contest Pool
Lead Senior Watson
Lead Judge
121,000 USDC
21,000 USDC
8,000 USDC
Status
Scope
Start Time
End Time
Judging Rules
