Reweight Without Reweights (using cumulative deviation)

[4/12 update: normalized by (1-\delta) so that A(t) and C are in the same unit as the price]

A dilemma is that we need reweights to happen in order to keep the peg, but we lose PCV with each reweight. To be precise, each reweight makes permanent the temporary loss in PCV that was accrued while price of FEI was decreasing. This is why we need to reweight without reweights; we need to make sure that everyone expects a reweight to happen when price is low, so that they buy FEI and prevent large reweights from occurring in the first place. Let me propose a simple reweight mechanism that does exactly this and satisfies a number of other desirable properties.

Reweight based on cumulative deviation

Assuming price is below 1, let m_t be the price distance from peg at block t:

m_t=1- (\text{price of FEI at block $t$})

Suppose T-1 is the most recent block at which price was 1 or above. Then the cumulative deviation at block t > T is defined as

A(t)=(1-\delta)\left(m_t+\delta m_{t-1} + \delta^2 m_{t-2} + \cdots + \delta^{t-T}m_T\right)

where \delta is a time discount parameter between 0 and 1. A(t) is thus a measure of the severity of price disparity in terms of how low the price is and how long it has stayed low.

A reweight is triggered at block t+2 if and only if A(t) > C for some threshold C.

This is a very simple mechanism, with no need for burns or mints. But it has a number of useful properties.

1. Reweight occurs immediately whenever price is low enough.

Reweight occurs immediately (in two blocks) whenever price is less than 1-\frac{C}{1-\delta}, since regardless of the history of past prices, A(t) is greater than C.

For example, if C=0.001, and \delta=0.99, then any price below 0.90 would immediately trigger a reweight.

2. Given any price below 1-C, if this price persists for long enough, reweight occurs.

If the price remains constant at p < 1 for a very long time, then cumulative deviation approaches


which means reweight should occur eventually as long as


For example, if C=0.001, then any price below 0.999, if it persists long enough, will eventually trigger a reweight. We can interpret C as the minimum price distance that we are willing to allow to last indefinitely without triggering a reweight.

3. Whenever a reweight occurs, the loss of PCV is arbitrarily small.

Suppose the reweight threshold A(t) > C is met at block t. Then everyone knows that a reweight will occur at t+2. So arbitrage should push the price to 1 at block t+1. This means the size of the actual reweight at t+2 will be extremely small.

4. Whales with bots cannot profit by triggering a reweight himself

When price is below 1, a whale might consider the following attack: sell just enough FEI at block t to send A(t) above C and immediately trigger a reweight, buy a large amount of FEI at t+1, and then sell after reweight at t+2. But as explained above, every other whale with a bot will observe that a reweight has been triggered and compete to buy at t+1 and sell at t+2. Gas auctions should drive the profit from this attack to zero.

5. Reweights are rare.

Suppose A(t) is close enough to C such that without a price increase, A(t) will be greater than C at t+1. Then arbors will anticipate a possible reweight and buy FEI at t+1. Other arbors will anticipate these arbors and also buy at t+1. This will bring the price closer to 1, reduce A(t), and prevent a reweight.

6. No need to worry about vulnerabilities in direct incentives.

Finally, this mechanism can be implemented without fixing the vulnerabilities in the direct incentives, since it does not rely on minting or burning FEI.

As an aside, the direct incentives of mint and burn have no impact on supporting the price; they simply increase the effective swap fee as price goes down. It will certainly be useful to optimize the swap fee that accrues to the PCV, since the PCV has a huge market power as the biggest liquidity for FEI. But this is not really relevant for the immediate task of pegging.

It may come as a surprise that direct incentives are unimportant. After all, wasn’t the FEI project all about using incentives to achieve under-collateralization? In fact, FEI is indeed based on incentives, but these incentives come from the automated market maker (AMM). The difference between FEI and USDC is that USDC is always redeemable 1:1, while FEI is redeemable through the Uniswap AMM. This ensures that whenever the price is lower than $1, sellers get less than $1 per FEI and buyers get more than 1 FEI per USD. In my view, this is the novelty of a FEI.


Thanks for being proactive. I like this proposal. I wonder how long this would take to implement with audits if it was supported by the community?


I unfortunately have zero knowledge about developing, so I don’t really know. Maybe others can shed some light. But I am hoping that it can actually speed things up, since we won’t have to worry about fixing the vulnerabilities. The community would need to decide on the parameter values, C and d.

1 Like

I fail to see how this is significantly different from the system that’s described in the white paper. What am I missing?

As far as I can tell, what it achieves is that reweights are triggered after the price is too far below the peg and/or after the price has been below the peg for too long. The longer the price has been below the peg, the smaller the price deviation needed to trigger a reweight.

If you take a look at the docs (UniswapIncentive - Fei Protocol), the original implementation is that reweights can be triggered exactly when the burn incentives are as large as the mint incentives. If m is the distance from the peg and t is the time off peg, then this is achieved exactly when 100m = w(t), where w(t) is the time weight function. The time weight function grows linearly at a rate of r = 75/100,000 per block for as long as FEI is off peg. Moreover, the time weight function is reduced whenever there’s a buy below the peg, “prorata… based on percent toward the peg.”

This means, whenever m > w(t)/100 (and so the price is too far off the peg), a reweight can be triggered. And whenever w(t) > 100m (and so too much time has passed below the peg), a reweight can be triggered. I get the sense that what you want to achieve with this proposal could be achieved by tweaking the severity of the time weight function w(t). It’s not clear to me that that’s necessary yet.

I think the question of what the right choice of w(t) is an extremely interesting one. It’s by no means clear that a linear increase that is ameliorated by buys under the peg is the optimal choice. I asked about this in the Discord about a month ago. Joey told me that the reason for these choices is that they’re simple to implement. To me, this means there’s still an opportunity to derive an optimal choice of w(t). It seems like your proposal indirectly does this when you define A(t). Except A(t) depends not only on t, but also on A(t-1) and on the deviation from the peg at time t.

Also, how’d you manage to include those nice mathematical expressions? Can we use Latex in this forum? I’d be excited to know we can!

1 Like

Thanks for the comments.

In the original mechanism, w(t) starts from 0 and increases so that reweight is triggered when w(t) hits 100m. This did not work very well for two reasons. First, this means that when m increases, it actually takes longer for w(t) to reach 100m. Second, as you mentioned, buying below the peg reduces t. But selling below t does not increase t. This means that whenever price fluctuates, t is reduced. And since price tends to increase when a reweight is about to happen, reweight was pushed back for a very long time. These two reasons are why we only had something like two reweights even though market price (at secondary markets) was often below 0.80 for hours.

Initially, most people including myself approached this problem by keeping the mint/burn framework and trying to fix the two problems. I don’t think we were able to find a very appealing solution. But more importantly, mint/burn does not play any role in supporting the peg, and only serve to increase the swap fees that the pool receives. It is still reasonable that we may want to keep mint/burn in the long term for the purposes of maximizing swap fees that goes to the PCV. But this is a long term issue, and there is really no reason for the reweight trigger, which is about pegging, to depend on mint and burn. If we want reweights to happen when price is low for a long time, I think it is better to simply make the reweight happen as a function of price and time, rather than going through intermediate steps.

As for the expressions, I just typed on Latex and uploaded screenshots :sweat_smile:. Would be very convenient if we could type directly here!

I see. It does seem like a significant difference. It seems like by design we always have 100m \geq w(t) (I guess I’ll just have to use aspirational latex. So when m increase, we move further away from a reweight.

I’m not sure that’s entirely undesirable. After all, the further away from the peg, the more expensive the reweight. So it seems prudent to extend it’s hope for direct incentives to come back closer to peg throug direct incentives before triggering a reweight. I’m not sure if this was intentional or not, but it doesn’t seem like an unreasonable decision. That said, you might be right that this is not desirable. I’m not at all sure. And now I do see that your solution addresses the problem of the price of reweights by introducing a delay between the announcement that a reweight will happen and the actual reweight.

What’s led you to be convinced that minting/burning do not play an effective role in supporting the peg? Of course, they weren’t successful in the first couple of days after launch. But they were operating under extreme sell pressure. And the implicit reward of mints (that FEI would eventually be sellable at $1), hadn’t been realized yet. It could be the case that minting/burning do not shine as bootstrapping mechanisms, but do work effectively in the long term.


I like the idea of signaling an upcoming reweight and wait for x number of blocks before the reweight actually happens. This gaurantees an arbitrage opportunity, and arbigurs will drive up the price, and this will greatly reduce the cost of reweight to PCV.

the A(t) equation sounds like a good way to measure both distance to peg and time under a peg and finds a balance between the two. It’d be nice to find a way to test this so see it in action without using real money :sweat_smile:

I think the burning mechanism is the crux of the problem, it punishes free market in order to keep a peg, it was demonstrated to be ineffective. If burn has to go, then mint also need to go, which means DI is gutted. I think that with a different design to the reweights (with no DI), it might still work.

An easy crude way is to to just have regular reweights at preset time. Although it will surely favor the bots and arbs. It will make FEI the best bot playground in town, which it already was. I don’t think this can be avoided tbh.


I see that one might prefer a delayed reweight if the reweight is expensive. But I think as long as the reweight is expected, it should become cheap as soon as soon as bots realize it and push the price up. In the beginning, before there are enough arbers, maybe we want reweight to happen at something like t+100 rather than t+2. This would give enough delay for people to buy, even for small investors, while retaining the property that extreme price deviations are handled more quickly (not necessarily by a reweight, but by the organic trading that happens in expectation of a reweight).

I know this is not a widely shared belief at the moment, but I am 100% convinced that mint/burn can never incentivize the buyer while punishing the seller. Whenever you make the seller incur a burn (sales tax levied on the seller is a typical example in the real world), this always hurts both the seller and the buyer. Suppose a seller and a buyer were willing to trade at 1 without any burn/mint. They are happy with this trade because the seller is willing to sell as long as he gets at least 0.80, and the buyer is willing to buy as long as he pays less than 1.20. If we set the burn to be 0.25 per token (let me use absolute values instead of percentage for ease of exposition), then the seller knows that if he sells at 1, he will only receive 0.75 after incurring the burn. So he might raise the price to 1.10. The buyer is still willing to buy, so the trade still happens. But both the seller and the buyer are worse off, even though the burn was applied to the seller only. And notice that the burn (0.25) was smaller than the difference of 0.40 between the buyer’s willingness to buy (1.20) and the seller’s willingness to sell (0.80). If the burn had been greater than 0.40, the trade would not have happened at all.

It is a well known principle in economics (“tax incidence”) that it does not matter who incurs the burn. Whether you impose it on the seller or the buyer, the punishment will always be born by both of them in a certain ratio that depends on how much the two people are willing to trade at a disadvantageous price (formally, the ratio depends on price elasticities of supply and demand). Likewise, if you subsidize a buyer or a seller by giving them a mint bonus, the two will share the bonus in the same way regardless of who you give it to.

So suppose we make the seller pay a burn of 0.25 and give the buyer a mint of 0.10. Then the net result is that the seller and the buyer share the net burn of 0.15. This is identical to simply making one of them pay a burn of 0.15. There is no way to punish one while rewarding the other, because the two of them will always share the net punishment. And the mint/burn reduces the amount of trading that happens, since some buyers and sellers will choose not to trade.

This is why we saw very little trading at the PCV pool in the first days of launch. The nominal PCV price was around 0.95 (this price is meaningless, since no one trades at this price). The burn was around 25%, and mint was around 10%, depending on the time t. So if they traded with the PCV pool, the seller would would have received around 0.70, while the buyer would have paid 0.85. But clearly, these guys would prefer to get together on their own and trade at 0.80! And they did exactly this by trading at FEI-DAI pair at Uniswap or other centralized exchanges. As long as burn is greater than mint, it will always be true that outside exchanges offer a better price for both buyers and sellers. (Except after large price swings. Effectively it’s a swing trading pool with a high swap fee, like some Balancer pools).

I agree, simulations could also allow us to try out different parameters, or other functional forms for A(t).

I think the periodic reweight can work quite well too. It’s actually my second most preferred mechanism, after this one. Some of the pros and cons I can think of right now are:

  • A trader might sell and bring down the price in the instant before the periodic reweight, maybe because of a liquidity constraint (had to repay a loan) or just clicked the wrong button. Under the periodic reweight mechanism, this would lead to an expensive reweight, without allowing time for the market to arb.

  • Suppose ETH drops and we are undercollateralized, at a ratio of $0.90 per FEI. If FEI has not quite become a dominant currency that can sustain a fractional reserve, the market may value FEI at 0.90. If this is the case, a series of reweights will happen. Each sell-reweight cycle will decrease the collateralization ratio, barring other devices such as swap fees. So we may have a death spiral that completely drains PCV. With the A(t) mechanism, the death spiral will happen almost instantly. With a periodic reweight mechanism, the the protocol may have some time to respond, depending on the period length.
    I think this could be one of the cases when a high swap fee (i.e. high burn) may play a role by delaying the selling. Perhaps we can set some safeguards that kick in at under collateralization, such as higher swap fees, longer reweight periods (if we use the periodic reweight mechanism), or switch to a reweight period mechanism (if we use a different mechanism in normal times). These could delay the sell-reweight cycle from happening too quickly, and allow the protocol time to do things like TRIBE dilution to bring up the collateralization rate.


Elegant, efficient, I love it :clap:

The further we are from the peg, the faster a reweight triggers. Reweights are predictable, and not pushed back when arbitraged, so they occur closer to the peg and cost less to the PCV. What else could we hope for ?

Seems doable : add a peg deviation oracle and change the criteria in EthUniswapPCVController::reweightEligible() ?

I think there a 3 main (psychological) differences :

  • This mechanism places a floor price to FEI (C). If we take a low value of C (e.g. 0.01), we know FEI will never drop below 0.99$.
    • Removes essentially all risk as long as the protocol is overcollateralized.
    • The quadratic burn & mint behave much better under 1% off peg than outside.
    • I believe low-slippage secondary markets like Curve can take care of the remaining 1% volatility.
  • Predictability of reweights
  • Easy to understand formula

Apparently there’s a plugin :smiley:


Hmm. I like this argument. But I’m not convinced by it. I’ll try to push back.

First, I entirely agree that a sales tax on cars increases the price of the car for the buyer even while reducing the profit for the dealer. In the case of a tax system, that’s by design. The tax increases the cost of transaction in order to funnel money towards the government. Whether that’s good or bad depends on how benign the government is.

This leads me to my most immediate point against your argument: it’s by design that the FEI protocol benefits by increasing the cost of transactions through the action of direct incentives when the FEI is below the peg. In a sense, the deal is everyone is technically free to transact when FEI is below the peg, but transactions will be more expensive! And the further below the peg the FEI is, the more expensive the transactions. Eventually the cost of transactions will be prohibitive for sellers.

Well, the cost of transactions will be prohibitive at least for sellers. But your point, if I understood correctly, is that eventually the cost of transactions is prohibitive for both buyers and sellers. About this I have two thoughts.

The first is that, even if you’re right, that might be good. It would be a design that sacrifices liquidity in order to protect PCV. That’s desirable in many circumstances. It’s exactly what we want FEI to do in the case of a bank run when the protocol is severely undercollateralized. However, it’s not desirable in many circumstances. An ideal design wouldn’t paralyze a bank run when the protocol is significantly overcollateralized. What we saw last week was an edge case. The protocol was collateralized at a 1:1 ratio and it froze almost all buyers and sellers! At this point, I’m not sure that this behavior on this edge case is good or bad.

The second is that you’re borrowing results and intuitions from markets that are tremendously different from an AMM whose liquidity is guaranteed by the protocol. There are several key differences: one is that FEI is not a rational, profit seeking actor; the second is that AMM buys and sells are two different transactions on AMM. As a consequence of these two differences, direct incentives guarantee that the increase in the cost of transactions under the peg is incurred entirely by sellers. There’s no doubt that the effect of minting is to reduce the cost of buying under the peg. The limitation is that it only increases the cost of selling and reduces the cost of buying under the peg when we denominate costs in FEI.

So what happened last week? Why did minting not work? I think before we make any elaborate conclusions we need to rule out the simplest explanation. So far, reducing the cost of a transaction in FEI does not incentivize anyone to buy because the value of FEI is rather uncertain. Virtually no one has been able to sell FEI at a dollar. And there’s nothing like a guarantee that they will in the future. Moreover, FEI has no unique use cases that make it more desirable than other ERC-20 tokens. The net effect is that even after reducing the cost of a transaction in FEI, the cost of that transaction in dollars appears too large to be worth it. The only way to remediate this limitation is to instill confidence that FEI can be sold at a dollar.

Unfortunately, the problem is we’re trying to pull ourselves by the bootstraps: we want to ensure the value of FEI is a dollar by a mechanism that only works if people think the value of FEI is a dollar! This seems like a catastrophic blow for direct incentives. But I’d argue that it’s not. In fact, I’d argue that the most successful decentralized stable coin to date depends on such a mechanism. I can try to explain this point further if you’re skeptical. But I do remember that when I first learned about DAI my reaction was precisely: “the design is circular! There’s no way this works.” And the only thing that satisfied my skepticism was to see that nonetheless DAI had done a great job at keeping around $1.


Oh boy I was so excited when you said there was a plugin! But it looks like it’ll have to be installed by the team for us to be able to use it. :frowning: We should file a motion. There’s a lot of math going on that would look so much nicer all texed up!

1 Like

Indeed, the plugin would be wonderful. I think this could be complementary with yours, which if I understand correctly is about how the ETH should be sold when a reweight happens, whereas this is about the reweight condition.

I very much agree with your first point that we are restricting liquidity when price is low, and this can help prevent bank runs. Indeed, I think the proposal as it is may lead to an immediate death spiral, and if we are to implement this, we would need some safeguards like reweight delays or higher swap fees (i.e. burns) when PCV is undercollateralized.
That said, I don’t think guaranteeing stability during undercollateralization can ever be costless, unless FEI becomes as successful in the crypto world as US is in the world. Even the USD was backed by gold for a while until it became the dominant economy. It’s like an undercollateralized loan - we would need a lot of trust to achieve fractional reserve.

Regarding your second point, I admit that the AMM is not quite the same as a simple supply-demand model. But it’s similar in the sense that there is always a single market price (or two market prices, given the spread), and each buyer and seller is a price taker. Any (net) burn will increase this market price, making buys more expensive. Last week, there were two liquid markets on Uniswap, ETH/FEI and DAI/FEI (though DAI/FEI may not have been enough for some whales). ETH and DAI were pretty stable, so we can just translate all prices into the dollar price of FEI. In dollar terms, DAI/FEI always offered a higher price for the seller and a lower price for the buyer, except in occasional instants right after a big price movement occurred. Think about it this way: what happens if the buyer is actually incentivized by the mint of 10% or so and gets a strictly lower price at ETH/FEI? If we assume that the DAI/FEI pool is liquid enough, and ignore the 0.3% swap fees, this must mean that the buy price at ETH/FEI is also lower than the sell price at DAI/FEI. So the buyer would arbitrage by buying at ETH/FEI and selling at DAI/FEI, until the DAI/FEI price is at least as good as ETH/FEI price.


I love the elegance of this proposal. Would trying out a fixed cadence on reweights combined with some minimum peg distance allow us to gather more data on how actors behave when the next reweight time is deterministic? We could use that to motivate a more sophisticated proposal like this one

Also I enabled the MathJax plugin if someone wants to try it


Thank \, \, you, Joey

I assume you mean that a reweight is triggered when both a fixed amount of time has passed and the peg distance is above the minimum. What do you think would be the benefit of adding the minimum distance condition, rather than just fixed cadence?

Some of the possible effects I can think of are:

  • Suppose cadence is once per hour. If it has been more than an hour since the last reweight but the peg distance is less than the minimum, there is uncertainty about the next reweight time. In this case, perhaps we want to have reweight occur with delay after the minimum distance is reached, e.g. 10 blocks after.

  • It is possible that the price stays just above the minimum price but below 1.

  • The flip slide of the above: unnecessary reweights cannot happen when price is very close to 1 for a long time. Even if price is very close to 1 and there is little gain to be made from arbitrage, without the minimum distance condition, people may rush to reweight to earn the 500 FEI (hat tip to @Choochoo).

1 Like

For a crude reweight mechanism, we can just have these two conditions, and both need to be met.

  1. Peg distance is bellow C (1%).
  2. 1 hour has passed since last time price is above peg distance C.

So every time the price is above 0.99. the reweight timer is reset.
This might end up having the price hovering right around 0.99. which means that C can be set to … 0.1%, then the price will hover right around 0.999.

It’s actually better that reweight function is never called and the price hovers around 1-C.


Woohoooooo! Thank you! That \mathbb{R} helpful! (Except I evidently don’t know how to use it! :sweat_smile:)

1 Like

but this crude mechanism would still wait for an hour when price is wayyy bellow peg. THe A(t) mechanism you proposed @fei.saver will make sure to shorten to the wait when peg distance is large. That’s really nice.


That’s a good point. My current thinking is as follows.

For modest levels of sell pressure, even under a cadenced reweight, organic demand should still quickly correct price deviations below the peg (or the minimum distance) that occur some time before the next reweight. People should arbitrage now even if the reweight is expected an hour later. So if there are enough arbers willing to support $1 FEI, a slow paced reweight may be enough.

But there could be cases where there is an extreme sell pressure even while we are overcollateralized and periodic reweights are expected. For example, ETH volatility may spike up, and FEI holders may wish to exit even though we are currently overcollateralized. In this case, a reweight every hour may not be enough to relieve all sell pressure. Quicker reweights will allow a larger amount of users to exit quickly and with less slippage. This could be an appealing feature for users. I guess how quick we want the reweight to be is like how close we want FEI to be a reserve backed stablecoin. Reweights happening infinitely often would be identical to a stablecoin that allows 1:1 redemption.


Great point here, I think we could adjust the algorithm to have a shorter time to reweight when we are further from the peg instead of the current behavior where it takes longer


So I think there’s a typo in the last sentence. If I’m interpreting correctly you mean “the buyer would arbitrage by buying at ETH/FEI and selling at DAI/FEI until the DAI/FEI price is at least as good as the ETH/FEI price.” And the problem is then that when the DAI/FEI buy price is at least as good as the ETH/FEI buy price, the DAI/FEI sell price is much better than the ETH/FEI sell price. In turn, people can sell without getting burnt. Unfortunately, the asymmetry of the selling prices does not result in an arbitrage opportunity to balance this.

This is what you’re saying, right?

It’s an interesting interaction. It makes it seem like the protocol can’t successfully manipulate the selling price. But it might be even worse than that. Suppose that the buy price is the same at ETH/FEI and DAI/FEI. In this case, the sell price on DAI/FEI is likely better than the sell price on ETH/FEI. So if anyone’s desperate to sell FEI, they will sell on DAI/FEI. In turn, the price on DAI/FEI will fall. How significantly will depend on the degree of the sell pressure. What happens next is that there’s no arbitrage opportunity that encourages people to buy from DAI/FEI. Yes, the buyer can buy cheap FEI from DAI/FEI, but she can’t sell it for a better price on ETH/FEI. So minting/burning will have successfully depressed the effective selling price on the market. But at this point there will be no incentive to buy from ETH/FEI until the minting rewards increase so much that the buying price on ETH/FEI is as good as the buying price on DAI/FEI. So all of the buying and selling action will happen on the DAI/FEI market. Hmm.

That said, it’s very possible we’re thinking about this the wrong way. After all, we’re ignoring at least one extremely important constraint: liquidity. I imagine that the inherent limit to the liquidity in pools other than ETH/FEI likely changes these dynamics. After all, what’s really happening in pools like DAI/FEI is that small trades can occur at better prices than at ETH/FEI. But large trades are limited by the constraints of ETH/FEI.

Here’s what I mean. Suppose we begin at the end of the scenario you described. The buy price of ETH/FEI is the same as the buy price of DAI/FEI. And there’s a lot of sell pressure. People will sell on DAI/FEI until no one’s willing to sell anymore or the price of DAI/FEI reaches below the sell price of ETH/FEI. Then people will sell on both markets, but because of differences in liquidity, more sells will happen on ETH/FEI. So for a short run, people can sell at a price that’s better than the sell price at ETH/FEI, but eventually it reaches the sell price at ETH/FEI, and a significant portion of sales have to happen at that price. How significant that portion is will depend on how much liquidity can be accrued on the DAI/FEI pool.

Similarly, suppose we begin at the end of the scenario you described. The buy price of ETH/FEI is the same as the buy price of DAI/FEI. But now there’s a lot of buy pressure. People will buy on both markets. But a majority of the purchases will happen on ETH/FEI. Both because the slippage of DAI/FEI will be greater, and because minting will conspire to keep the price on the ETH/FEI pool lower than the price on the DAI/FEI pool, creating the short term dynamic that you described, where arbitrageurs are incentivized to buy on ETH/FEI and sell on DAI/FEI for short term profits. All of this will heavily favor purchases at the incentivized price on ETH/FEI.

I think the key to thinking about this the right way is to compare both scenarios to an unincentivized ETH/FEI market with the same liquidity. In the first scenario, people will be able to sell fei for longer at a better price and drain more PCV. In the second scenario, people will have to buy more fei at a higher price till they restore the peg. Both of these are undesirable relative to the incentivized case.

In any case, I’m rather tired and likely not thinking properly. I’m doing my best to not be dogmatic about the direct incentives but at the same time give some serious thought to why it would or would not work. It’d be interesting to know what Joey had in mind when he thought about interactions between uniswap markets. I’m sure he’s given this problem some thought. But I also bet he’s rather exhausted at the moment!