What makes Ekubo different

Ekubo is a next-generation AMM built around what it calls “super-concentrated liquidity.” Its ticks are one-hundredth of a basis point—100 times finer than the convention used by most concentrated-liquidity AMMs. This gives liquidity providers unusually precise control over where their capital is deployed. Pool creators can also choose each pool’s fee and tick spacing instead of selecting from a small set of predefined configurations. Learn more about providing liquidity on Ekubo. (https://docs.ekubo.org/products/liquidity/)

Underneath the markets is a highly optimized singleton Core contract. Every pool settles through the same Core, while flash accounting defers token transfers until the end of an interaction and settles only the net amounts. Ekubo’s extension system can introduce functionality such as TWAMMs, MEV capture, boosted fees, and oracle pools without requiring another copy of the underlying AMM. Read about Ekubo’s architecture. (https://docs.ekubo.org/concepts/architecture/)

That precision and flexibility give LPs more ways to express a market-making strategy—but they also make analytics and position management especially important.

A purpose-built tooling for Ekubo LPs

Concentrated liquidity gives LPs precise control over where their capital works. It also makes good tooling essential: returns depend on the range you choose, how price moves through it, the fees a pool generates, and how actively you manage the position.

Revert brings those decisions into one place. You can compare pools before deploying capital, follow a live position after you enter, and act without leaving the dashboard.

What's live today

Pool discovery. Filter Discover to Ekubo and compare pools using liquidity, volume, fees, fee APR, and liquidity-distribution data.

Position analytics. Track your Ekubo positions with PnL versus HODL, fee APR, divergence loss, current token balances, uncollected fees, and position history.

Create and manage positions. Open a new position, add or withdraw liquidity, collect or compound fees, and change your range directly from Revert.

Built for focused execution

Position actions run through a dedicated EkuboUtils contract on Ethereum. When an action needs to rebalance tokens, the integration uses a 0x-only swap path with tightly scoped approvals. The deployed contract is verified on Etherscan:

0x4Cf798c93280E2103Ae1186B4D4AB7E9CE93df9f

At launch, Revert supports Ekubo's standard concentrated-liquidity pools without extensions on Ethereum mainnet.

Getting started

Connect your wallet at revert.finance, then open Ekubo pools in Discover. Your supported positions will also appear automatically on your dashboard.

Ekubo brings a new concentrated-liquidity design to Ethereum. Revert gives its LPs the analytics and controls to use it with more context.

That answers what the fee costs existing LPs. It does not answer the question an LP asks next, which is "what is the best venue to LP at today?". A protocol take only means something next to what the pool pays before it, and on Base the same pair trades across venues whose fee mechanics have important differences: fixed fees, dynamic fees, emissions paid instead of fees, emissions paid on top of them. So we measured all of it, net of every venue's cut.

This is a like-for-like measurement of what a synthetic ETH/USDC liquidity position would have earned in each of the five largest WETH/USDC pools on Base: Uniswap v3's 0.05% and 0.3% pools, two Aerodrome Slipstream pools, and PancakeSwap v3's 0.01% pool. Same position size, same price ranges, same price path, never rebalanced, so what differs between the results is the pool rather than the LP running it.

Which pools, and why those. WETH/USDC trades on Base in dozens of them. These five cleared $23.5B between them over the last 90 days, 94.7% of the volume among the WETH/USDC pools on that network.

What each pool charges in swap fees is less obvious than it sounds. On Uniswap v3 and PancakeSwap v3 the fee is a constant of the pool: a 0.05% pool charges 0.05% on every swap, for its whole life. Aerodrome Slipstream pools set the fee per swap through a configurable fee module, so no single number describes one, and the two Aerodrome pools here did not behave alike. Over these 90 days the fee volume actually paid was 0.0110% in one of them and 0.0439% in the other: same pair, same venue, four times the rate.

Swap fees are also not the only way these pools pay, and the three venues do not pay on the same terms. On Uniswap, swap fees are the whole of it. On Aerodrome, liquidity can be staked in a gauge, which takes 100% of the position's swap fees and pays AERO emissions instead: fees or emissions, never both. On PancakeSwap, the position can be deposited in the MasterChefV3 farm, which pays CAKE and leaves the swap fees with the position, forwarding them to the staker on collect. Fees and emissions. So a staked position means a different trade at each venue, and every row below says which.

No venue's marketing would write this piece. It is not an argument that one pool is better; it is a measurement of what dynamic fees, competing liquidity, and professional market makers do to a passive LP's revenue, and it is illustrative of the different factors at play.

Window: 90 days to July 25, 2026
Network: Base
Pools: five WETH/USDC pools across three venues
Position: $10,000 at four widths, never rebalanced
Snapshot: July 25, 2026

Scope

Fee income for identical hypothetical positions. A $10,000 position at four widths (1.20x, 1.52x, 2.46x, and full range, where width is the ratio of upper to lower price bound), centered at each window's opening price and never touched. Every bound sits on the tick grid that is mintable on all five pools, whose spacings are 10, 60, 100, 50 and 1, so each simulated position is one you could actually open in any of them.

Not total return. Divergence loss is common to identical ranges on the same pair over the same price path, so it cancels out of a venue comparison and fee income is the entire difference. Your own return includes it. The fee APRs here are net of each venue's protocol take and nothing else.

Not LP skill, though other LPs still matter. Synthetic positions remove our LP's judgment from the measurement, as would be the case when comparing the real historic positions in each pool. What the synthetic positions earn still depends on how much other liquidity was active around the price at each moment, because that is what a fee share is. So what this measures is what each pool happened to offer one more passive dollar during these specific windows, not a fixed property of any venue. Run it over a different period, or against a different amount of competing liquidity, and the answer changes.

Method

Everything comes from raw on-chain events, processed by identical code for all three venues: every swap in the window (12.2 million of them) and every liquidity addition and removal in each pool's entire life (140.5 million events, 121 million of those in the first Aerodrome pool), which together reconstruct each pool's tick-by-tick liquidity map at every moment. Each swap is then walked step by step through that map the way the pool contract executes it, splitting at every initialized tick, with fees credited to the liquidity active in each step.

The fee is not assumed anywhere. Given exact pool state, the input a swap's observed price movement would require at zero fee is computable, and whatever the trader actually paid above that is the fee the pool charged. This recovers Aerodrome's dynamic fee swap by swap, through configuration changes and any discounts, without needing a published rate at all.

Emissions are measured two ways. Where a position's own tick bounds can be read straight off the pool's reward accumulator, the reading is exact, and that covers 22 of the 36 emissions figures here. The other 14 are integrated from the reward rate and the exact time the range held the price, which is a sampled estimate rather than an exact reading.

What each pool charged

The first Aerodrome pool's fee spent most of the window between 0.006% and 0.03%, volume-weighted at 0.0110% overall, well below every static tier here except PancakeSwap's. Spot reads of its fee() function ranged as high as 0.2%, but volume concentrates where fees are low, given lower fee means greater arbitrage opportunities, so the rate volume actually paid is much lower than any snapshot suggests. The configuration itself changed mid-window, on-chain, on May 8 and again on July 9. The July change is the step visible in the chart: volume-weighted, that pool became roughly three times more expensive over the final 14 days, 0.028% against 0.0110% for the window as a whole.

The second Aerodrome pool ran at 0.0439% volume-weighted, four times the first, and the comparison between them is the most useful thing in this chart. It took a quarter of the first pool's volume, $2.65B against $9.66B, and collected more gross fees doing it, $1.16M against $1.06M.

The results

Net fee APR for the same $10,000 position, after what each venue keeps (25% on the Uniswap 0.05% pool, 16.7% on the Uniswap 0.3% pool, 33% on PancakeSwap, and on Aerodrome a cut on unstaked positions only, 5% in the 0.01% pool and 10% falling to 5% partway through the window in the 0.04% pool, applied per swap from its on-chain history), with fees valued at each swap's price. Staked rows say what staking pays at that venue: on Aerodrome the gauge takes all swap fees and pays AERO instead, on PancakeSwap the farm pays CAKE and the position keeps its fees. The best figure in each width is highlighted.

The 90-day window opened at an ETH price of $2,348 and closed at $1,865, so these positions were centered high and the price fell through them.

This window opened at $1,579 and closed at $1,865: centered low, with the price rising through the ranges, which is why every narrow number here is larger than its 90-day counterpart.

This window opened at $1,806 and closed at $1,865, the quietest of the three for price.

Read the three tables as three separate entries rather than one position watched over time: each window's positions are freshly centered at that window's opening price, so differences between windows carry entry timing and market path as much as venue. Fees are valued as they accrue; valuing the accumulated fee tokens at end-of-window prices instead moves APRs by up to 1.95 percentage points, the extreme case being the 30-day narrow position in the pool with the highest realized fee. Both conventions are in the published results.

Four things stand out. No venue won. That is why this piece does not end by naming one.

• The pool decides, not the venue. What you take home is the best instrument the venue offers: swap fees on Uniswap, fees or AERO on Aerodrome, fees plus CAKE on PancakeSwap. On that measure the 0.04% Aerodrome pool took the 30-day window and three of the four 90-day cells, PancakeSwap took the 14-day window and the 90-day narrow range, and neither Uniswap pool won any of the twelve. Strip the staked rows out and compare swap fees alone and the picture inverts: the 0.04% Aerodrome pool takes eleven of twelve, PancakeSwap's 6.5% in the 90-day narrow cell is the lowest of the five, and Uniswap's 0.3% pool wins that one cell at 8.0%. Which comparison you run decides who wins, so the tables mark what an LP takes home. The other Aerodrome pool, the one that traded 5.8 times the Uniswap 0.05% pool's volume and collected more fee dollars than it, was the worst of the five over 30 days and second worst over 90.

• The volume, fee dollars and TVL numbers are each half an argument. Uniswap's 0.3% pool collected $18.3M in fees over the window, twenty-two times what the 0.05% pool collected, and paid a $10,000 position about what that pool paid, because the position is one twenty-fifth of the slice there. PancakeSwap is the mirror image: the thinnest book of the five, where the same position is about twice the slice it would be in Uniswap's 0.05% pool, and the smallest fee pot, $348k, a third of which the protocol keeps. It finishes last. Neither pool's volume number tells you what it paid: the one with the most fee dollars and the one with the thinnest book came within four tenths of a point of each other.

• Staking is a different instrument at each venue, and the ranking is not settled by it. On Aerodrome, emissions valued as they accrued beat that pool's own unstaked fees at every width in every window, which is the whole point of a gauge; against the other venues they win some widths and lose others, and which ones depends on how AERO is valued. On PancakeSwap that is not an issue: the farm pays CAKE and leaves the swap fees with the position, so staking there is additive: over the 90 days a staked position is simply the unstaked one plus 1.1 to 5.7 points,

Emissions are paid in a token whose price moves, and that is an important price risk staker LPs are exposed to. AERO fell about 11% across the 90 days. Valuing each day's accrual on the day it accrued gives the staked figures above; valuing the same tokens at the window's close costs the 90-day staked figures up to 1.1 points and the 30-day ones up to 5.8, and it changes the answer to whether staking beat holding the fees: over the last 14 days the 0.01% pool's staked position goes from ahead of its own unstaked fees at every width to behind them at every width, and the 0.04% pool's lead over its own fees shrinks to 1.25 points at the narrow width and a twentieth of a point at full range. Fee income is not risk-free either, since it accrues in the two assets you already hold, but staking swaps part of that for exposure to a third one.

Those figures assume the AERO sits unclaimed until the end, which is the worst case in a window where it fell 11%. Auto-compounding it would have improved these returns even above what is shown in the tables and charts: harvesting converts each day's rewards at that day's price, so the price going down stops eating the revenue, and the harvested amount earns fees alongside the original capital. That is what we automate at Revert, and worth considering if you are a staker.

Ignoring protocol fees

Every number above is net of what the venue keeps, and the venues keep very different amounts: a quarter of LP fees in the Uniswap 0.05% pool, a sixth in the 0.3% pool, a third on PancakeSwap, and on Aerodrome a cut on unstaked positions only. That cut is not a constant either, and it is somewhat confusing: their own docs claims it is between 10% and 50% for unstaked liquidity, however in practice the 0.01% pool charged 5% throughout, while the 0.04% pool charged 10% until 20 May and 5% after, which works out to 5.6% of the fees the pool collected over the window. PancakeSwap's is the largest cut of the five and it is not a published number we took on trust: its slot0.feeProtocol reads 3300 per side against a 10,000 denominator, which is neither Uniswap's 1/n encoding nor a percentage, so we measured it from the protocol-fee fields its own Swap events carry. It comes to 0.330000 of every fee paid, identical across twelve sample regions spanning the window.

Add every venue's protocol fee back and compare fee income only, with no staking and no emissions on either side, and the order changes completely:

Gross of the protocol fee, Uniswap's 0.05% pool earns the most at every width, and PancakeSwap moves off the bottom: second at the narrowest width, third at the next, fourth at the two widest.

What to do with this

There is no one-venue that really comes out ont op. These five pools competed for your liquidity over the same 90 days and no single one of them was the answer. Which pool paid you the most depends on the window and on whether you staked taking on the implied price risk. On swap fees alone the 0.04% Aerodrome pool takes eleven of twelve cells; allow staking and PancakeSwap's fees-plus-CAKE takes the 14-day window outright. One pool changed its fee twice inside the window, and another halved its cut. At the tightest width over the last 14 days, three of the five finish within three quarters of a point of each other.

So the job is not picking a venue. It is monitoring the different factors, and moving when they change:

• the realized fee rate, not the label. A dynamic-fee pool has a fee history rather than a fee, and the two Aerodrome pools here ran 0.0110% and 0.0439% on the same pair over the same window.

• how much of the tick is yours at the moments fees are paid. That is the other half of every result above, and it is why the pool with the most fee dollars did not pay a $10,000 position the most. Short-lived ultra-concentrated liquidity it not good for more passive LPs.

• what the venue keeps, from a 5% cut on Aerodrome to a quarter on Uniswap's 0.05% pool and a third on PancakeSwap. It is also mutable: one of these pools halved its cut inside the window.

• whether staking is additive or a swap. On PancakeSwap the farm pays CAKE and leaves your fees alone. On Aerodrome the gauge takes all of them and pays AERO, which is a real trade with a reward-token risk attached. And how exposed you are to the reward token's price risk.

All four move. None of them is visible from a TVL number or a headline APR, and by the time a pool reaches a leaderboard the flow has usually already arrived.

Check what your own positions actually earned, after each venue's cut, from your Revert dashboard.

Appendix

Fees and volume

Volume follows execution price, and at 0.0110% the first Aerodrome pool was very cheap to trade in. Then it stopped being so cheap. Its fee module was reconfigured on July 9, the realized rate went from 0.8 bips to 2.9 over the following week, and volume fell 65%, from $88M a day to $30M. Over the same days the other four pools moved by -14%, -2%, -4% and +21%, so that decline is far larger than anything else happening in the pair, and it is consistent with flow responding to the fee.

Part of that relationship is mechanical rather than a matter of trader preference. A pool's fee is the threshold an arbitrageur has to clear, so the cheaper the pool, the smaller the price divergence that is already worth trading against. Lower the fee and you get more arbitrage volume, mechanically, with no change in anyone's demand for the pair.

What is measured here is the fee series, the volumes, and the pool's response to its own fee change.

PancakeSwap volume numbers highlight an import caveat, because the cheapest fee did not get the most volume. It charges the same one-bip fee the first Aerodrome pool averaged over the window, and it had about a third of that pool's volume. The difference is what a trade pays besides the fee. Price impact is set by the liquidity standing at the price, and Aerodrome's book at the price is about four times deeper, much of it short-lived positions, posted at the active tick.

Why Volume*Net LP Fee rate is not the whole story

What an LP position earns is the product of exactly two things: the fee dollars the pool paid out to liquidity on each swap, and the slice of the active tick your position was at the moments the swaps happened.

A swap only pays the liquidity standing in the tick it is trading through, so your fee income is your liquidity divided by the liquidity in that active tick, summed over every step of every swap. Liquidity parked in ranges the price never reaches earns nothing and dilutes nobody. So the quantity that matters is not the pool's average liquidity or its TVL, it is how large a slice you were of the active tick at the moments fees were actually paid.

So the question is not why one pool's fees were low. It is who you are splitting them with. Aerodrome pools have a considerable amount of volume, however for normal LPs much of its diluted by an equally considerable amount of "short lived liquidity", or "bots" that reposition very extremely narrow-range liquidity every few blocks.

Because arbitrage volume will increase or decrease along with liquidity this ultra concentrated liquidity will actually have a more important impact in diluting reward revenue. This is something we have studied previously in the context for Uniswapv3 staker rewards. If Aerodrome were to prevent this type of strategy it should have a big positive impact on regular staked LPs performance.

The five pool addresses in this study: Uniswap v3 0.05% 0xd0b53d92, Uniswap v3 0.3% 0x6c561b44, Aerodrome Slipstream 0.01% 0xb2cc224c, Aerodrome Slipstream 0.04% 0x3fe04a59, PancakeSwap v3 0.01% 0x72ab388e, all on Base.

The comparison that answers the question runs between two complete scenarios. In one, the fee never exists and LPs keep every fee dollar. In the other, the fee runs for each position's entire life. Real positions live in between: their pre-activation fees were untaxed, and their post-activation fees arrived already net of the protocol's cut, because the pool contract deducts the protocol share before crediting LPs. We build both scenarios from actual accounting: where the fee already ran, we add its take back; where it had not started, we subtract it. This is accounting, not equilibrium: nothing here models LPs changing behavior because of the fee.

What governance activated

1. UNIfication (passed late 2025) turned on protocol fees for v2 and a first wave of mainnet v3 pools, those where Uniswap held 90%+ market share. The v3 rates: 0.01% and 0.05% pools give up one quarter of LP fees; 0.30% and 1% pools give up one sixth. The mainnet pools here activated December 27, 2025.

2. The Protocol Fee Expansion (Vote 1, executed March 6, 2026; Vote 2, executed March 8, 2026) extended the same per-tier rates to all remaining mainnet v3 pools and all v3 pools on eight more chains, including Arbitrum and Base, which activated March 6, 2026.

3. v4 protocol fees are a separate track, with votes underway since mid-July. Excluded throughout.

A fee haircut is not a return haircut

Your net return as an LP is fees earned minus divergence loss. Divergence loss is a loss by construction: zero at best, when price is exactly at your entry, and growing the further price moves away. Fees are the only reason LPing (sometimes) beats holding. The protocol fee applies only to the fees side, so the relative damage to your net return is the haircut multiplied by how fee-dependent your position is.

A position that earned $100k in fees against $10k of divergence loss nets $90k. A 16.7% fee haircut takes $16.7k, which is 18.5% of net. Mild.

A position that earned $100k in fees against $80k of divergence loss nets $20k. The same haircut takes the same $16.7k, which is 83% of net. Brutal.

Measured across the cohort below: the median profitable position gives up 28% of its net return to a 17-25% fee haircut.

The data

Scope: Ethereum mainnet, Arbitrum and Base, every Uniswap v3 pool pairing ETH with USDC or USDT holding at least $100k TVL. That is 20 pools, of which 18 contain qualifying positions.

Inside those pools we measure one fixed set of positions. We call it the cohort, and every number in this post describes it unless stated otherwise. A position is in the cohort if it:

• is still open and has never had a withdrawal

• has at least $1,000 deposited

• is at least 30 days old

• has earned fees at all (price never entering a position's range means nothing accrued and nothing for the fee to take)

8,053 positions qualify. Profitability throughout is measured against HODL, APRs are lifetime figures, and everything is a snapshot as of July 24, 2026. Everyone else in these pools pays the fee too but is not counted here: closed positions, every LP who ever withdrew (which covers rebalancing vaults and just-in-time liquidity), and sub-$1k positions.

The fee split is exact for every position, with no estimation anywhere:

• 4,238 positions were minted after their pool activated. All their fees are post-fee reality by construction.

• 3,815 positions predate activation. For each one we reconstructed its full fee state at its pool's exact activation block from archive data: the position's fee checkpoints and owed balances, plus the pool's fee-growth accumulators, which together give the precise fees earned up to the activation boundary. Post-activation fees are the recorded lifetime totals minus that reconstruction.

The results

[Lifetime net APR distribution, no-fee scenario vs fee always on: chart_results_hist.png]

Per position, the median cost is 3.5 points of net APR. That is each position measured against itself, which is why it differs from the 3.0-point gap between the two medians above: the positions earning the most fees take the biggest cuts. The median profitable position gives up 28% of its net return. The fee flips 491 positions, one in ten of everything that would be profitable without it.

Separately from the scenario comparison: the protocol has actually collected about $3.6M from these positions since activation. That figure is realized revenue, not a model; $2.5M of it came from positions that straddle activation and $1.1M from positions created after the fee switch.

[The cohort's $30.0M in gross fees split two ways: scenario vs reality: chart_results_money.png]

Where it costs the most

[Median lifetime net APR by width, fee tier, and network, before and after the fee: chart_where_dumbbell.png]

By range width (width is the ratio of a position's upper price bound to its lower one; a 1.8x range on ETH/USDC runs, for example, from $1,500 to $2,700; full range means the position's ticks span the entire usable range for its fee tier):

Splitting each width by fee tier:

Wide ranges stay clearly positive under the fee on both tiers. Middle widths take the deepest cut, fee-dependent enough to feel the haircut, not wide enough to earn through it, and on the 25% tier their median under the fee is exactly zero. Narrow ranges lose money in both scenarios: the fees they earn do not come close to covering the divergence loss a tight range accumulates, with or without a protocol cut.

By position age:

Read the age rows for what they are: entry-date cohorts. The 180-days-to-1-year bucket is deeply underwater in both scenarios because of when it entered, not because of the fee: those positions were opened between late July 2025 and late January 2026, a window containing ETH's August highs above $4,300, and ETH has roughly halved since. Their median divergence loss is 24% of deposits against 6% in fees, so the market path swamps everything else. The fee's own effect is the gap between the two columns, and it stays in a narrow band (2.3 to 4.8 points) across every age. What does move with age is the flips: over half of all flipped positions (252 of 491) are in the youngest bucket, where cushions are thinnest and a quarter of the fees is the difference between positive and negative.

Two aggregate medians cross zero under the fee: the 0.01%/0.05% tier goes from +2.2% to -1.1%, and Arbitrum goes from +1.1% to -2.3%. On the highest-rate tier and the chain most concentrated in it (92% of Arbitrum's cohort is on 0.05% pools), the median position's lifetime economics go negative under the fee. Base goes +7.9% to +4.5%; mainnet +5.0% to +2.6%.

By pool

The mainnet USDC/WETH 0.05% pool dominates the dollars: $4.4M of the cohort's $6.8M lifetime take, and $2.3M of the $3.6M collected so far.

Cross-checking against on-chain receipts

The protocol's revenue is independently visible on-chain: every sweep emits a `CollectProtocol` event, and whatever has accrued since the last sweep is held in each pool's `protocolFees` slot. Summing both across the 20 pools from each pool's activation block through July 24 gives $13.4M, all but a few thousand dollars of it already swept to each chain's TokenJar, Uniswap's fee-collection contract. Collection is continuous: the first sweeps happened within two days of activation, and every pool was swept within the last day.

The cohort's $3.6M realized take is 27% of that, and in every pool it is below both the pool-wide total and the cohort's share of TVL.

The two extremes tell the same story from opposite ends. The mainnet USDC/WETH 0.05% pool is dominated by large passive positions, our cohort holds 82% of its TVL, and accordingly pays 75% of its protocol fee. The Base 0.3% pool is the busiest revenue source of all 20, but its fee flow comes overwhelmingly from tight, frequently recycled positions that the never-withdrawn filter excludes, so the cohort's 21% of TVL pays only 4% of the take. TVL shares come from our pool snapshots and are used only for this plausibility check. The per-pool `CollectProtocol` tally and the script that produced it are in the published dataset.

What to do with this

The fee is part of the terrain now. For the most common strategy, LPing to beat holding, fees have to out-earn divergence loss, and on these pools a sixth to a quarter of them goes to the protocol first. Wide ranges clear that bar most often, on both tiers. Middle and tight ranges on the 25% tier are where lifetime economics stop working at the median. Your dashboard shows net APR (fees and divergence loss together) for every position. And a note on the backtester: it replays observed on-chain fee growth, which on fee-on pools is already net of the protocol's cut, so do not apply any additional haircut to its results.

Check it out Revert

Check the data yourself

One CSV row per position: the boundary-reconstructed fee split, both scenarios, explicit profitability booleans, unrounded values, and a revert.finance link per row so every input can be checked against its live page. The bundle includes the per-pool activation table (block, transaction, timestamp), the boundary reconstruction script, and the on-chain cross-check: a per-pool `CollectProtocol` tally with the script that produced it. Snapshot: July 24, 2026.

A new chain, and a new kind of pool

Robinhood Chain went live on mainnet on July 1st: an Arbitrum-stack L2 settling to Ethereum, built around tokenized US equities and ETFs trading around the clock. That makes it an unusual place to provide liquidity. Alongside the familiar crypto pairs, there's an emerging set of pools around tokenized real-world assets, and liquidity there is still forming.

Early markets are where informed LPs do best: ranges are unpriced, competition is thin, and fee tiers haven't settled. They're also where discipline matters most. New pools mean thin books, volatile spreads, and token risk that hasn't been tested. The tooling for judging that tradeoff is exactly what we ship.

What's live today

Position tracking. Every Uniswap v3 position on Robinhood Chain, with the metrics you know from other networks: PnL vs HODL, fee APR, divergence loss, real-time fees. Choose your benchmark (HODL, ETH, or USD) per position.

Create and manage positions. Open new v3 positions, add and withdraw liquidity, and manage ranges directly from the dashboard.

Top positions. Browse the largest and best-performing v3 positions on the network to scout ranges, fee tiers, and strategies that are actually working, especially useful while these pools are young and reference points are scarce.

Price simulation. On any live position, simulate the effect of price moves before they happen: asset distribution and divergence loss at any target price you set.

Getting started

Connect your wallet at revert.finance, switch to Robinhood Chain, and your positions are there. Or start from Create Position to open your first one.

More to come on this network. We'll keep it boring and announce things when they ship.

TL;DR

• A security researcher privately reported an issue in the Auto-Range V3 contract for UniswapV3 on Ethereum mainnet, Arbitrum, and Base. The researcher has asked to remain anonymous. Thank you, you know who you are.

• No user funds were at risk at any time, and no positions were affected.

• We paused Auto-Range executions on those three chains, deployed fixed contracts on July 5, and completed the migration on July 11th.

• If you had Auto-Range active on a Uniswap v3 position on mainnet, Arbitrum, or Base, you need to re-activate it once. Open the position page and follow the prompt. Configurations on the old contract do not carry over.

• Auto-Range on Polygon, Optimism, and BNB, and all Aerodrome automations, were not affected.

What you need to do

Uniswapv3 Auto-Range configurations live inside the contract that executes them. Since the fix required deploying a replacement contract, your old configuration cannot follow automatically: re-creating it is a one-time action only you can take.

1. Open your position on revert.finance.

2. If the position had Auto-Range on the old contract, you will see a prompt to activate Auto-Range again. Set your range trigger as before and confirm.

3. Optional hygiene: revoke the NFT approval you granted to the old contract address. The old contract can no longer touch vault positions and is no longer operated by us, but there is no reason to leave stale approvals around.

That's it. Fees, positions, and everything else are untouched.

What happened

Last week a security researcher reached out through our security contact with a finding in the Auto-Range V3 contract for UniswapV3.

No user funds were at risk. The issue was not exploitable by the public: the code path in question was only callable by our own permissioned operator account, the same account that already executes your automations within the limits you configure.

What the issue did was quietly increase how much trust that operator account required. And that is exactly the direction we never want to move in.

Revert Lend is built around one invariant: anything that touches a position held as collateral must pass through the vault's health checks. That is a promise enforced by code, not by us behaving well. Auto-Range integrates with the vault as a "transformer", so borrowers can rebalance collateral in place, and the vault wraps every such transform in a collateral check before and after.

The researcher found that the old Auto-Range contract also accepted direct operator execution on positions owned by the vault, skipping the vault wrapper. Your own configuration limits, like slippage caps and reward caps, still applied on that path. What went missing was the vault-level solvency check, and with it the guarantee that even a compromised operator key could not move Lend collateral outside vault rules.

In practice, safety on that path depended on trusting the operator account. Users never signed up for that trust, and we don't want it. So we treated this with the same urgency as a fund-loss bug.

The fix

Our contracts are not upgradeable, on purpose. A fix therefore means a new deployment and a migration, not a silent patch.

The contract change itself is small and public (revert-finance/lend PR #60): direct execute and autoCompound calls now revert when the target NFT is owned by a configured vault. The vault path, where the health checks live, becomes the only way to transform collateral. Regression tests cover the edge cases, including old NFTs that retain a stale approval after a range move.

The operational timeline:

New contract addresses, verified on the block explorers:

Between June 27 and the redeploy, Auto-Range executions on these three chains were paused. If your position crossed its trigger during that window, it was not rebalanced. We prefer a paused automation over one running on a contract we have open questions about, every time.

Trust is the actual bug

The lesson we took from this finding is not "add a check". It's that trust in privileged accounts creeps in silently, and it has to be hunted deliberately.

The operator account was designed to be low-trust: it can only execute automations users opted into, within limits users configured, and the contracts enforce those limits. This issue widened what trusting the operator meant without anyone deciding it should. The fix restores the boundary: a compromised operator key is once again bounded by contract code, including for Lend collateral.

We applied the same standard to our own admin keys while we were at it:

Vault administration on Arbitrum and Base already sits behind 48-hour timelocks, and the entire migration above ran through them. No shortcuts, including for our own security fix.

Thanks

Our thanks again to the researcher who reported this and chose to stay anonymous. Reports like this one are how trust assumptions get found before they matter.

Thanks to PeckShield for reviewing this fix prior to deployment.

If you believe you've found a security issue in any Revert contract or system, contact us at hi [@] revert.finance. We take every report seriously and we will not be weird about it.

A Quick Word on the Relaunch

Shortly after our initial launch in January, an exploit affected the newly deployed Aerodrome vault. We paused the vault within hours, and no user funds were impacted; the affected capital was entirely our own. You can read the full details in our post-mortem.

Rather than patching the original code, we rebuilt the Aerodrome integration from the ground up. The rewritten contracts were put through a public security competition on Cantina, where independent researchers reviewed the code with no high-severity issues identified, and every reported finding has been fixed.

What Changed Under the Hood

The rewrite hardens the invariants that matter most for a lending vault built on staked LP positions:

• Vault-enforced collateral integrity. Every execution path that can touch a collateralized position now settles through the vault's health checks. Positions with active debt can no longer be modified in any way that reduces collateral value outside the vault's control, which was the root cause of the January incident.

• Validated reward swaps. AERO reward compounding routes through pools validated against on-chain TWAPs with strict price-deviation limits, protecting compounders from manipulation and excessive slippage.

Market Parameters

The vault relaunches with the following market parameters:

• Lending asset: USDC

• Collateral factors: 85% for USDC, 77.5% for WETH and cbBTC pairs

• Global limits: 1M USDC lend cap, 1M USDC debt cap, with 100k USDC daily growth limits

• Reserve factor: 10%, with 5% reserve protection

What You Can Do With It

This is the same lending engine that has been running on Revert Lend on Arbitrum, now wired into Aerodrome's gauge system on Base.

Earn lending yield on idle USDC. Deposit USDC into the vault and earn interest paid by borrowers. Rates adjust dynamically with utilization, and lenders can withdraw at any time subject to available liquidity.

Borrow against your LP positions. Deposit an Aerodrome position and stake it into its gauge, and it keeps earning AERO emissions while doubling as collateral. Borrow USDC against it for working capital without closing the position, exiting the pool, or giving up your rewards.

Lever up in one transaction. Borrow, swap, and add liquidity atomically to scale your exposure to a pool without bringing in fresh capital. Unwinding works the same way in reverse: remove liquidity, swap, and repay in a single transaction.

Manage positions without repaying first. Change ranges, withdraw a portion of liquidity, or rebalance directly on a collateralized position. The vault checks loan health on every operation, so you keep full flexibility as long as the loan stays healthy.

Auto-Compounding, Done Properly

Staked Aerodrome positions earn AERO emissions, but emissions left unclaimed do nothing for you. Compounding them by hand means claiming, swapping to the right token ratio for your range, and re-adding liquidity, over and over, with gas and timing working against you.

The Revert autocompounder does the whole loop automatically:

• Claims accrued AERO from the gauge

• Swaps it into your position's tokens at the ratio your current range actually needs, through TWAP-validated pools with strict slippage protection

• Adds the proceeds back as liquidity and restakes, so the new liquidity immediately earns emissions too

The effect compounds in both senses. Your position grows continuously instead of in occasional manual lumps, and on leveraged positions the compounded rewards increase your collateral value, improving loan health over time rather than letting interest erode it.

Analytics for Every Decision

Revert started as an analytics tool, and everything above sits on top of it:

• Pool discovery. Compare Aerodrome pools by volume, TVL, emissions, and historical fee and reward APRs to find where liquidity is actually paid.

• Position-level performance. Every position gets a full breakdown: fee and reward earnings, PnL versus holding, divergence loss, and APR over time, so you know whether a strategy is really working.

• Loan monitoring. Collateral value, debt, and loan health are tracked continuously, so leveraged LPs can see exactly how much headroom they have before acting.

Getting Started

Head to revert.finance, connect your wallet, and deposit your Aerodrome position to unlock lending, leverage, and auto-compounding. If you are new to the pool side, browse the Aerodrome pool analytics first and start from a position that fits your risk.

Contracts

All Revert Lend Aerodrome contracts are deployed on Base:

Contract

Address

Lend Vault (rlUSDC)

0x1EF7C181188687e20A9750714f1b9DE6F70f17C0

GaugeManager

0xc171F8c6ED8253151DE50ab839E3A468028113F2

AutoRange

0xEB6127DcFB1E4107Dc1F3111151f779920c213Dd

AutoExit

0xc35e20379C3267B5f63E569c25959031aC588203

LeverageTransformer

0xF4fCBaB7D092A0b46438DBBaa21333f7F07137EC

V3Utils

0x2309A5aE06e86986a6f27b81a53cC31Fc1B55b0a

V3Oracle

0x82722327E45E86a0F2107746F423f612139b0952

InterestRateModel

0x9E29b74336A0D698AD600b3e52729bFda85e0564

PancakeSwap currently carries roughly $2.2B in TVL and ~$87B in monthly volume. The bulk is on BNB, with around $3.6B on Base and $513M on Arbitrum, both growing. With these three integrations live, Revert now covers the bulk of PancakeSwap's concentrated-liquidity surface.

The BNB gap came down to one thing: our subgraph stalled at ~70% sync and never caught up to BSC's event throughput. We routed that specific workload onto Envio's HyperIndex, and the full historical sync (over 1.7B events) finished in ten days.

With indexing solved and historical state fully reconstructed, PancakeSwap positions across all three networks are now tracked inside Revert with the same analytics stack used across the rest of the platform.

What you get

- Full analytics on existing and historical positions
- Surfaced in Discover when you're scoping a new position to open
- The same automation suite you know and love
- Top Positions tracking

Returning BNB users: positions are already backfilled. New positions on Base and Arbitrum start tracking from mint.

Try it

revert.finance → connect → your PancakeSwap v3 positions on BNB, Base, and Arbitrum will appear alongside the rest.

Tracking is up across all three networks today.
Revert Lend on PancakeSwap is what's next.

On January 29, 2026 we announced support for Aerodrome concentrated liquidity positions on Base:
https://paragraph.com/@revertfinance/revert-lend-now-supports-aerodrome-on-base

A few hours later, we received and verified a report of an exploit affecting the newly deployed Aerodrome Lend vault. We immediately disabled new deposits and new borrows via our emergency multisig and communicated the pause publicly:
https://x.com/revertfinance/status/2017087480772600157

TL;DR

• All user funds are safe.

• The USDC in the affected vault was 100% Revert team capital (no third‑party user deposits were in the pool at the time).

• Only the Aerodrome Lend vault on Base was affected. No other Revert vaults/products were impacted.

• This deployment had three independent audits (Cantina, PeckShield, HYDN). We are implementing fixes and will not re‑enable Aerodrome Lend without additional independent review/audit of the changes.

Impact

• Loss: ~50,101.744193 USDC (protocol‑owned / Revert team funds)

• User impact: none (no user funds in the affected pool)

• Affected component: Aerodrome Lend vault integration (Base)

Onchain transactions (Base)

A second exploit transaction occurred ~58 minutes after the first, from a different address.

Timeline (UTC)

• Jan 29, 2026: Aerodrome support announced (launch post linked above)

• Jan 30, 2026 ~02:31: Exploit transaction #1

• Jan 30, 2026 ~03:29: Exploit transaction #2

• Shortly after verification: New deposits and borrows disabled via emergency multisig; Aerodrome Lend paused

• Jan 30, 2026 14:14:21: Onchain recovery outreach sent to the address thatcontrol the exploited funds.

What happened (technical overview)

Aerodrome Lend allows Aerodrome Slipstream concentrated liquidity positions (NFTs) to be used as collateral in a lending vault, while optionally being staked for gauge rewards and autocompounding.

This incident was caused by an end‑to‑end invariant gap across multiple contracts involved in that flow.

The staking/automation layer (used to stake positions and execute position-management operations) included a pathway that allowed the position owner to execute operations that could materially change the position, even when that position was flagged as a vault-collateralized position.

In short, the attacker was able to withdraw liquidity from a collateralized (and staked) LP position while leaving the vault with an NFT that still existed but no longer represented the expected collateral value for the outstanding loan.

Attack flow (simplified)

1. Flash‑loan funds were used to mint an Aerodrome Slipstream LP position (NFT).

2. The attacker deposited the NFT into the Aerodrome Lend vault as collateral.

3. The attacker borrowed USDC against that collateral.

4. The position was staked through the vault’s staking/manager flow.

5. The attacker used a GaugeManager execution path (via a utility contract) that temporarily unstakes the NFT and executes position‑management instructions.

6. That execution path did not enforce the constraints required for positions backing active debt, allowing liquidity to be withdrawn and routed to the attacker.

7. The flash loan was repaid and the borrowed USDC became profit.

Root cause

The root cause was a missing safety constraint in the staking/management layer: a collateralized position with active debt could still be modified through an execution path in a way that reduced its collateral value without the vault preventing the action at the time it happened.

Immediate response

• Verified the report and confirmed the issue onchain.

• Disabled new deposits and new borrows for the Aerodrome Lend vault via emergency multisig.

• Communicated the pause publicly and began remediation.

Remediation & next steps

Aerodrome Lend will remain paused while we:

• implement fixes to ensure collateralized positions cannot be modified in ways that break collateral backing,

• complete additional internal review and testing of the Aerodrome integration and surrounding flows,

• commission additional independent security review/audit specifically focused on the incident root cause and the final remediation.

We will publish follow‑up updates as we complete these steps. Aerodrome Lend will not be re‑enabled until the fixes are deployed and the additional independent review/audit is complete.

Contracts involved

Security reviews / audits

Prior to launch, the Revert Lend deployment and supporting components underwent three independent audits/reviews:

• Cantina:
  https://cantina.xyz/portfolio/cfb5a6a0-0061-4f14-ab5a-195ed6b7816d

• PeckShield:
  https://github.com/peckshield/publications/blob/master/audit_reports/PeckShield-Audit-Report-Revert-v4Utils-v1.0.pdf

• HYDN:
  https://github.com/hydnsec/audits/blob/main/Revert%20Finance%20-%20Lend/HYDN%20-%20Revert%20Finance%20Lend%20-%20aero%20-%20Audit.pdf

Audits reduce risk, but they are not a guarantee. We take responsibility for this incident and are adding additional review/audit before re‑enabling Aerodrome Lend.

After the incident, HYDN Security proactively reached out and assisted our team during incident response and remediation planning.

Thank you / reporting

Thank you to the reporter who raised the issue quickly. If you believe you have found a vulnerability, please disclose it responsibly via the security contact listed in our documentation.

We're excited to announce that Revert Lend is now live for Aerodrome concentrated liquidity positions on Base. This expansion brings the full power of Revert's lending protocol to Aerodrome LPs, enabling new ways to maximize capital efficiency while earning AERO rewards.

Aerodrome LPs on Base can now:

• Borrow against LP positions – Use your Aerodrome concentrated liquidity positions as collateral to borrow USDC while continuing to earn trading fees and AERO rewards

• Leverage your positions – Amplify your LP exposure by borrowing, swapping, and adding to your position atomically

• Autocompound AERO rewards – Automatically compound your AERO emissions back into your LP position to maximize returns

• Stake with one click – Deposit positions into Aerodrome gauges through our Revert-Staker to earn AERO rewards while maintaining access to all Revert features

Why This Matters

Concentrated liquidity positions on Aerodrome represent significant capital. Until now, this capital was locked—earning fees and AERO rewards, but otherwise idle.

With Revert Lend, you can put that capital to work:

1. Deposit your Aerodrome LP position as collateral

2. Borrow USDC at competitive rates

3. Leverage up to amplify your exposure and yield

4. Keep earning trading fees and AERO rewards on your position

5. Autocompound your AERO rewards to amplify returns

All without giving up control of your position.

Leverage

For LPs looking to amplify their exposure, Revert Lend enables one-click leverage. Borrow against your position, swap into your desired tokens, and add liquidity—all in a single atomic transaction.

This means you can:

• Increase your position size without additional capital

• Amplify fee earnings and AERO rewards

• Deleverage just as easily when you want to reduce exposure

The leverage flow handles the complexity of borrowing, swapping, and redepositing, giving you a streamlined way to scale your positions.

AERO Autocompounding

One of the most requested features from our users: automatic compounding of AERO rewards. Instead of manually claiming AERO, swapping it, and redepositing liquidity, Revert handles this for you.

The autocompounder:

• Collects your earned AERO rewards

• Swaps them optimally into your position's token pair

• Redeposits as concentrated liquidity in your existing range

This turns your gauge rewards into compounding yield without any manual intervention.

How It Works

1. Navigate to your position on revert.finance

2. Stake with Revert-Staker to unlock lending and automation features

3. Enable autocompounding, leverage up, and/or use your position as collateral

Security

Revert Lend for Aerodrome has undergone comprehensive audits by Cantina, PeckShield, and Hydn.

Get Started

Aerodrome LP positions are now eligible for Revert Lend on Base. Visit revert.finance to start borrowing against your positions, leveraging up, and activating AERO autocompounding.

This launch announcement is simple: the analytics you already know and love, now for Uniswap V4. Every V4 position comes with the full Revert metrics stack, with Hook integrations coming soon.

LPs can now analyze v4 positions, backtest ranges, and manage them directly in Revert. When creating positions, v4 pools appear alongside every other supported market, with the same performance metrics, charts, and historical data users already rely on.

This launch also includes V4Utils, our dedicated suite of on-chain utilities for Uniswap v4 LPs. The toolset covers the core actions LPs use constantly: Move Range, Swap-and-Mint, Decrease-and-Swap, Collect-and-Swap, and other streamlined zaps that collapse multi-step v4 workflows into clean, atomic transactions.

 The V4Utils contracts have been audited by Peckshield.

Contract addresses:

• V4Utils address Ethereum Mainnet: 0xE162E02eD718F94ac70336fBA69Ff86F2918436d

• V4Utils address Unichain: 0x84b41aea9fe0d7a840d699d840c5fd78f20efe65

Support for other Ethereum L2s coming soon.
Support for hooks, if you are a hook developer, please reach out.

We’re excited to announce the launch of Revert Lend on Ethereum Mainnet.

With this launch, Ethereum users can now supply collateral and borrow against their Uniswap V3 LP positions — unlocking capital efficiency and enabling leveraged strategies or external liquidity use.

Supported collateral assets and factors on Mainnet:

• USDC — 80.75% collateral factor

• USDT — 80.75%

• WETH — 73.63%

• WBTC — 73.63%

Revert Lend allows LPs to borrow against their positions, either to leverage up or to extract capital. Supported positions include pairs like WETH/USDC, WETH/USDT, and WBTC/ETH across all UniV3 fee tiers.

Key Contracts

• LeverageTransformer

  0xbAEA7f73569456096fCf38AE34242c52CA227b1e

• FlashloanLiquidator

  0xa44080F20464de260e25F35A69d6BDa50f2cc79D

• V3Vault

  0xa2754543f69dC036764bBfad16d2A74F5cD15667

• V3Oracle

  0xe0151d335A6C4AB0600Ae4000a9CAAf7b236072f

• InterestRateModel

  0xb50daFe03fEe68595Ab2bAaD3c16F899421F063B

Start lending now:

https://revert.finance/#/lending

We’re excited to announce the launch of Revert Lend on Base 🟦

You can now supply WETH (77.5%), USDC (85%), or cbBTC (77.5%) as collateral to borrow against your Uniswap V3 LP positions on Base. Use the borrowed funds to leverage up your LPs or deploy capital elsewhere.

Revert Lend has already become the largest holder of Uniswap V3 liquidity on Arbitrum. Now we’re bringing the same power to Base.

To bootstrap lending, Revert Points will be distributed to USDC lenders on Base. Full details to be announced shortly.

• Start lending: revert.finance/#/lending

• Docs: docs.revert.finance

• Vault address: 0x36aeae0e411a1e28372e0d66f02e57744ebe7599

• Liquidator repo: github.com/revert-finance/liquidator-js

Repository: https://github.com/revert-finance/liquidator-js

While we will continue to operate our own liquidation bots as a backstop, we believe that a decentralized network of operators is vital for the health and robustness of the DeFi ecosystem. By open-sourcing our bot, we aim to provide a reference implementation that others can build upon.

Liquidation fees on Revert Lend range between 2% and 8%, offering an incentive for participants who help maintain the protocol’s stability.

About the Bot

This bot is designed to monitor active positions on the Revert Lend protocol and execute liquidations when certain conditions are met. It employs a combination of real-time event monitoring and periodic checks to stay updated on the state of positions and market conditions.

Key Features:

• WebSocket Monitoring: Listens to real-time events from the Revert Lend contracts to update positions as they change.

• Periodic Position Checks: Regularly scans all positions to ensure no liquidation opportunities are missed.

• Flashloan Liquidations: Executes liquidations using flashloans, requiring no upfront capital in the asset being liquidated.

• Optional Non-Flashloan Liquidations: Supports liquidations without flashloans if the operator holds the necessary assets and has approved the V3Vault contract.

We invite everyone interested to join us in strengthening the Revert Lend ecosystem. By running your own liquidation bot, you not only contribute to the stability and decentralization of the protocol but also have the opportunity to earn liquidation fees ranging from 2% to 8%. Whether you’re a developer looking to dive into the code or an operator ready to set up your own bot, your participation is valuable.

Together, we can build a more resilient and robust DeFi environment. If you have any questions or need assistance getting started, feel free to reach out to our team or open an issue on the repository. Let’s collaborate to enhance the security and decentralization of Revert Lend.

Worse is better

AMMs could be worse than centralized limit order books markets in any capacity you wanted to measure, and they would still win because they enable the instant, frictionless creation of markets by anyone just holding some amount of assets.

No sophisticated HFT systems need to be spun up. No special SLAs have to be drafted and signed. Instead, AMMs offer fair, algorithmically determined prices that directly respond to market demand.

RFQs are just Binance in the end

Some folks will try to tell you that RFQ systems have a place in this future, and maybe they do, but today most of the quotes on RFQs are arbitraging prices between centralized exchanges (CEXes) and the slippage limit of your on-chain order. They are, in large part, an intermediary between an on-chain swapper and liquidity or expected volume at some centralized exchange. I’m not trying to be critical; they provide a valuable service to traders when they can provide a better price than what is otherwise available on-chain. However, a centrally operated trading system will not get us to the future we are heading for.

If we compare today the liquidity sources where most of the trades happening over the 0x protocol end up, we can see that AMMs account for around 70% of the volume versus 30% for RFQs. If you account for the fact that RFQ systems existed on-chain well before Uniswap v1, you can understand where the trend is going.

And all of this is just getting started. A vast majority of today's crypto assets remain outside the decentralized finance ecosystem, often stored on centralized exchanges or, at best, in cold wallets, not leveraging the potential of permissionless innovation in non-custodial financial services. What do you think AMMs look like when there is 1T in assets in DeFi protocols? What about 10T? You are not sufficiently excited about AMMs.

Firstly, let's explore Auto-Exit.

As a Uniswap v3 liquidity provider (LP), have you ever wished you could automate your liquidity withdrawal when the price hits a certain value? With Auto-Exit, this is now possible. Auto-Exit lets you pre-configure a position so that the liquidity is automatically withdrawn when the pool price reaches a predetermined value. Moreover, you can optionally configure the system to swap from one token to the other on withdrawal, providing a safety net for your investments akin to a stop-loss order.

Next up is Auto-Range.

Auto-Range automates the process of rebalancing your liquidity positions. When the token price moves and your position goes out-of-range by your selected percentage, Auto-Range springs into action. The system then automatically rebalances your position, by withdrawing the liquidity and recreating it with the same range width but centered around the current price, ensuring your liquidity stays in-range and collecting fees always.

Tracking PnL across rebalanced positions can be tricky, and of course it’s important to remember that, depending on your investment strategy, divergence loss is a crucial part of the PnL equation. Measuring each rebalanced position separately might be deceptive with regard to the actual divergence loss that becomes permanent on each rebalance operation. Taking this into account, coming very soon, your Revert dashboard will aggregate auto-range positions into one, providing you proper analytics for these multi-position strategies.

How do automated actions work

To activate the automated actions LPs authorize the Auto-Exit or Auto-Range contracts to act as an Operator for their positions.  Upon this authorization, Revert bots start monitoring the activated position. These bots execute the prescribed operations - withdrawal of liquidity or rebalancing - when the predefined conditions are met.

To support the automation, a fee of 0.25% of the position value is levied for each operation executed by the bots. However, it is crucial to note that if the gas cost for an operation exceeds this fee, the bots will not perform the operation. The UI will display a message indicating if the position is close to the lower limit threshold given the current gas costs.

The security of these operations is of utmost importance, and we have taken rigorous measures to ensure the reliability of our new offerings. Both the Auto-Exit and Auto-Range contracts have undergone rigorous auditing by Hydn, with an audit report that can be read here.

We anticipate that these innovative additions to the Revert toolkit will greatly benefit LPs by providing advanced automation and risk management capabilities. Give them a try from your position dashboard.

In the context of our roadmap with the awarded grant for the Forge integration, we're excited to share that we've managed to complete the first three milestones of our plan. These achievements highlight our commitment to providing enhanced tools, services, and integration to the EVMOS/Forge community as described below.

Milestone 1: Liquidity Incentives Tools

Our first milestone was centered around the deployment of liquidity incentive tools. We successfully launched the vested v3 staker contract on EVMOS. This advancement allows anyone to stake positions and create incentive programs for Forge pools, boosting community engagement and increasing liquidity.

The vested v3 staker frontend, another part of this milestone, is now operational. This user-friendly interface makes it easier for anyone to permissionlessly create incentives programs for Forge pools, and for LPs to stake their positions and be awarded rewards in the respective liquidity incentives program.

The completion of this milestone holds particular significance due to the impending launch of an incentives program, aptly codenamed 'Inferno', on Forge. This strategic initiative is designed to attract liquidity, offering potentially lucrative opportunities for Liquidity Providers (LPs) in this emergent exchange.

Milestone 2: Analytics and Top Positions Indexing

Next, we focused on giving liquidity providers (LPs) the tools needed to track their investments efficiently. We have launched Forge analytics for existing positions, providing LPs with real-time data on profit and loss, annual percentage rate, fees, and more. This information empowers Forge LPs to make informed decisions about their investments.

Moreover, we introduced indexing of top positions. This feature allows users to browse and explore the catalog of existing positions across Forge pools. We believe this will be an invaluable tool for those interested in understanding market trends and gaining insights from top performers.

Milestone 3: Position Management and Auto-compounder

In our third milestone, we have rolled out advanced features for position management. The introduction of an initiator/backtester for Forge pools allows users to backtest and create new positions using the revert interface. This tool is crucial for strategic decision-making, enabling users to gauge potential outcomes before making a move.

We also launched the v3utils contract and frontend, offering utilities for LPs such as swap and mint, moving ranges, and more. These tools further simplify the position management process.

Our auto-compounder contract and protocol, including auto-compounding bots, were also successfully deployed and are currently running. This feature helps LPs optimize their APYs by automatically reinvesting their fees at the optimal times..

Milestone 4: Keplr Integration (Pending)

Our final milestone, the integration with Keplr wallet, is still in progress. This integration is anticipated to expand the accessibility of our platform, offering users a secure, user-friendly, and versatile wallet for managing their assets.

We understand the importance of this integration and will be working with the Forge team to make it happen. We aim to complete this milestone within the next four months.

We're proud of the strides we've made over the last few weeks and are excited for what's still to come. We remain committed to our roadmap and will continue to strive to provide our community with the best tools and services possible.

Stay tuned for more updates as we progress toward our final milestone. As always, we appreciate your support and patience as we continue to improve and expand our platform.

Let’s do a quick review of the functionality provided by the V3Utis contract that is now available on the app:

Swap and Increase liquidity: Takes any amount of token0, token1, or a third arbitrary token and a Uniswap v3 position NFT. It will swap the tokens into the correct amounts according to parameters passed given the position range, pool price, 0x quotes, and max slippage parameters, perform any required swaps, add the swapped tokens into the Uniswap position and return the NFT to the user.

Decrease liquidity and swap: Is the inverse operation, given a Uniswap position NFT and a desired output token, which does not require to be any of the underlying assets, it will decrease liquidity by the amount indicated by the user and perform the swap as defined by the 0x API, and max slippage parameters, and finally return to the calling user the output of the swap(s) as well as the position NFT. It can be performed by any amount of liquidity contained by the position.

Collect fees and swap: This one, similarly, allows users to collect any amount of uncollected fees on their Uniswap v3 position and atomically swap them into any token. Returning, at the end of the operation, the output of the swaps as well as position NFT with the underlying liquidity untouched.

Our team is dedicated to providing the best user experience, and we have responded to users' requests by developing two additional functions.

Swap and Mint: Similar to “Swap and increase liquidity”, it will take any amount of token0 and token1, or a third arbitrary token, and will perform the required swaps to create a position on the selected pool for a position range, it will then return the newly minted position to the user.

Move range: Allows LPs to exit from an existing position into another position in the same pool by atomically withdrawing existing liquidity and uncollected fees, swapping the withdrawn tokens into the correct allocation given the newly selected range, depositing the tokens and minting a new position which is then sent back to the user.

We are currently testing the integration of these new functionalities on the frontend, and they will be shipped soon. Stay tuned!

Mainnet: https://etherscan.io/address/0x94f9FBdf13f19C86D6d07ae500D10e199BC61c4A#tokentxns

Optimism: https://optimistic.etherscan.io/address/0x94f9FBdf13f19C86D6d07ae500D10e199BC61c4A#tokentxns

Polygon: https://polygonscan.com/address/0x94f9fbdf13f19c86d6d07ae500d10e199bc61c4a#tokentxns

Arbitrum: https://arbiscan.io/address/0x94f9FBdf13f19C86D6d07ae500D10e199BC61c4A#tokentxns 

This post aims to explain what happened, provide transparency into affected accounts, and to provide accountability - ensuring verifiable refunding for all affected users -, and an increased commitment of security over fast iteration in our operations and product releases.

How it all went down.

At 2:56 AM CST on the eve of Saturday, February 18th, one of our users posted on our Discord server the following message:

“WARNING: I just had my polygon USDC stolen after approving it via revert's single token add liquidity feature. I have contacted one of the developers about it and waiting to hear back.”

About half an hour later another user posted a similar message. The whole team being in the same time zone (CST), this was not noticed until 6:46 AM when I woke up and reached for my phone. I alerted the team right away.

We immediately disabled the new “Atomic swap into Uniswap v3 positions” functionality from the site.  This feature had been released earlier in the week, and was what being reported as being used by the affected users. If this were an ongoing attack, disabling the Atomic Swap feature would prevent any new users from being harmed.

After disabling the Atomic Swap feature, we started investigating. Inspecting the transactions, it became evident that they did involve our V3Utils contract, and that there was an interaction with a suspicious, unverified, and recently deployed contract. We decided at this point it was best to alert all possible users who might have approved allowances for the exploited contract.  At 7:39 AM CST we posted a Tweet and a Discord message notifying all the members with the possible vulnerable contract addresses and urging everyone to revoke any approved balances.

revert

@revertfinance

mainnet: 0x531110418d8591c92e9cbbfc722db8ffb604fafd
polygon: 0x8c925768c793e00c095135b8656d6014ee2d07bb
optimism:
0x2A017f2Fb369F4CA061B8D8A922Bb05100e8f8C3
arbitrum: 0x95a8cc9ab71b26bdacbe6a7ccf519456edc2a164

7

7:40 AM • Feb 18, 2023

As  part of the team focused on working with users to answer questions about the revoke process, the rest of the team worked to diagnose the exploit while also writing code to identify and mitigate any other accounts that  could be potentially be at risk (given previously authorized allowances).

Tenderly proved to be an invaluable tool for understanding the exploit. Using Tenderly, our team was able to identify the attack vector:

• The V3Utils contract relies on an external aggregator to do the swaps. Our frontend calls this API with the tokens and amounts intended for swapping, and the API returns the swap parameters sent to the V3Utils contract.

• There are two important values included in this API response, the contract which works as a router for the swaps, and the contract to approve the tokens for the actual swap. Because these values are dynamic and can be changed at any time with new versions of the aggregator, we had decided not to hard code them in our contracts which was designed to be ownerless and immutable.

• By inspecting the reported transactions it became clear that the swapRouter parameter was used as the vector for attack. The swap function was called using a token contract (like USDC) as the router parameter, which allowed the attacker to execute arbitrary code against that contract with our own V3Utils as the caller.

• This means that any previously authorized allowances to the V3Utils contract were vulnerable to being drained. Because our frontend only prompts for approval of the amounts to be used as deposits the remaining allowances mostly remain at zero and so not vulnerable. In some cases, however, accounts approved amounts larger than what was swapped leaving them open to be drained by these malicious transactions.

At 8:46 AM, once we verified the exploit was tied to the V3Utils contract, we once again  pushed a notification to all Discord members -  explaining the diagnosis of the exploit and urging everyone again to check and revoke any allowances to the affected contracts.  We relayed the same information via our official Twitter and Telegram  accounts.

revert

@revertfinance

We have confirmed that this was an exploit to our v3utils contract used in the new "atomic swap into v3 position" functionality. Here is an inital explanation of what happened

revert

@revertfinance

We have gotten reports from 2 users about an attack involving approvals to our v3utils contract. We are investigating and will report further.
We recommend using revoke.cash for following addresses:

25

8:48 AM • Feb 18, 2023

At that point we had tallied up that there were allowances for the V3Utils contract the low hundreds of thousands of dollars. We urged everyone to echo our information on all channels possible and a lot of the community was there to help amplify the message. We added a bright orange banner to the top of the website that would display to the vulnerable accounts that their funds could be at risk.

Alerting our community of the situation was successful, we quickly started seeing allowances revoked, and a few minutes before 12pm we saw the single largest one was revoked.

revert

@revertfinance

The biggest open pending allowance has revoked permissions!

revert

@revertfinance

Would help to spread the msg for accounts to revoke permissions for:
mainnet: 0x531110418d8591c92e9cbbfc722db8ffb604fafd
polygon: 0x8c925768c793e00c095135b8656d6014ee2d07bb
optimism:
0x2A017f2Fb369F4CA061B8D8A922Bb05100e8f8C3
arbitrum: 0x95a8cc9ab71b26bdacbe6a7ccf519456edc2a164

12

12:08 PM • Feb 18, 2023

After these wave of revokals, the total vulnerable allowances were down to close to $30k USD, a considerable but much less catastrophic amount. We also knew that the total amount stolen from victims was also close to but under another $30k, with $25k being from a single user who had reported the attacks on mainnet.

Whitehatting it

The following day, by midday Sunday, February 19th, there were still close to $20,000 USD of unrevoked permissions across all networks. We’d  taken every measure possible to  contact the possibly affected users, and  decided that focusing on deploying a way to whitehat vulnerable accounts would be the best possible thing to do. We deployed our own attacker contract and started running a bot that would monitor any transfers into the vulnerable accounts to execute the described attack ourselves for refunding the users. This worked and we were able to get small amounts of tokens before the attackers and were used as part of the refunding.

By the end of the weekend, only a few thousand dollars that users had not revoked remained at risk though ready to be captured by our counter measure bot.

Lessons learned & moving  forward

First, we want to apologize to all of our users, particularly those that were a victim of this exploit. At Revert Finance, our mission aims to empower our users, AMM LPs, and ensuring the safety and security of the tools we provide is paramount to achieving that.

This exploit was disappointing, painful and frustrating for us, but more importantly for those affected – and does reflect the way we aim to operate here at Revert.

We sub-estimated the this contract could present for our users. Since it was not a contract that would hold user funds, we assessed incorrectly that it was less of a risk and hiring a full audit was not necessary.

This is contrary to our other deployed contracts, the auto-compounder which was audited by Peckshiend before deployment and has a running bounty for $100k on immunefy, and the time-vested v3 staker where a full audit was also conducted by PeckShield before deployment.

Going forward, and before resuming functionality of the affected contract, all of our deployments will receive a proper external audit, but more importantly we will not make the same mistake of assuming any contract that handles user funds, even temporarily, is less of a risk. While the “move fast and break things” philosophy is tempting when you are simply providing analytics, when smart contracts are involved “move at a steady pace and be very mindful of the things” is the only sensible approach.

Finally we would like to express sincere gratitude to our users, and the different folks who reached out to us privately offering their help and support. We will not forget it.

---

The affected accounts

Below is a list of accounts with the amount of tokens that were withdrawn with the exploit, and the script we used to determine the amounts. Those same tokens and amounts have been now airdropped back as a refund from this account on each respective network. This script we used to generate the list of attacked victims.

MAINNET 0x067D0F9089743271058D4Bf2a1a29f4E9C6fdd1b USDC 19305.581627
MAINNET 0x4107A0A4a50AC2c4cc8C5a3954Bc01ff134506b2 USDC 500
MAINNET 0x067D0F9089743271058D4Bf2a1a29f4E9C6fdd1b USDT 4106.316699

OPTIMISM 0xbB8694519BC68B337663F0BDbE79847b49000b6B OP 403.5786287699002
OPTIMISM 0xD5dE81E7e5E4F740a26Ebb254d6052e1D03B4787 OP 32.00000000000003
OPTIMISM 0xD5dE81E7e5E4F740a26Ebb254d6052e1D03B4787 USDC 228.935843
OPTIMISM 0x89425a801dbbacD4562638161198b6d3b85A314c WETH 0.06919111687156008
OPTIMISM 0x50EE407e77EBfD8A6b0F22AC74719f63C8a0A7Db USDC 36.736549
OPTIMISM 0x8cadb20A4811f363Dadb863A190708bEd26245F8 DAI 10
OPTIMISM 0x5C0843066F64aA0D9858611401cD2DD6F2e1f7E4 DAI 17
OPTIMISM 0x50EE407e77EBfD8A6b0F22AC74719f63C8a0A7Db WETH 0.003659440712231981OPTIMISM 0x5C0843066F64aA0D9858611401cD2DD6F2e1f7E4 PREMIA 22
OPTIMISM 0x50EE407e77EBfD8A6b0F22AC74719f63C8a0A7Db USDC 106.557557
OPTIMISM 0xD5dE81E7e5E4F740a26Ebb254d6052e1D03B4787 USDC 6
OPTIMISM 0xe48fE6012f97b6A13C0Ce5cEF314cAF66E972deB USDC 41.296177

POLYGON 0x4E23d9Bb84359e2a20D3aBC6985d6c55c37062D6 WMATIC 15
POLYGON 0xb9B69B3B969E8Fa9EcF9815b396A77fB53267ED1 WMATIC 3.5972237426468854
POLYGON 0x225170393fCD06F3295aDa2bF33002C8ec94b8E4 USDC 194.316778
POLYGON 0x8cadb20A4811f363Dadb863A190708bEd26245F8 WBTC 1e-8
POLYGON 0x859Bb79038C20F09A7Ad5726e036028f301d5de6 USDC 0.76822
POLYGON 0x0B82F6a646cD5C07da58EBDDBd8b21caBD9E3632 USDC 111.918734
POLYGON 0x31Df5f1437eC5fA7BE165a84ED9635e9b0f57536 USDC 373.40421
POLYGON 0xD2eDb935FE14C80747E782FA870116D5E1C1E744 USDC 158
POLYGON 0x225170393fCD06F3295aDa2bF33002C8ec94b8E4 USDC 922.439314
POLYGON 0xD2eDb935FE14C80747E782FA870116D5E1C1E744 USDC 664.599662
POLYGON 0x5593095740485D30cd2171Eb12a1F174A1Ccb085 USDC 165.702693
POLYGON 0xb7A3E33A76c359349a2aED0A7833DCDB3E2D8337 WMATIC 0.004956763791274464
POLYGON 0x637c25D0f2CCa040D025e4c5b0332e6146869C56 USDC 6.488701
POLYGON 0x637c25D0f2CCa040D025e4c5b0332e6146869C56 DAI 7.590931982602232
POLYGON 0xA0f7F9F79f619BD86849747Be69Fb7a257fF01C0 WBTC 0.00000679
POLYGON 0x8cadb20A4811f363Dadb863A190708bEd26245F8 USDC 0.7853
POLYGON 0xA0f7F9F79f619BD86849747Be69Fb7a257fF01C0 oMATIC 0.21822824027535612
POLYGON 0xA0f7F9F79f619BD86849747Be69Fb7a257fF01C0 USDC 0.02
POLYGON 0xA0f7F9F79f619BD86849747Be69Fb7a257fF01C0 WBTC 0.00046135

ARBITRUM 0xf6b9Cb280Ae3c5dd5eC22D7A1A2A7f5F0a1AE879 USDC 200
ARBITRUM 0x19D32180BC2210eA3b500553d3Db90ef248A38f3 WETH 0.08983629296701101
ARBITRUM 0x7C14D5dB2A4417901E45D2Ab7fE33D916d18F0e1 WETH 0.01
ARBITRUM 0x19D32180BC2210eA3b500553d3Db90ef248A38f3 WETH 0.005984559978510494
ARBITRUM 0x5A12D9cd39Bc86C510aDA067F662c7bf796f8De6 WETH 0.002690670523787123

The Attackers

On a post-mortem analysis we have determined that there were five EOA accounts involved in the attack. This information has been forwarded to Chainalysis for inclusion in their database.

MAINNET: 0x38F887a0FE01b9e4960D5C727519408fA7f32F70

The first funding transactions for this account comes from a multi-chain bridging from BNB chain, where that account was originally funded on August 30th, 2022 via tornado cash.

POLYGON: 0x31487bBD8c2E79465940CC07DEc049dC0845331B

The first funding of this account was via a bridge called AnySwap, and this account was also funded via Tornado Cash on the same date as the mainnet attacker account, August 30th. Given this, it seems apparent that at least this one and the mainnet accounts belong to the same attacker.

OPTIMISM: 0xF93CEE8fdbC59BcA3A74A2F08d60a3e366E4768c

This account appears to also have been first funded on BNB, but through a centralized non-custodial exchange called FixedFloat on February 14th. This same account also performed the same attack on the Arbitrum contract.

OPTIMISM: 0x9b6Bb041B79B83b2dF1839d51Cd654cc6444e852

This account was originally funded on Optimism via the HOP bridge on October 12th 2022 from Ethereum. On the Ethereum the account was originally funded on the same day (October 12th) by account 0xbce37312886b43721bf488bda0f5d58871b310cf That account in turn was first funded on June 7th 2021 by account 0xb7f830845e9f385372ae6fb160aa968908f5bfbc which has a long history across several blockchains due to the huge number of transactions Etherscan does allow to paginate that far back, but trackable for sure by inspecting the blockchain.

OPTIMISM: 0x5504790a2426A312194270C7a7443a54AF9F75AE

This account can be traced back to Ethereum where it originally bridged from on December 13th 2022. That account itself was originally funded on the same day by account 0xc5e3605480fad6b9acb84585fb56860c835f6dd7, that account was funded by account  0x077d360f11d220e4d5d831430c81c26c9be7c4a4 on December 02 2022. That account has a long history across chains and the original funding is unavailable on ethersan.

Not included in the list above is our own bot 0x54ab50dd18305e4280e41af1923b38835363ecf1 which white hatted a small portion of funds on Optimism, Polygon, and Arbitrum.

If any of the above addresses was also performing white hatting service, please return the funds to this account: 0x54ab50dd18305e4280e41af1923b38835363ecf1 Keep 20%. No questions asked.

I have 5000 USDC and I want to add them to my ETH/OP position. To do that I end up doing two or even three swaps, some in opposing directions, and even after that, I am left with change and just give up.

Indeed, that is a pain point we’ve felt as well, and have built a solution for.

One of the challenges in adding liquidity to existing positions on Uniswap v3 is getting the assets you want to add to the correct ratio required. This is because the price of the assets is constantly changing, and the correct ratio is dependent on the current price of the pool as well as the position range. And if you are swapping into the same pool with sufficient price impact, the calculations get even more tricky.

Using Revert you can now add liquidity to an existing position using any amounts of the underlying assets, or even any third arbitrary token. Revert will automatically compute the required amounts that need to be swapped for each of the token pair assets, get the best possible quote using the 0x API, and atomically do the swap and add the liquidity to your positions.

We’ll conveniently do the same in the way out if you want do “withdraw and swap” or “collect fees and swap” for any mounts into either one of the assets or again an arbitrary third token.

This all happens atomically on-chain, we are making use of v3utils.sol, a contract we have published for this purpose, and the 0x protocol to handle any required swaps, so for LPs can confidently use this functionality even when they are providing liquidity for relatively small pools.

How does it work?

We have implemented three basic operations defined by v3utils contract.

Swap and Increase liquidity: Takes any amount of token0, token1, or a third arbitrary token and a Uniswap v3 position NFT. It will swap the tokens into the correct amounts according to parameters passed given the position range, pool price, 0x quotes, and max slippage parameters, perform any required swaps, add the swapped tokens into the Uniswap position and return the NFT to the user.

Decrease liquidity and swap: Is the inverse operation, given a Uniswap position NFT and a desired output token, which does not require to be any of the underlying assets, it will decrease liquidity by the amount indicated by the user and perform the swap as defined by the 0x API, and max slippage parameters, and finally return to the calling user the output of the swap(s) as well as the position NFT. It can be performed by any amount of liquidity contained by the position.

Claim fees and swap: This one, similarly, allows users to collect any amount of uncollected fees on their Uniswap v3 position and atomically swap them into any arbitrary token. Returning, at the end of the operation, the output of the swaps as well as position NFT with the underlying liquidity untouched.

Coming Soon, Swap and Mint: Atomically swap and mint a position.

And obvious missing piece here is this same idea of atomically swapping any asset into a determined Uniswap position, but instead of increasing liquidity on an existing position, create a new position that you don’t already hold. Fret not, we are on it, testing, and expect to ship it out in a few more days fully integrated to the revert initiator.

Available now

The features described above are already available on the site and across all chains. We are looking forward to your comments and feedback as you try them out. Follow us on Twitter or drop in on our Discord to stay updated.

Another pair of variables totalRewardX64 and compounderRewardX64 determine the amount of fees the protocol charges and how much of that the protocol pays to the compoundor bots that execute the auto-compound function. These parameters have not been changed since the contract was deployed and are currently set at 2% for the totalRewardX64 (this parameter can only be reduced and never increased) and 1% for the compounderRewardX64 (this parameter can be decreased or increased, but it can never be greater than totalRewardX64). More clearly, this means that right now when a position is auto-compounded, 1% of the compounded fees go to the Compoundor protocol, and the other 1% goes to the people running the compoundor bots.

When we launched the Compoundor protocol our team was really the only one running auto-compounding bots, but we published and open sourced our bot implementation expecting other people might want to run them, learn from them, and perhaps accrue some profit by auto-compounding positions.

And indeed that did happen, to the point where we just kept our bots running as backstop in case other bots did not compound positions first, but that is a rare occurrence now.

On one hand this is great, we believe the resilience of the protocol is theoretically increased by compoundor bots running independently of ours. On the other hand there are some downsides to this.

First, in full honesty, we (Revert, the company) are leaving some revenue on the table by giving 1% to the bot operators for a task that we have to be prepared to do anyway.

Our stated mission is to build powerful analytics tools for liquidity providers in AMM procools while keeping them open and accessible to everyone, for this reason we have avoided doing things like paywalls and our roadmap includes revenue generating features that are aligned with our mission.

Going back to compoundor bots, a simple way to increase company revenue, without increasing costs for our users, is for us to take over the role of running them exclusively.

Additionally, as explained in our whitepaper, auto-compounding has diminishing returns. This is to say that the APY increase from auto-compounding most positions is not significantly increased if a position is auto-compounded 4000 times per year, instead of 400 times per year. While these excessive compoundings don’t represent an extra cost to the LPs, as the fee is 2% of what is compounded regardless of the compounding frequency, there are some externalities to consider:

• Unnecessary load on chains: as mentioned above, increasing the number of auto-compounds above a certain threshold does not significantly increase the APY for positions, but does result in more transactions being included in the respective network.

• Unnecessary load in tracking positions: every collect and deposit transaction implies additional resources being spent in tracking the positions.

• Excess balances mixed between positions: In some cases, because the uncollected fees and the positions being compounded have different ratios in token0 and token1, excess balances can be left in the contract assigned to the position owner. These balances are there to be used in future compoundings for positions from that same LP account, and if an account has more than one position that share an asset (like ETH), excess balances accrued from one position can be used to compound another position (owned by the same user). This can be avoided if Compoundor bots swap the accrued fees to the correct ratio, but this implies an extra gas cost that compoundor bots can decide to avoid.

• UX confusion: Though the unnecessary compoundings do not imply any additional cost (gas or otherwise) to the LPs, we do get a lot of questions as to why positions are compounded with this seemingly excessive frequency.

The changes we are making to the Compoundor parameters

We will be leaving totalRewardX64 as is, but will be setting compounderRewardX64 to zero**.** What this means is that external compoundors are not incentivized to run the compoundor bots and that responsibility will be taken over by our team only.

The team will also run the bots so that we maximize APY improvement for positions, but also reducing the negative externalities mentioned above. Additionally, and not to minimize this, the revenue generated by the Compounder bots will be accrued fully by Revert.

When will this be executed?

Any change to the Compoundor contract parameters requires a 24-hour time-lock to take effect, but we will also be allowing for a few more days, and notifying the folks we know running compoundor bots of these changes so that they can stop their bots, as otherwise they would be only paying gas costs without any revenue to make up for it.

Does this mean that Revert Compoundor is becoming more centralized?

The compoundor protocol is at the moment trustless and with minimal governance required, but it is not decentralized as the parameters, and the protocol revenue, is controlled by the team and not any form of DAO.

What comes next?

As we progress in executing on our roadmap, and a next version of the Compoundor, we will be releasing an additional set of features where it will perhaps become more important to decentralize governance of specific parameters and we will most likely do so.

What effects will this have on LPs that are auto-compounding?

The changes should be mostly unnoticeable for LPs. The Compounding APY will not be reduced even though they might notice less frequent compoundings for their positions. There are no new or additional costs for Revert users.

Compoundor bot runners will not be happy

We understand this is not great news for folks who have been running Compoundor bots and we did not make this decision lightly. But we believe this change will help in keeping with our stated mission of building powerful tools for LPs in AMM protocols while keeping them open and accessible to everyone. Again, we believe as we execute on our roadmap throughout the year there will be new opportunities for external parties to help in protocol automation.