MIP40c3-SP45: Modify Core Unit Budget, ORA-001 (Oracle Gas Costs)

MIP40c3-SP45: Modify Core Unit Budget, ORA-001 (Oracle Gas Costs)


MIP40c3-SP#: 45
Author(s): Niklas Kunkel (@NiklasKunkel)
Tags: core-unit, cu-ora-001, budget
Status: RFC
Date Applied: 2021-11-12
Date Ratified: n/a

Sentence Summary

MIP40c3-SP45 appends Maker Oracle gas costs to the Oracle Core Unit ORA-001 budget for August 1 2021 through end of March 2022.

Paragraph Summary

MIP40c3-SP45 appends Maker Oracle gas costs to the Oracle Core Unit ORA-001 budget for August 1 2021 through end of March 2022. The Maker Oracle gas cost budget is separate from the general operations budget of the Oracle Core Unit. Unlike the Operations budget, which is renewed annually, the Oracle gas costs budget will be renewed every three months. This first subproposal instance of the Oracle gas cost funding requests also includes one-time payments to fund an emergency multi-sig as well as a repayment to the Maker Foundation for fronting Oracle gas costs since August 1st, 2021.



To finalize the transition of the Oracle Core Unit from the Maker Foundation, the DAO must shoulder the Ethereum network transaction costs consumed by the Maker Oracles.

Constructing a fixed budget for Oracle gas costs is difficult due to the multivariable nature of the problem, and the consequences should the budget be insufficient.

This MIP details quantitive observations with respect to historic costs. It introduces a multitude of factors that determine realized costs. Finally, it presents an implementation of a comprehensive framework to deduce a budget proposal for the Maker Governance community to consider.

Core Unit ID



The original Oracle Core Unit budget filed in May 2021 explicitly stated:

It should be noted that the gas costs for operating Oracles are not included in this budget and will be requested in a later subproposal. These costs scale linearly with the gas-price of the Ethereum Network and are significant, variable, and difficult to model.

At the time, the Oracle Core Unit lacked sophisticated tooling to achieve effective granularity for tracking Oracle costs. This made it difficult to estimate a sufficient gas cost budget which wouldn’t put the Oracles, and in turn the Maker Protocol, at risk of freezing up.

The Maker Foundation, despite its wind-down activities, very generously offered to front the Oracle gas costs to give the Oracle Core Unit sufficient time to compose a more sophisticated funding proposal to the Maker Governance community.

This agreement between the Maker Foundation and the Oracle Core Unit became effective in August 2021 and continues to this day.

Factors which Affect Oracle Costs

Ethereum Gas Costs

The gas cost of the Ethereum network corresponds directly with the demand to transact on the Ethereum network. More transactions lead to more competition to get into a block.

This is expressed in a combination of a maximum base fee and a priority fee. The base fee is modulated by the Ethereum protocol to calibrate the amount of transactions in a block. If blocks are full, the base fee increases. If blocks are empty the base fee decreases. All transactions mined in a block regardless of their selected maximum base fee pay the base fee determined by the protocol. Unlike base fees which are burned, priority fees go to miners to serve as a bribe for inclusion in the block at the expense of other transactions that have a sufficient base fee but a lesser priority fee.


New users tend to become attracted to crypto when prices are rising as they have been the past year. This has led to an enormous increase in transaction demand on Ethereum (as well as other blockchains). Decentralized exchange activity has seen enormous growth and accounts for ~25% of daily gas on Ethereum at time of publishing.


In particular the boom and mainstream adoption of NFTs has led to significant gas price spikes. When new NFTs are released, users who ‘mint’ can earn many multiples in profit. This leads to a race condition where every user is competing to get as many NFTs minted before they run out. Due to the high profit potential, users are willing to pay thousands of dollars in transaction costs. Operating Oracles during these intervals of time can quickly cost in an hour what is typically spent on Oracles in a day. Even outside of the gas spikes created by NFT minting events, NFTs as a baseline represent ~5% of daily gas at time of publishing.


While rollup activity has been fairly muted thus far, rapid adoption of rollup chains such as Optimism and Arbitrum could lead to upward pressure on Ethereum L1 gas costs as calldata for every L2 transaction must be recorded on L1.

Number of Oracles

The number of Oracles that need to be in operation scales linearly with the cumulative gas consumed. Key to creating a budget for Oracle gas costs will require forecasting what number of Oracles will be created in the future. This could come in the form of collateral onboarding or creating Oracles for customers and partners. Underestimating the amount of new collateral types that will be onboarded would lead to the Oracle Core Unit having to throttle collateral onboarding until additional budget could be ratified by Maker Governance.

The Number of Feeds for Quorum

Oracle Medianizers are configured with a parameter bar which is the number of Feeds necessary to reach consensus on a new canonical price. Increasing this threshold would increase the security of the Oracles by raising the bar for the number of Feeds that would need to be malicious. However, increasing the threshold for quorum also increases the amount of gas consumed as more calldata needs to be sent to and processed by the Medianizer smart contract.

This is different from the total number of Feeds, which has no effect by itself on the gas consumed by an Oracle.

Oracle Type

Collateral assets fall into different categories depending on their design. There is no one-size fits all Oracle solution for every asset. The Oracle Core Unit has designed different Oracle solutions to fill the DAOs demand to on-board different kinds of assets.

These different Oracle solutions all have different costs, and even instances of a solution may have varying costs depending on the configuration and the asset in question.

In the majority of cases, a Feed-based Oracle consisting of a Medianizer smart contract, Oracle Security Module smart contract, and Spotter smart contract is applied. See the Oracle Parameters section below for a description of how different instances of this Oracle type may have different costs.

In the case of Uniswap V2 LP tokens, a bespoke Oracle was created which exclusively uses on-chain reserve data from the pools rather than sourcing it from the Feeds. This is more decentralized and slightly cheaper than a Feed-based Oracle.

A forthcoming Curve V2 LP Oracle currently being designed by Protocol Engineering Core Unit will add an additional Oracle solution to the mix with its own unique gas cost profile.

Oracle Parameters

Relayers can configured to update Medianizers under specific conditions. One of these conditions is a spread parameter. The spread is the percentage difference between the current value in the Oracle Medianizer smart contract and the fair market value of the asset the Oracle represents.

Assets that the Maker Protocol has high risk-exposure to, such as ETH and BTC, tend to have lower spread parameters, while assets with lower risk-exposure tend to have higher spread parameters. Risk in this instance is typically viewed as a combination of debt ceiling and collateralization ratio, but may include other factors depending on the particular collateral asset in question.

An Oracle with a lower spread tends to update more frequently than one with a higher spread. This is not absolute due to different volatility profiles of assets, but is generally true. More frequent updates leads to a more expensive Oracles.

Another parameter is the expiration. This is how long an Oracle Medianizer isn’t updated due to the spread condition not triggering. The expiration parameter exists to serve as a heartbeat for an Oracle. It is the way a smart contract on-chain can deduce whether an Oracle is online or offline. Lower expiration times may lead to more frequent Oracle updates, which increases Oracle costs.

Quantitative Observations

The gas costs for Oracles can be deconstructed into four separate components:

  1. Medianizer
  2. Oracle Security Module
  3. Uniswap V2 LP Oracle
  4. Spotter

The Medianizer is the real-time price Oracle. It updates continuously and is triggered by a spread (price deviation between Medianizer and market price).

The Oracle Security Module consumes the Medianizer price and enacts a one-hour delay. It is updated at the top of every hour.

The Uniswap V2 LP Oracle is a bespoke Oracle which utilizes Uniswap pool reserves as well as Medianizers to price those reserves in order to compute the price of an LP token. Similar to the Oracle Security Module, it has a built-in hour-long delay function and is updated at the top of every hour.

The Spotter is part of the core Maker Protocol and reads prices from the Oracle Security Module and Uniswap LP Oracle so that they can be utilized by the Maker Protocol. They are typically poked in unison with the Oracle Security Module, but do not have to be.

Medianizer Gas Costs

Medianizer Cumulative Gas Costs

Range: August 1, 2021 - November 8, 2021
Source: Dune Analytics

Medianizer Distribution by Asset Pair

Range: August 1, 2021 - November 8, 2021
Source: Dune Analytics

Medianizer Cost by Asset Pair

Range: August 1, 2021 - November 8, 2021
Source: Dune Analytics

Daily Gas Consumptions

Range: August 1, 2021 - November 8, 2021
Source: Dune Analytics

Oracle Security Module Uniswap LP Oracle + Spotter Gas Costs

This includes cost of the Oracle Security Module, Uniswap V2 LP Oracle, and Spotter.

Range: August 1, 2021 - November 8, 2021
Source: Dune Analytics

Daily Gas Consumption

Range: August 1, 2021 - November 8, 2021
Source: Dune Analytics

Gas Distribution of OmegaPoker

Quantitative Analysis

This analysis uses the observed data and breaks it down into its components. It then reconstitutes the components into meaningful insights to gauge the annual cost per Oracle over a year. This should aid not only in planning how much to budget to maintain operation of the currently active Oracles but also allowing cost forecasting to support collateral onboarding activities.

The gas profile distribution for the OmegaPoker mapped to the observed gas consumed gives us the following information:

Oracle Security Modules - $331,019.22
Uniswap LP Oracles - $455,493.38
Spotter - $411,722.248
GUNI - $98,485.056

These are likely off by some degree due to the introduction of the MATIC and GUNI tokens during the sampling period. That is to say, the proportions are indicative of what we can expect going forward but may not be entirely accurate with respect to what has occurred since August 1st.

Spread out over 16 Oracle Security Modules, the individual cost of each OSM for time period T [08/01/21 to 11/08/21] is:

OSM Cost(T) = $331,019.22 / 16 =  $20,688.70

Extrapolating this over a year:
$20,688.70 * 365/100 
= $75,513.755

Uniswap V2 LP Oracle costs can be calculated by utilizing the proportion of the observed OmegaPoker costs that correspond to Uniswap V2 LP Oracles. Although there are currently 8 active LP Pairs, DAI-USDT and ETH-USDT were offboarded but still do factor into the observed costs. We’ll use 9 as an approximation for our cost calculation. The cost to operate each Uniswap LP Oracle during the time Period T [08/01/21 to 11/08/21] is:

Uniswap V2 LP Oracle (T) = $455,493.38 / 9 = $50,610.3756

Extrapolating this over a year:
$50,610.37 * 365/100 
= $184,727.87

The cost per Spotter can be derived in a similar manner. However, in this case every ilk has its own Spotter, so even collateral types which share the same underlying Oracle (WBTC & renBTC) still have the Spotter cost component. Currently there are 26 different ilks. However, MATIC and GUNI were added relatively recently, so we’ll use 25 as an approximation. Hence, the Spotter cost for time period T [08/01/21 to 11/08/21] is:

Spotter Cost(T) = $411,722.248 / 25 = $16,468.89

Extrapolating this over a year:
$16,468.89 * 365/100
= $60,111.45

So now we have all of the individual pieces of data we need to deduce the total Oracle cost of a particular collateral type.

A standard collateral type uses a Medianizer, Oracle Security Module, and Spotter.

Therefore, the standard Oracle cost is:

C = C_Medianizer + C_OSM + C_Spotter

Medianizer costs vary depending on how volatile an asset is in combination with what the spread sensitivity parameter on the Oracle is set to.

The estimated total annual cost of the ETH Oracle is:

C_Medianizer_ETH(T) = $53.529.23
C_Medianizer_ETH(1 year) = $53.529.23 * 365/100
                         = $195,381.69

C_ETH = $195,381.69 + $75,513.75 + $60,111.45
C_ETH = $331,006.89

The estimated total annual cost of the YFI Oracle is:

C_Medianizer_YFI(T) = $33,756.32
C_Medianizer_YFI(1 year) = $33,756.32 * 365/100
                         = $123,210.57

C_YFI = $123,210.57 + $75,513.75 + $60,111.45
C_YFI = $258,835.77

A Uniswap V2 LP collateral type uses a Uniswap V2 LP Oracle and a Spotter.

Therefore the annual Uniswap V2 LP Oracle cost is:

C = C_UNIV2LP + C_Spotter

  = $184,727.87 + $60,111.45
  = $244,839.32

So far only a single GUNI (Gelato Uniswap V3) vault has been added only very recently, so data is sparse. Preliminary gas profiling of the OmegaPoker shows that GUNI uses 7.2% of the gas per call. This is relative to the 8 Uniswap V2 vaults which collectively use 33.3% of the gas. This means a single Uniswap V2 vault uses 4.16% of the OmegaPoker gas consumption. Comparing those two figures, it becomes clear the GUNI Oracle is significantly more expensive than the Uniswap V2 Oracle. While imprecise, the following should serve as a decent approximation of the annual cost of a GUNI Oracle:

$184,727.87 / 4.16 = C_GUNI / 7.2
C_GUNI = $319.721.31 

C = C_GUNI + C_Spotter
  = $319,721.31 + $57,799.46
  = $377,520.77

Now that we have an annual breakdown of each Oracle types we can surmise that the following collateral types are currently unprofitable:


(though the last one is purely due to DC limitations).

Estimated total annual Oracle cost:

($614,846 + $1,367,848) * 365/100 
= $7,236,833.10

However, these estimates are not accounting for gas costs that may rise. In fact, gas costs have risen dramatically over the course of the sampling period.

Range: August 10, 2021 - November 10, 2021
source YCharts

The average gas price on 8/10/21 was 65.22.
The average gas price on 11/10/21 was 173.90.

This makes it extremely difficult to predict what Oracle costs may be in the future, as gas prices could rise rapidly.

Budget Breakdown

It must be internalized that the consequences of running out of funding for Oracle gas costs are the immediate halting of the Maker Oracles, and subsequently the disabling of liquidations and borrowing in the Maker Protocol. This leaves the Maker Protocol vulnerable to price risk of the underlying collateral and in extreme circumstances could threaten the Dai peg.

Therefore, it is vital that a defense-by-layers approach is taken with regards to Oracle funding. Factors that can drive up costs must be assumed with a pessimistic mindset. The penalty for overshooting is merely capital inefficiency while undershooting can have dire consequences.

The Oracle Core Unit is recommending that MakerDAO budgets Oracles gas costs on a three-month rolling basis. Costs exhibit more determinism over shorter periods of time.

Based on the observed data, the cost to operate the currently active Oracles for three months is:

3-month Oracles Gas Cost = Annual Oracles Gas Cost * 90 days / 365 days
3-month Oracle Gas Cost = $7,236,833.10 * 90/365
3-month Oracle Gas Cost = = $1,784,424.6

New Oracles that the Maker Protocol plans to create during that time period as a part of collateral onboarding need to be factored in. Using the previously established values as a guide we will estimate that each Oracle costs $295,000 annually (average of ETH and YFI Oracle cost). Since all new Oracles won’t be onboarded all at once but instead continuously through the 3-month period, the costs are halved. Five new Oracles over a 3-month period then cost:

Additional 3-month Gas Cost = Annual Gas Cost per Oracle * Estimated Number of New Oracles * 90/365 / 2
Additional 3-month Gas Cost = $295,000 * 5 * 90/365 / 2
Additional 3-month Gas Cost = $181,849.32

Making a pessimistic assumption that the Ethereum average gas costs are doubled during that time period leads us to a figure of:

Risk-Adjusted 3-month Oracles Gas Cost = (3-month Oracles Gas Cost + Additional 3-month Gas Cost) * 2
Risk-Adjusted 3-month Oracles Gas Cost = ($1,784,424.60 + $181,849.32) * 2
Risk-Adjusted 3-month Oracles Gas Cost = $3,932,547.84
Oracle Emergency Funds = 3-month Oracles Gas Cost + Additional 3-month Gas Cost * 6 weeks / 52 weeks pear year
Oracle Emergency Funds = $1,784,424.60 + $181,849.32 * 6/52
Oracle Emergency Funds = $1,805,407.21

This budget is expected to be voted on in December 2021. The Maker Foundation would front Oracle gas costs until the OCU has access to the requested funds. This means the refund would approximately cover the range 08/01/21 to 12/31/22. If the current rate of spending holds, this would be approximately:

Maker Foundation Refund = Annual Oracles Gas Cost * Days Since August 1st, 2021 / 365 Days per Year
Maker Foundation Refund = $7,236,833.10 * 153/365
Maker Foundation Refund = ~$3,033,522

Budget Contents:

  • Oracle gas cost funding through end of March 2022
  • Funding for 5 additional Oracles to support collateral onboarding activities through end of March 2022.
  • Safeguard adjusted for average gas price doubling during that period
  • Refund the Maker Foundation for gas costs incurred since August 1, 2021.
  • An emergency fund which contains a further 6 weeks worth of Oracle gas costs.
Item Cost
Oracle Gas Cost (01/01/22 - 03/31/22) $3,932,547.84
Oracle Emergency Fund $1,805,407.21
Maker Foundation Refund ~(8/1/21 - 12/31/21) $3,033,522
Total $8,771,477.05

The only recurring item of this budget will be the 3-month Oracle Gas Cost. The Foundation refund is a one-time expense, and the Emergency Fund only need to be funded once and topped up if ever utilized. Realized gas costs are likely to be lower than what is budgeted. This is by design.

Budget Implementation

Multi-Sig Management

Funds will be split up into two multi-sig wallets that are separate from the Oracle Core Unit Operations Multi-sigs and Oracle Core Unit Emergency Multi-sig.

Multisig #1 = Oracle Gas Costs

Signers = 5
Quorum = 3

Nik - Oracle Core Unit Faciliator - @NikKunkel

Marc-Andre - OCU Engineering Team Lead - @marcandu

George - Tech-Ops Core Unit -

Primoz - Risk Core Unit Facilitator - @doopson

PunchIt Inc. - Protocol Engineering Core Contributor - @cmooney

Multisig #2 = Oracle Emergency Fund

Signers = 3
Quorum = 2

Nik - Oracle Core Unit Faciliator - @NikKunkel

Marc-Andre - OCU Engineering Team Lead - @marcandu

George - Tech-Ops Core Unit -

The emergency multi-sig has a lower signing threshold than the general multi-sig because of the need to ensure that in an emergency funds are available to fuel the Oracles. Unlike people which can convinced with rhetoric that their paychecks will be late, Oracles are smart-contract which are much more resolute. You either pay them, and they do what you want, or you don’t pay them and they will do nothing. Therefore, it’s imperative that the emergency fund is easy to access and not susceptible to uncommon but high impact scenarios such as “multiple signers: on a plane, asleep, off-the-grid, generally unreachable, bus-factor, etc.”

The multi-sigs will be deployed and the smart contract addresses inserted into this MIP after the Maker Governance community has had the chance to give feedback and ratify the proposed configuration in a Polling Vote.

The one-time Maker Foundation refund should be sent to the Oracle Gas Costs multi-sig so an exact amount can be forwarded to the Maker Foundation.

Fund Distribution

Unlike core unit operational funds, which are streamed continuously, Oracle gas cost funding should be distributed as a lump-sum payment. This is for several reasons:

  1. The Maker Foundation refund needs to be paid in full so the Foundation can close its books as part of its winddown.

  2. Gas costs are hyper volatitle, meaning Oracles expense outflows can happen in bursts many times the size of a typical day. Gas costs on short-time intervals are therefore not predictable and only average over long time intervals.

Fund Management

In order to bound Oracle gas costs and in an effort to make them more deterministic, the Oracle Core Unit will engage in inventory management strategies with its funding. Initially these management strategies will bias towards extreme conservatism until the Oracle Core Unit builds up the necessary expertise to execute on more advanced strategies.

These may include but are not limited to:

  • Diversify some or all of the funds into ETH in order to hedge against increases in the price of ETH
  • Purchase gas calls/futures when secure liquid markets become available in order to hedge increases in gas
  • Purchase ETH calls/futures to hedge against increases in the price of ETH

Fund Rollover

Towards the end of the 3-month cycle, the Oracle Core Unit will submit a new budget proposal for the next 3-month cycle. Any leftover funds from the previous cycle will be rolled over and deducted from the budget distribution for the next cycle.

To illustrate the above, if there are $1M worth of assets (combination of DAI and ETH) leftover and the budget for the new 3-month cycle requests $2M, then the Maker Protocol would only distribute $1M Dai. Prices used to value assets should be the Oracle price on the day the Executive Vote is created.

Related Material

Governance & Risk call walkthrough on 11/9/21 - (note figures were changed between this recording and what is contained in the MIP).


Considering this is the first time the community has been exposed to the full cost burden of the Oracle infrastructure, I can imagine there’s some sticker shock. I’m happy to discuss solutions the Oracle Core Unit is working towards to optimize gas costs as well as what Maker Governance can do to reduce the Oracle cost burden. I just didn’t think it was appropriate inside the MIP itself.


You must have done a good job easing the community into this post because I’m not feeling much of a sticker shock.

I think discussions on lowering costs can have their own thread and it would be very interesting to see what you have in mind.

Re: fund management for gas prices, do you know if (based on historical data) the default choice should be to keep the funds in ETH vs. DAI?


Thanks @NikKunkel for the very detailed MIP.

Same. Not shocked.

We are all kind of used to the fact, nowadays, that Ethereum fees are crazy high! It is what it is.

Let’s gooo! :slight_smile: :100: :call_me_hand: :clap:


@NikKunkel thanks for the detailed report and my apologies I missed the details during the last Governance call.

So the question I asked (what is the average cost per pair) - based on what I see above it looks to be about 10ETH/Q or at current ETH prices 50K/Q. This ends up being 200K/Yr and with a collateral type of 1% SB (most of our collateral SFs are above this) we need to have 20M/yr DC - AT CURRENT ETH price and whatever average gas cost was over the Q.

So you are projecting a gas cost.

What is this based on? ETH cost? + actual gas in gwei on average?
Exactly how much time given various ETH costs + a 2,5,10,20,50x in gas prices will an emergency fund last?

Lastly how does the Foundation Relief figure here? Do they spend DAI to buy ETH or does this fund already have ETH?

While I like to see variability in a chart I also like to see these with running averages to see trends more clearly.

One thing that is interesting on the charts that I don’t quite understand is how the USD price can track ETH price so well over the entire period. We doubled in ETH price, maybe average gas price in gwei decreased.

I really want to see included somewhere on these charts or with them is the ETH price and the actual bid cost in gwei to clear a transaction. I also would like to see something like a ‘time to clear’ as well. My expectation is that these tx’s are designed to clear rapidly so the gwei will be higher than a person might use, but also given the fluctuations in the network it would be interesting to see what gas gwei bids are getting us in terms of actual response of the blockchain to accept once a tx is posted.

I think there are some real insights into what kinds of fees relative to average fee at the time and time to be posted to blockchain from our own oracles missing in the above that will be particularly relevant to understanding how much an emergency buffer is going to cost us.

One last thing. Wished we had done this at 200US/ETH vs now almost 5000US/ETH but doesn’t it behoove us to hold our emergency oracle funds in ETH ?

BTW: This is to all CUs. When costs on anything substantial double - please make a forum post about this. Costs growing at > 100% yr/yr are a real concern and need to be monitored carefully.


I would like to raise a couple of concerns regarding this MIP.

While fundamentally agree on the proposal I think we ought to consider the ramifications of the proposed schedule of payout. This is proposed as a single payout of 8,7M DAI. As a comparison, currently the SB is standing at 59,4M DAI. Such a payout would reduce the current SB by more than 14%, and would most likely reduce the ratio of surplus to non-stablecoin DAI ratio bellow 1%. Risk recommends a level between 2-3%.

As this signal request shows: The SB is already hotly debated, with the community seeming to land on a consensus of a partial burn. If we reduce the SB by the proposed amount, it will take more than a month just to get back to the point we are now. Adding a needed increase in SB would further push back on burn, delaying it by more than two months at current profit levels. A further delay will cause further harm to Maker’s reputation as an investment case. Lacking a clear and defined policy on how to handle burning, there exists an expectation of some level of burn to take place and a failure to do so can be viewed as an unfulfilled obligation.

From a risk management perspective I think we ought to examine the need to establish the Oracle Emergency fund against the need to keep the SB at reasonable levels. I would love for Risk to give an assessment on this particular issue, and importantly how to balance these two needs against each other.

The need for this to be a lump-sum payment should be critically examined, because doing so would have direct consequences for other strategic objectives.

My personally proposed solutions would be to:

  1. Split the Oracle Gas Cost payment into 2 payments. 1 now, and 1 in mid February. Gas cost is volatile, but this is a running cost.
  2. Establish the Oracle Emergency fund, but view it in conjunction with the SB and find a balance between increasing the SB and filling the Emergency Fund.
  3. Use MKR in the treasury to pay the Maker Foundation Refund. The treasury is a direct result of the foundation dissolving and I think it would be natural to view this as reduction in the original payment into the treasury. Meeting obligations should be the highest priority as failing to do so will erode the trust on which this protocol ultimately depends.
1 Like

What about 4. Pay the Oracle CU in MKR from the treasury and they can convert it to whatever and transfer to the Foundation?


This seems like a no brainer.

How did the foundation cover these costs. Is there a record trail of the transactions? Was it funded in eth or Dai?

Re: fund management for gas prices, do you know if (based on historical data) the default choice should be to keep the funds in ETH vs. DAI?

This is difficult to answer. If ETH is in an up only climate it is almost certainly better to hold ETH. However, it would be foolish to bet on ETH always only going up (remember we’re talking about discrete 3 month time intervals). You can imagine a scenario like Black Thursday where gas prices were insanely high, and yet ETH price was very low. In that particular scenario an Oracle gas cost budget consisting of an ETH-only fund management strategy would have gotten rekt. So the answer here is you really should have both Dai and ETH, or Dai and some alternative exposure to ETH through some other financial instrument such as calls/futures.

I understand that the amount of Dai in the surplus buffer has effects outside the scope of Oracles.
The Risk Core Unit and Real World Finance Core Unit use it to deliberate on debt ceilings. Meanwhile the community uses it as a factor in deciding the frequency of burns. I’m sure there are others as well.

Why did I request the budget for 3-month segments. Why not 1 month, 6 months, or 1 year? I selected 3 months because I’d like to balance the following factors:

  1. a governance dispute leading to Oracles failure
  2. a change in the macro leading to Oracles failure
  3. time overhead spent by the Oracle Core Unit on preparing budget proposals for governance and ferrying them through the governance process.

Let me expand on (1). I view it is an ultimate failure of governance were an Executive Vote to replenish Oracle gas costs ever fail. However it’s a real possibility the Oracle Core Unit has to consider. It could happen for a number of reasons. Maybe that Executive Vote is bundled with other changes large stakeholders deem undesirable. You might even consider proposals with overall shallow support intentionally inserting themselves into an Executive Vote containing an Oracle gas cost funding payment because “of course MKR holders won’t do anything that would lead to the Oracles to shut down”. Maybe one day we devolve into US style politics where political parties intentionally play a game of chicken when the Federal government is about to run out of money in order to get the other party to concede on other issues. Yes I’m aggrandizing a little bit. The point is these touch points where funding has to be renewed are in my view potential failure events, the frequency of which we should want to minimize as much as possible.

(2) The budget is based on assumptions informed by historical data. The longer the time period we try to extrapolate based on these assumptions, the more likely we are to observe drift when the macro shifts considerably. Even with proper fund management, this is still a considerable risk. What if the ETH price stays the same but gas prices go up 4x? Have we seen this yet, no, not really. Could it happen? Absolutely yes.

3 months is this sweet spot, between (1) and (2).

So let’s discuss if there’s a compromise to be made here. Does the Oracle Core Unit need to pull the funding up-front? No, the budget is spent continuously. Does the Oracle Core Unit need to be able to pull funding without delay in case of outlier events? Yes.

So to your point of splitting the gas cost up into 2 payments, what if we did that but without increasing (1)? That is to say, let’s have the budget be vested 100% from day 1 but the Oracle Core Unit enters into a social contract with the DAO to pull funding in 2 discrete payments (or maybe more?) rather than as a lump-sum. This ensures the Oracle Core Unit can still pull all funding in case of an emergency.

While ultimately the surplus buffer after 3 months ends at the same amount (-ish, see below), it is overall higher at discrete points in-between. Now what are the drawbacks here. Well not having the funding all at once compromises the fund management strategies. For example, let’s say the optimal strategy is to have 70% ETH, and 30% Dai. You can’t get a 70% ETH allocation with only 50% of funding up-front. Are calls/futures here able to use leverage to get this kind of outsized ETH exposure? Maybe, but the Oracle Core Unit isn’t ready to deploy such an advanced strategy with confidence (yet).

Im interested to hear from the community what they think about the above compromise.


@NikKunkel , sorry this is a question only tangentially related to this MIP but, are you aware of any serious working in progress regarding gas futures?

It seems crazy to me that nobody has yet come up with something solid on this, since it would be tremendously useful to many project, MakerDao included.

First of all @NikKunkel I want to thank you for a very thorough and well reasoned response to my post. I share your sentiment that a failed Vote to replenish Oracle gas costs would represent a disastrous failure of governance. The idea of bundling Oracle gas costs with another controversial change in order to pass it is so alien and irresponsible to me that I hadn’t even considered it. Perhaps some issues related to critical running costs (like Oracles) should be their own Executive entirely.

As for your suggestion for a compromise I think it’s a good one. The needs for the funds are not in dispute merely the rate of withdrawal. Making the vesting immediately available while spacing out the actual draws would seem to me to help covering several competing objectives without causing disproportionate disruption to either. I would certainly support such a way forward.


Is there any chance we can break the oracle gas budget and Maker Foundation payment into separate proposals?

After more careful review of this budget.

I would like to second @PaperImperium request to break these into at least 2 different budget requests.

The following relates to what I am going to want to see in the future in terms of oracle budget accounting. If the budget is in DAI and ETH then we need to see either quarterly or given the volatility of costs that are pretty high monthly tracking report with the following:

Beginning of the month
DAI/ETH on hand.
costs in DAI (what this was spent on)
costs in ETH (what this was spent on).
End of Month
DAI/ETH on hand.

Point here will be that there will rightly be some tendency to tap the emergency budget if funding runs low (either that or to have a contingency buffer).

I am supportive of the 3 month forward oracle gas cost (3.932M) (extra cost for new oracles).

Regarding emergency fund. It looks like 1.7M gives us 45days (at 2x current gas) of emergency funding. So if this 2x, 5x, 10x again we end up with 22.5, 9, 4.5days worth of emergency oracle funding. This gets a little dicey at 20x, 50x, 100x or 2.25, .9, .45days

Given this fund will just sit waiting for an emergency.
I would encourage it be used to purchase ETH and paired with DAI in the Uniswap or sushiswap v2 contract. I track ETH-DAI v2 LP earnings in uniswap and these are consistently running at 10%. The beauty of putting the oracle emergency funds into this contract is that it will earn return in ETH and DAI. Even if the ETH price quadruples we only lose 1/2 the ETH and gain 2x the DAI in that contract and can still buy all our ETH back. (price has to more than quadruple before we start losing ETH relative to the contract). The case where we expect high gas fees is when ETH price drops. IF ETH price drops by 75% the LP value drops by 1/2 and we end up with 2xETH + 1/2 DAI . This is actually a good way for the protocol to bet to profit if the ETH price drops. We can talk more about this as a strategy to deal with ETH costs btw because it earns significant return and hedges in the right way against ETH price dropping with a fund that should only rarely be used. ETH price going up 4x should more than double our earnings.

Regarding the last piece of this budget request the 3M to Maker Foundation Relief.

What I need to see here is an accounting of funds in
we have an accounting to 8/1-11/8 of 380ETH or 1.367M.
Now all of the above would be valid if we were dealing with an outside funding agent, but my understanding is that these funds came from the Maker Foundation. Correct me if I am wrong but the last I heard the Maker Foundation has ceased to exist - so who exactly would we be paying why?

My biggest problem brought up with this 3M request is a complete lack of financial accounting by Maker Foundation regarding its legal and financial dissolution into MakerDAO and where these funds are?


Perhaps we can use the ENS airdrop to cover some of these costs? Seems like it could almost cover the entire Maker Foundation refund, and we’d be done with it.
EDIT: This was discussed on the governance call - the sentiment was that it would be better hold the ENS tokens, which I agree with :slight_smile: