We can now track total, daily, and hourly rebates earned by makers. Initially this update was so we can display it on defi llama, but we can plug this in wherever we're using Metrics subgraphs.
Currently (July 12) the RubiconMetricsOptimism subgraph is 7 days into syncing with a few days left. RubiconMetricsArbitrum is fully synced. Neither of these are updated with these fee changes so we can't display fees on defi llama. If we wanted to re-sync with these changes, we would have (possibly) 12ish days of downtime on RubiconMetricsOptimism and only a few hours of downtime on RubiconMetricsArbitrum. Too much downtime for us to handle right now with all the new users from OP rewards and arb launch. Maybe wait until we have our own archival node (I assume syncing on our own archival is faster than hosted service).
Schema changes
New entities: HourMakerRebateVolume and DayMakerRebateVolume follow same pattern as HourVolume and DayVolume.
New field on Rubicon entity: total_maker_rebate_volume_usd tracks the total amount of fees paid to makers in USD.
Handler changes
All new fields and entities are updated in new event handler handleFee that handles the emitFee event.
First, the handleFee checks if the emitFee event is paid to a maker:
from Metrics/src/utils/entities/fee.ts
if (event.params.feeTo == rubiconMarket.getFeeTo()){
// this emitFee event is NOT a maker rebate
}
else {
// this emitFee event is a maker rebate
}
Then it follows the same pattern as handleLogTake to convert event.params.feeAmt into USD value of event.params.asset (asset that was paid to maker) and update Rubicon, HourMakerRebateVolume, and DayMakerRebateVolume.
Other changes
Added Metrics/src/utils/entities/fee.ts which contains function isFeeMakerRebate(event: emitFee). This function makes a call to a deployed RubiconMarket to check if the address the fee was sent to is the protocol's feeTo address.
Added RubiconMarket addresses to Metrics/src/prices/config/arbitrumOne.ts and optimism.ts
Notes
I went back and forth between referring to the new entities as rebates or revenue or fee. I settled on rebates because that is what they are referred to in our docs https://docs.rubicon.finance/protocol/rubicon-market/fees but I can make a switch.
I wasn't sure where the best place to cleanly add isFeeMakerRebate(emitFee) was. Let me know where I should move it to and if I should separate out the portions where it connects to the contract and makes the call into separate components for better organization.
TODOs
Could easily update the schema to also track protocol revenue from fees if we want. Would need to update handleFee to not immediately return if fee is paid to the protocol and add logic inside that check.
We can now track total, daily, and hourly rebates earned by makers. Initially this update was so we can display it on defi llama, but we can plug this in wherever we're using
Metrics
subgraphs.Currently (July 12) the
RubiconMetricsOptimism
subgraph is 7 days into syncing with a few days left.RubiconMetricsArbitrum
is fully synced. Neither of these are updated with these fee changes so we can't display fees on defi llama. If we wanted to re-sync with these changes, we would have (possibly) 12ish days of downtime onRubiconMetricsOptimism
and only a few hours of downtime onRubiconMetricsArbitrum
. Too much downtime for us to handle right now with all the new users from OP rewards and arb launch. Maybe wait until we have our own archival node (I assume syncing on our own archival is faster than hosted service).Schema changes
New entities:
HourMakerRebateVolume
andDayMakerRebateVolume
follow same pattern asHourVolume
andDayVolume
.New field on
Rubicon
entity:total_maker_rebate_volume_usd
tracks the total amount of fees paid to makers in USD.Handler changes
All new fields and entities are updated in new event handler
handleFee
that handles theemitFee
event.First, the
handleFee
checks if theemitFee
event is paid to a maker:Then it follows the same pattern as
handleLogTake
to convertevent.params.feeAmt
into USD value ofevent.params.asset
(asset that was paid to maker) and updateRubicon
,HourMakerRebateVolume
, andDayMakerRebateVolume
.Other changes
Added
Metrics/src/utils/entities/fee.ts
which contains functionisFeeMakerRebate(event: emitFee)
. This function makes a call to a deployed RubiconMarket to check if the address the fee was sent to is the protocol'sfeeTo
address.Added
RubiconMarket
addresses toMetrics/src/prices/config/arbitrumOne.ts
andoptimism.ts
Notes
rebates
orrevenue
orfee
. I settled onrebates
because that is what they are referred to in our docs https://docs.rubicon.finance/protocol/rubicon-market/fees but I can make a switch.isFeeMakerRebate(emitFee)
was. Let me know where I should move it to and if I should separate out the portions where it connects to the contract and makes the call into separate components for better organization.TODOs
Could easily update the schema to also track protocol revenue from fees if we want. Would need to update
handleFee
to not immediately return if fee is paid to the protocol and add logic inside that check.