When you serve queries, you do not automatically keep the fees. A rebate function decides how much of what you generated actually reaches you, and the rest is burned.
The function changed in a way that matters enormously to how you should think, and a great deal of writing still describes the old one.
What Cobb-Douglas did wrong.
Under the previous mechanism, query fees went into rebate pools and were distributed by a formula that depended on the global state: how much everyone had staked and how much everyone had collected.
Two consequences followed, and both were bad.
You could not compute your own outcome. Your rebate depended on decisions other indexers had not made yet. Staking correctly meant predicting the field, which is a game about other people rather than about serving queries well.
It burned an enormous amount. Per GIP-0051, the old mechanism “historically has burned over over 50% of query fees”. Over half of the revenue the network generated never reached the people who earned it.
That second figure is the argument. A mechanism intended to encourage staking was destroying the majority of the network’s actual revenue.
What replaced it.
GIP-0051 defines the rebate to indexer i on subgraph j as:
R(q, s) = (1 - α · e^(−λ · s/q)) · q
q query fees you generated on that subgraph
s your stake on that subgraph
α, λ protocol parametersThe stated values are λ = 0.6 and α = 1.
The important property is what is missing. There is no term for anybody else. Per the GIP, “only the i-th indexer can claim query fees it generates and its rebate does not depend on the staking levels of any other indexer.”
The curve, and where it stops mattering.
The only input is the stake ratio, your stake divided by the fees you generated.
Lambda and alpha are the values proposed in GIP-0051. The deployed values sit in contract storage and governance can move them, so read the contract before sizing real stake. Note what the curve does past a ratio of 8: almost nothing. In 2022 the average ratio was well over 1000, which is why in practice indexers keep effectively all of their query fees.
GIP-0051 gives the reference points, and they reproduce exactly at the stated parameters: a ratio of 4 returns about 90% of fees, 6 returns about 97%, and 8 returns over 99%.
Push the ratio past 8 in the calculator and watch what happens. Almost nothing. The curve is effectively flat there, which means additional stake on that subgraph buys you almost no additional rebate.
That is the actionable finding. Stake beyond the point where the curve flattens is not improving your rebate, and it could be allocated somewhere it does something.
What this looks like in practice.
The GIP is blunt about the real distribution: “For calendar year 2022, the average stake ratio was significantly greater than 1000 and 90% of the time indexers collected rebates, their stake ratio was over 1000. This implies that at current stake levels, effectively all query fees will be returned to indexers.”
So for most indexers most of the time, the rebate is not a live constraint. Your stake vastly exceeds the fees on any single subgraph, and you keep essentially all of them.
Worth understanding anyway, for two reasons. It tells you the shape of the incentive if query volumes rise substantially relative to stake, and it tells you that allocating stake in pursuit of rebate improvement is optimising something that is already at its maximum.
The multi-gateway detail.
Worth knowing because it is unintuitive. If your fees on a subgraph come through several gateways, the rebate is computed per gateway voucher against the portion of fees from that gateway, not against the total.
Since the ratio is stake over fees and the per-gateway fee figure is smaller, the ratio is higher, and you clear the curve more easily. The GIP notes this openly and notes the risk that follows: splitting vouchers into small enough chunks would guarantee a full rebate and bypass the mechanism entirely.
That is a good example of the protocol’s design documents recording where a mechanism could be gamed rather than omitting it, and it is worth reading GIP-0051 directly for that quality alone.
Before reading on: if effectively all query fees are already returned, why keep a rebate function at all?
Because the mechanism has to hold at volumes the network does not yet have.
The rebate ties fee collection to stake, so an indexer serving large query volume must have committed capital in proportion. Remove it and an operator could collect substantial fees with minimal stake, which is minimal exposure to being slashed for serving those queries wrongly.
Today stake is enormous relative to fees, so the constraint does not bind and the curve returns essentially everything. That is the mechanism working as intended in a low-demand regime, not a mechanism that has become pointless. If query revenue grows by orders of magnitude, the ratio falls and it starts to bind again, which is exactly when you would want it to.
Under exponential rebates, your rebate depends on:
Only your own state. That is the headline improvement over Cobb-Douglas, where the outcome depended on decisions other indexers had not made yet, so staking correctly meant predicting the field.
Roughly what proportion of query fees did the Cobb-Douglas mechanism historically burn?
Over half, per GIP-0051. A mechanism meant to encourage staking was destroying the majority of the network's actual revenue, which is the argument the GIP makes for replacing it.
Your stake ratio on a subgraph is already 12. Adding more stake there will:
At a ratio of 8 you already keep over 99% of fees, so there is almost nothing left to gain. Stake beyond that point is not improving your rebate and could be doing something elsewhere.
0 of 3 answered