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.
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.
Open your position on revert.finance.
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.
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.
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.
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:
Date | Action |
|---|---|
June 27 | Operator bot stopped executing on the old contracts on mainnet, Arbitrum, and Base |
July 5 | Fixed contracts deployed on all three chains, ownership transferred to the chain multisigs |
July 5 + 48h | Vault allowlisting of the new contracts executed through the Arbitrum and Base timelocks |
[DATE] | Old contracts removed from the vault allowlists on all three chains |
New contract addresses, verified on the block explorers:
Chain | Old Auto-Range V3 | Fixed Auto-Range V3 |
|---|---|---|
Ethereum |
|
|
Arbitrum |
|
|
Base |
|
|
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.
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.
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.