Summary
LlamaRisk supports the expansion of Chainlink’s SVR system to Aave v3 deployments on Avalanche, Polygon, and BNB Chain. The proposal would activate SVR feeds for 15 assets on Avalanche, 12 assets on Polygon, and 8 assets on BNB. This expansion would be enabled by Chainlink’s Atlas auction infrastructure for EVM chains, with a recommended 10-second fallback delay set.
Since our previous analysis related to the Base and Arbitrum expansions, cumulative results have increased, with headline figures including ~$887 million in liquidations via SVR, ~$22 million in recaptures, and 6768 SVR liquidation events across 5 markets.
Given the expansion consists of EVM chains, we support the utilization of the same Atlas-based auction infrastructure deployed on Base and Arbitrum. Additionally, we support the proposed assets on each chain with no material risk considerations outside of what we have observed.
1. State of SVR
1.1 Financial Performance
Based on data from our SVR monitoring dashboard at svr.llamarisk.com, the system has produced the following aggregate outcomes to date (July 2026):
-
Cumulative liquidation volume processed via SVR: ~$887 million
-
Total OEV recaptured: ~$22 million
-
Number of SVR liquidation events: 6775 transactions
-
Average recapture rate: 52.81% of maximum available OEV (from bonuses of $41.1M)
This represents an expanded scope of 5 markets including Core, Prime, Base, Arbitrum, and Monad. Revenue from recaptured OEV is distributed as follows: Aave has received approximately $14.1 million and Chainlink approximately $7.6 million from SVR since inception.
Source: LlamaRisk SVR Dashboard, July 24, 2026
The recapture rate has remained relatively unchanged, while the searcher pool has grown to 245 unique addresses, compared with our initial analysis, which identified 93 unique searchers. This implies that the SVR system is now fully integrated within searchers on the established chains and that the auction competition is healthy. In turn, this implies elevated recapture rates for smaller-sized liquidations.
Source: LlamaRisk SVR Dashboard, July 24, 2026
1.2 Stress Event Performance
The most recent notable liquidation stress episode was in early June, when heightened price volatility lead to liquidations of BTC and ETH backed positions. This generated around $4M in recaptured value and was one of the 3 largest recapture periods. It is notable that major positions were liquidated at that time and some of the liquidations sized at $5M or more were not routed through SVR.
Source: LlamaRisk SVR Dashboard, July 24, 2026
1.3 Coverage Scope
The proposed SVR feeds for the respective markets include:
-
Avalanche SVRs would cover over 90% of market TVL excluding GHO, sUSDe, MAI, and rsETH.
-
Polygon SVRs would cover all assets excluding GHST and frozen assets, representing over 95% of the market’s TVL.
-
BNB SVRs would cover the entire chain’s TVL, with no exceptions.
We support the proposed assets to be SVR-enabled in each market.
2. Liquidation Auction Infrastructure
2.1 Atlas on Avalanche, BNB, and Polygon
Given that Flashbots MEV-Share is primarily deployed on Ethereum Mainnet and that block production on the proposed chains is determined via validator rotation or is stake-weighted, expanding SVR liquidations to Avalanche, Polygon, and BNB Chain requires an alternative auction system. As EVM-compatible chains, Chainlink’s Atlas can be leveraged as the underlying auction infrastructure, mirroring the setup implemented on Base and Arbitrum.
For context, Atlas determines auction winning bids by executing solvers sequentially until one succeeds, rather than via offchain simulation. Chainlink’s DON bundles the oracle price update and ranked solver bids into a single transaction it submits directly, so the update and winning liquidation land atomically together. It is effectively agnostic to how blocks are produced, with the oracle update and the liquidation transactions bundled into a single atomic EVM transaction.
2.2 How Atlas Works
The flow of an Atlas SVR auction on the proposed chains proceeds as follows. When a Chainlink DON node determines that a price update must go onchain (triggered by either a deviation threshold or heartbeat), it delivers the price report to Fastlane’s Operations Relay, which submits the auction. Solvers (liquidators) monitor the relay for new opportunities, analyze the available OEV, and submit signed solver operations with associated bids. The relay collects these bids, orders them by bid amount, and selects the top bids for inclusion. A Chainlink DON node acting as the bundler then assembles a single Atlas transaction containing both the oracle update and the ranked solver operations, and submits that transaction directly to the public mempool (or the sequencer for chains that utilise them).
The Atlas contract executes the solver operations in bid order. Each solver gets a chance to execute its liquidation andif it fails to pay the stated bid within its allocated gas, its operations are reverted, and the next solver is tried. The first solver to succeed pays its bid, and the transaction completes. Because the Chainlink node itself submits the transaction, the sequencing of the oracle update and the liquidation cannot be disrupted by a third-party RPC or sequencer reordering.
An important property of this design is that the atomicity of the Atlas transaction, combined with the DON node sending it directly, provides an ordering guarantee that does not depend on any private mempool infrastructure. The oracle update and the winning liquidation are either included together or omitted entirely.
2.3 Gas Accounting and Solver Requirements
On Atlas, solvers must bond the chain’s native token (e.g., BNB on BNB Chain) in advance to cover the gas consumed by their solver operations. This bonded balance, denominated in atlETH, is used to repay the Chainlink node that fronted the gas cost for the full transaction.
If a solver’s operation is executed and succeeds, it pays the gas cost of its own operation plus a share of the overall transaction gas. If its operation is executed and fails, it pays only the gas cost of its own failed operation. If it is not executed at all, it pays nothing. This structure ensures that failed competitors do not impose undue gas costs on the winning solver, and that the Chainlink node is made whole regardless of outcome. The only requirement for auction participation is bonding enough native token to cover one transaction’s worth of gas, there is no capital requirement tied to bid size or protocol behavior.
2.4 Fallback and Continuity
The fallback mechanism for Atlas-based SVR is identical in design to the Ethereum implementation. A time-based parameter (s_cutoffTime) determines how long the system waits for an SVR auction to settle before falling back to the standard on-chain price feed update through the public mempool or sequencer queue.
The current fallback delays (CutoffTimeSet) for Aave SVR feeds vary by chain, with Ethereum set to 60 seconds, Arbitrum, Monad, and Base to 30 seconds, and 10 seconds on BNB Chain. We recommend setting the delay to 10 seconds for the proposed chains. Lower delay would represent lower risks due to price feed update delays and minimal adverse effect on the inclusion rate given the Atlas design.
The requireFulfillment parameter is set to true, meaning that if all solver operations fail and no liquidation takes place after an oracle update, the price report reverts rather than being delivered without a corresponding liquidation capture. In such a case, the price update is pushed through a fallback feed as the fallback window expires.
2.5 Immutability and Audit Status
The Atlas contracts are deployed as immutable, publicly accessible contracts and have undergone multiple independent audits (Certora, Cantina, Spearbit). The onchain settlement model has the additional property that its behavior is fully inspectable: any observer can reconstruct exactly which bids were submitted, in what order they were tried, and which one succeeded. This is a meaningful transparency improvement relative to the offchain simulation-based model used on Ethereum, where the selection process happens inside private builder infrastructure.
2.6 SVROracleSteward
As with all previous SVR activations, this expansion includes the deployment of SVROracleStewards for each new feed. The steward contract gives the Aave Protocol Guardian the ability to revert any individual SVR feed to the standard (non-SVR) Chainlink price feed at any time without a governance vote. This provides a direct circuit breaker in the event of a critical failure or unexpected behavior in any specific feed. Its scope is deliberately narrow: it can only replace an SVR feed with the feed that was already in production, not with any arbitrary oracle, so it does not introduce new oracle risk.
3. Risk Considerations
3.1 Searcher Pool Depth
As with the Base and Arbitrum deployments, the early-stage depth of the SVR searcher pool on Avalanche and Polygon could potentially impact bidding logic and competition, and translate into lower recapture rates during their initial phases. SVR feeds are yet to be deployed on these chains, with BNB representing the only chain that has an established set of SVR feeds.
Recommendations
We support deploying the proposed markets and SVR asset/feed coverage. In addition, we recommend setting the fallback delay s_cutoffTime to 10 seconds for the SVR setup of the proposed chains.
Disclaimer
This review was independently prepared by LlamaRisk, a DeFi risk service provider funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.