Analysing the OPEN Q3 Rebalance
In this post we’ll deep dive into why the OPEN Q3 portfolio rebalance failed to reach its target allocations. Our findings show the root cause to be a flawed auction mechanism, which led to the sandwiching of the rebalance swaps, trades failing to execute, and tokens being oversold or overbought.
What is OPEN?
OPEN is a community-governed index of stablecoin infrastructure tokens. vlSQUILL token holders vote on which tokens are included and quarterly rebalances align the portfolio to an equal-weighted allocation. Under the hood, OPEN leverages Reserve Protocol’s Decentralized Token Folio (DTF) smart contracts to manage the index and its rebalances.
What is the Reserve Index DFT Protocol?
Reserve’s DTF protocol is a system of smart contracts for managing token portfolios, including functionality for minting, redeeming, and rebalancing.
In the Reserve Index DTF Protocol 2.0.0, a portfolio rebalance is first proposed, then voted on, and finally executed over an auction period. Each proposed rebalance trade must specify a pair of two tokens to be sold/bought, as well as the min/max amount of each that can be sold/bought. It’s necessary to specify a range, as this gives the auction mechanism enough leeway to execute over the auction period. If the range is too tight, price movements between auction proposal, start, and end could cause the trade to fail to execute. To avoid such failures, the Reserve App allows a price range to be set according to the Expected Volatility (EV) of the token.
The Rebalance
When the Q3 rebalance vote passed it had two stated aims:
“(1) adding FXN, OGN, ALCX and removing ENA from the OPEN basket and (2) equal-weighting the basket 10% per each of the ten constituents.”
However, following the rebalance the target weights had not been met.
The following table shows the change in token balance and value before and after the rebalance:
As we can see, the rebalanced portfolio was overweight OGN and SKY, whilst being underweight everything else.
We attribute the failure of the rebalance to two primary causes:
- Losses due to poor execution
- Incorrect allocation due to price volatility
Although the net portfolio value actually increased when comparing the before and after, this is attributable to the rise in token values during the rebalance period. The rebalance itself lost value for the portfolio in avoidable ways, which we will now detail.
The Execution
The rebalance incurred losses due to poor execution, with value being extracted by MEV bots sandwiching transactions.
The OPEN Q3 rebalance vote was proposed on July 6th, 2025 and was executed four days later on July 10th. During this time there was significant volatility in the market, which led to token prices drifting considerably from where they were at the proposal of the auction. As a result, stale prices were used for the auction, which is equivalent to setting slippage very high. As the swaps were broadcast to the public mempool, MEV bots were able to sandwich the transactions, leading to poor execution prices.
For example, trade 3 was intended to sell all 140,115.5542059 ENA for a specified minimum amount of FXN, expressed as a range of buyLimit values. In the time between proposal and execution, the price of FXN rose 49% whilst the price of ENA rose 27%, a considerable deviation in the relative prices of this pair from when the proposal parameters were set.
In this transaction, 44,369.92 was sold for 148.69 FXN through the ENA → WETH → FXN route, settling at a relative price of 0.00335 FXN per ENA. At this time, ENA was trading for $0.3015, whilst FXN traded for $82.60, so the relative price should have been approximately 0.00365 FXN per ENA. However, the order had broadcast a willingness to accept a lower price, effectively setting a high slippage tolerance. An MEV bot took advantage by sandwiching the trade to extract the difference between the actual market price and the lower price which the auction would accept, with OPEN losing 7.11% in slippage.
This poor execution was repeated across other swaps, resulting in avoidable losses.
Our analysis of token flows estimates that approximately $4382 of value was lost during the rebalancing process, the majority of which was lost on the ENA/FXN pairing. This is understandable, given that FXN had the greatest price volatility and the lowest liquidity of all the tokens and is therefore most susceptible to sandwich attacks.
A detailed analysis of the ENA->FXN trades shows the losses on each swap during the auction:
In summary, the root cause of the poor execution was that the auction mechanism led to poor price setting whilst the swaps were executed without any MEV protection, exposing the rebalance to value extraction.
The Allocation
The portfolio ended up greatly overweight in OGN, slightly overweight SKY, and underweight all others. Aside from losses incurred due to poor execution, this is due to some trades not executing, whilst other tokens were oversold/bought.
Volatility in the relative prices of the pairs between the auction proposal and end meant that some of the max/min sell/buy limits could not be respected. As a result, of the 10 approved trades only 6 executed:
- LQTY → ACLX - Executed
- AAVE → OGN - Executed
- ENA → FXN - Executed
- SKY → CRV - Not executed
- LQTY → FXN - Not executed
- FXS → OGN - Executed
- SKY → RSR - Not executed
- INV → OGN - Executed
- LQTY → RSR - Not executed
- LQTY → OGN - Executed
As SKY was not sold, this led to an overweight allocation, whilst RSR and CRV were not bought, leaving them underweight.
This volatility also led to some tokens being oversold/overbought. If multiple trades selling/buying the same token execute using close to the max sell/buy limit, the token can end up being oversold/bought in the portfolio as a whole. The more trades there are involving the same token, the more likely this outcome will be. The problem here is that each token pair trade has no context about the result of the other trades and so cannot adjust accordingly. In this case, OGN was overbought whilst other tokens were oversold.
Variations in prices during the auction period can also leave tokens under/overweight by the end, even if the correct amount was traded. For example, if near the start of the auction a 10% allocation in a token is achieved, by the end of the period price movements could bring this down to 9%. This effect also contributed to the misallocation.
In summary, the root cause of the misallocation is that the rebalancing was done on a token pair basis, which introduces significant complexity and unpredictability into the auction. Due to the large number of variables at play, it is very challenging - if not impossible - to define limits and pairings correctly several days in advance to achieve the target allocations for a holistic portfolio rebalance.
The Upgrade
Reserve has recognised these flaws in the auction mechanism and is rolling out an upgrade to 4.0.0 to introduce three principal changes:
- Rebalancing the entire basket holistically
- Using CoWSwap to fill MEV-protected orders
- Enabling more flexible control of price ranges
By rebalancing the portfolio as a whole to reach target allocations, market participants can bid on any surplus:deficit token pair until the tokens in the basket reach their respective target ratios. This mitigates the impact of volatility in the relative prices of arbitrary token pairings during the auction process and ensures the target portfolio allocations are achieved.
Reserve is also introducing the concept of Trusted Fillers, who are tasked with finding optimal routes to fill rebalance trades. CoW Swap will be the first filler to be integrated. This ensures that bids remain competitive, with optimal execution achieved through CoW Swap’s best-price guarantees and access to deep liquidity. As CoW Swap trades are MEV-protected, they should not be vulnerable to sandwiching as before.
Lastly, the new system allows for greater flexibility when setting price ranges. Similar to before, when a Rebalance Manager proposes a new rebalance they will specify new basket tokens, target ratios (limits), and price ranges for each asset. However, for a restricted period, the Auction Launcher has the ability to fine-tune parameters within governance-set bounds. For example, if a token’s price had risen since proposing the rebalance, they could raise the token’s starting price for the auction.
Conclusion
In conclusion, the OPEN Q3 rebalance incurred avoidable losses and failed to meet target allocations, as it suffered from poor execution and misallocation due to flaws in the Reserve Index DTF Protocol 2.0.0 auction mechanism. The upgrade to 4.0.0 introduces mechanisms intended to provide better execution during rebalances and ensure target allocations are achieved. With the vote to upgrade to v4 already passed, we look to the next rebalance to see if the new mechanisms have the intended effect.
About us
Pangea is a permissionless orchestration layer for self-sovereign infrastructure providing colocated streaming for the most demanding workflows.
Our data analysis tooling and DeFi expertise alerted us to the MEV activity in the Q3 rebalance and facilitated our investigation. To find out more about how we can help with your data and infrastructure needs, reach out on our socials.
12 tokens proposed
Only 10 make the index
vlSQUILL holders decide
wannabe currently working for the Aave-chan initiative where I mainly write part of the code so that the AAVE DAO’s will can be executed on_chain permissionlessly. (BTW I wrote a smoll utils to make proposal for the $OPEN governance)
