Oracle Migration to Uniswap v3 (incentive adjustments)

Oracle Migration to Uniswap v3 (incentive adjustments)


The list of oracles currently used can be found in this post.

We would like to migrate the Chainlink RAI / USD oracle to Uni V3 (3 day TWAP).

As a Uni V3 pool would be RAI / ETH we will need to multiply the value by an ETH / USD price to get RAI / USD. We will have a converter feed contract that sits in front of the RAI / ETH uni v3 oracle and the ETH / USD Chainlink TWAP to perform this conversion.

This post will outline why we are switching, the associated incentive adjustments, the steps we will take to enact that change, and the timeline for the change.

Reasons for switching

  1. Chainlink plans to deprecate both it’s RAI / ETH and RAI / USD feeds due to lack of liquidity.
  2. We have decreasing confidence in the data sources behind the RAI / USD chainlink feed as we have been seeing odd pricing deviations from time to time.

Incentive Adjustments

We currently incentize liquidity in the RAI / ETH Uni V2 pool with 30 FLX / day. To ensure adequate liquidity for the Uni V3 oracle we will shift incentives from the V2 pool to the V3 pool so the LPs will migrate. As we know it’s an inconvenience to move LP positions over we will increase rewards the first month to 40 FLX / day (split between both pools) followed by a constant 30 FLX / day rate on the Uni v3 pool going forward. The incentive adjustment schedule will be as follows:

FLX Distribution #31

Distribution date: October 2023
Start: September-15-2023 12:50pm UTC
Cutoff-date: October-15-2023 12:50pm UTC
RAI/ETH UNI-V2 LP: 30 FLX / day
RAI/ETH UNI-V3 LP: 0 FLX / day

FLX Distribution #32

Distribution date: November 2023
Start: October-15-2023 12:50pm UTC
Cutoff-date: November-15-2023 12:50pm UTC
RAI/ETH UNI-V2 LP: 20 FLX / day
RAI/ETH UNI-V3 LP: 20 FLX / day

FLX Distribution #33 and onward

Distribution date: December 2023
Start: November-15-2023 12:50pm UTC
Cutoff-date: December-15-2023 12:50pm UTC
RAI/ETH UNI-V2 LP: 0 FLX / day
RAI/ETH UNI-V3 LP: 30 FLX / day

Steps to implement oracle migration

  1. Write forum post to share with community and get feedback (that is this post :face_holding_back_tears:)

  2. Write Uni V3 oracle and ConverterFeed contract.

    • TAI is currently using this setup for their TAI / USD oracle.
    • We also have written a contract for HAI that combines 2 price feeds with a shared unit (token) that we could use as well.
  3. Deploy contracts and monitor for period of time

    • This monitoring period is to ensure the oracle is running as expected.
  4. Governance Proposal


  • The contracts can be written, deployed, and monitored immediately.
  • We will need to wait until the LPs have migrated by the end of November to enact the change.
  • The governance process will take ~ 8 days
    • 1 day vote delay
    • 6 day vote period
    • 1 day execution delay

Next Steps / Going Forward

Some things we are thinking about include

  1. Having multiple duration TWAPs we can switch between for the RAI / USD feed. (1, 3, and 7)
  2. Explore alternate ETH / USD oracles besides chainlink.
  3. Add an additional backup (3rd) ETH / USD oracle and put all 3 behind a medianizer.

In regards to getting community feedback, here’s mine: :handshake::heart:
The migration to UniV3 from Chainlink would have been expected anyways, I believe it’s time to let Chainlink handle RWAs and use the enhanced Univ3 capabilities.
So the proposed setup is that oracle contract reads RAI/ETH pool parity and overlays ETH/USD price(fed by Chainlink still untill better options), to get RAI/USD?. Then feeds the GEB system with that data.?
I learned recently that HAI codebase is modern and clean, so I informally vote for trying this…
Multiple duration TWAPs are also a pleasant surprise…
3.What viable options do we have for alternative ETH/USD price action?

Will the Uni v3 LP range be full-range?
What will be the Uni v3 pool fee tier?

1 Like

Good change and good comms.

I’m curious to see what alternatives to the Chainlink ETH/USD oracle people propose.

1 Like

We’ve improved the RAI ConverterFeed to create a better combined TWAP when using the ChainlinkTWAP contract and UniV3 TWAP. With these changes, the UniV3 TWAP now exactly matches the timeframe of the Chainlink TWAP.

This is what TAI is using in prod for TAI/USD.

1 Like

Yes your understanding of the proposed setup is correct.

In terms of viable alternatives to ETH / USD, we are currently using Tellor Data Feed | Decentralized Oracle Protocol s a backup so that is a possibility.

Chronicle that powers MKR is launching a new protocol that might be interesting. (See:

We could also use an ETH / DAI or ETH / USDC uni v3 oracle in place of ETH / USD.

Have not extensively explored this yet though. Do you have any suggestions?

This is awesome! We plan on using this for the oracle migration.

1 Like

This has not been finalized yet. Full range would be most resilient to manipulation. Re: fee tier, maybe 0.3% as it’s not a stable since it’s being paired with ETH.

What are you thinking?

I second full-range. Regarding the fee tier, I think 0.05% is better. It defines daily minimum activities and the oracle precision. With the current pool size (~$1.2m) and the swap gas cost (~$2.5), an arbitrage trade occurs with a 0.14% (= sqrt{2.5/1.2e6}, see also ) price change, which is smaller than 0.3%. When the pool grows to $10m, it occurs with a 0.05% price change.

Very good point, 0.05% makes sense to me.

Just comment. Bribing through Bunni+HiddenHand looks >2x efficient now. However current DAO’s distro. style (1 month retroactive) doesn’t suit it.

Besides that, just specifying Bunni LP token (ERC20) may make tracking easier for rewarding than UniV3Pos-NFT. It also brings some options like collateral usage, Saviour integration, etc.

Has this been finalized? Full-range seems like a bit of a waste. Why not something like +/- 3% of redemption price?

No, this has not been finalized. Definitely open to discussion.

I would think a narrow range around the redemption price would be best for countering manipulation and also provide more useful liquidity (plus LP will get much more fees so will encourage more LP’s to join hopefully)

I’m not sure what the best way to determine that narrow range is. Also whether it should be set as a fixed range at the beginning of the month or updated constantly as redemption price changes (more work/gas for LPs and harder to figure out rewards, but could be necessary if redemption price moves too much in a month)

Update on incentive changes from uni v2 → uni v3 and oracle migration

I messed up in the incentives communication and didn’t update the proper label on GitHub incentives info for this period Oct 15 - Nov. 15th. It said RAI / DAI uni v3 was incentivized when it should have said RAI / ETH univ3). Additionally I did not update the RAI incentives table and the actual website.

That being the case I think it’s fair to use the distribution info that was incorrect on GitHub because that was what everyone saw publicly. Doing that would mean the following

Thus to honor what was on Github I propose we use the following incentives structure:

FLX Distribution #32

This was intended to be 20 FLX / UNI-V2 RAI / ETH and 20 FLX / UNI-V3 RAI / ETH but said UNI-V3 DAI / ETH on GitHub.

Distribution date: November 2023
Start: October-15-2023 12:50pm UTC
Cutoff-date: November-15-2023 12:50pm UTC
RAI/ETH UNI-V2 LP: 20 FLX / day
RAI/DAI UNI-V3 LP: 20 FLX / day (This is the one I messed up)

FLX Distribution #33

Distribution date: December 2023
Start: November-15-2023 12:50pm UTC
Cutoff-date: December-15-2023 12:50pm UTC
RAI/ETH UNI-V2 LP: 20 FLX / day
RAI/ETH UNI-V3 LP: 20 FLX / day

FLX Distribution #34

Distribution date: January 2024
Start: December-15-2023 12:50pm UTC
Cutoff-date: January-15-2023 12:50pm UTC
RAI/ETH UNI-V2 LP: 0 FLX / day
RAI/ETH UNI-V3 LP: 30 FLX / day

For the RAI/ETH UNI-V3 LP I propose we use the 0.05% fee tier for the reasons kyoronut suggested above.

For the range I suggest we do + / - N% around the price of RAI on the start of the distribution period.

So for example if the price of RAI is $2.73 on Nov. 15th then we use the following range.

N = 3%

Lower: 2.6481
Upper: 2.8119

Please let me know what you all think, especially regarding the fee tier and the LP range.

As long as the purpose of the pool is the oracle usage, I think full-range is the only choice.

1 Like

The primary purpose is indeed oracle usage.

yeah lets go w full-range liquidity. everything else is too complicated and will likely create problems.

seems legit, oracle usage priority for common interest and stability of protocol
Regarding a more private interest of LPers, is it worth to start a new thread and get RAI big brains to propose/explore some outside the box ideas?

If you want not full range liquidity, a contract like this one would have advantages over the original proposal. It’s less “price fixing” and more “avoid incentivizing JIT liquidity providers that don’t help the oracle”.

But as others have pointed out, probably makes more sense to go full range.