We propose an Issuance Allocator, a governance-controlled contract that manages how token issuance is distributed across protocol components.
Today, all issuance goes to the Rewards Manager, which distributes it as indexing rewards based on stake and curation signal. This has been successful in bootstrapping a healthy network of indexers, but indexing rewards are not linked to the value actually delivered to consumers; an indexer earns the same rewards regardless of service quality. GIP-0070: Evolving The Graph Protocol Economics identified this gap and proposed migrating issuance distribution toward mechanisms that align rewards with consumer value delivered, while maintaining the network balance that issuance provides.
The Issuance Allocator enables incremental introduction of new distribution mechanisms to improve incentive alignment and network health. It introduces a layer above the Rewards Manager so that governance can split the total issuance rate across multiple targets, including mechanisms like indexing agreements that link payment to service delivery, without changing the overall rate.
The allocator supports two types of targets:
- Self-minting: Targets that mint their own tokens (like the existing Rewards Manager). The allocator provides the issuance rate; the target mints.
- Allocator-minting: Targets that receive tokens minted directly by the allocator. New targets are expected to use this model.
This is a building block. No change to issuance distribution is proposed in this GIP; the allocator is deployed with the Rewards Manager as the sole target at 100%. Separate governance proposals configure additional targets and their allocations. Following the iterative approach outlined in GIP-0070, this creates infrastructure that allows new distribution mechanisms to be added alongside existing ones, enabling gradual migration without disrupting the network balance that existing issuance provides.
Just want to understand a difference between self-minting (SM) and allocator-minting (AM) targets. Today, for SM, if an Indexer is inelligible to receive rewards (be it for going over 28 epochs before closing an allocation, submitting a 0x0 POI, etc) then the proportional issuance that could have been minted, simply never was.
For AM targets, would the issuance target be the end provider of that data service? Or a shim in between? (be it a vault, a contract, a governance board, wtvr)
Just wanting to understand if on NewDataService, if there are 10 providers that were included into the issuance calculations, but for some reason Indexer9 is not actually eligible to claim rewards, were those rewards ever issued (and deposited into somewhere), or would it be similar to how it happens with the Rewards Manager currently? (or does it depend, on a case by case basis as written into that Data Service Deployment?)
Good question, I hope the answer becomes clearer if I first explain the purpose.
The Rewards Manager contract, which is responsible for managing indexing rewards, was designed as the minting authority. We do want to re-write the Rewards Manager, we want it to keep operating the way it currently does. That is why the Issuance Allocator has a self-minting mode, so that Rewards Manager can keep running the way it does. The Rewards Manager now looks up the rate from the Issuance Allocator now but manages minting within that budget.
In the case of the Rewards Manager it can and does under certain circumstances simply not mint, which would not be the model for allocator minting where the Allocator would mint the entire amount and allow the target mechanism to operate within its budget.
For robust management of overall issuance budget we want to limit the minting authorities, and separate the role of distribution from that of minting. New mechanisms are expected to operate on this basis and have allocator minting.
It might help to understand that the Rewards Manager is not a data service, it is rewards distribution mechanism built into the protocol. The Issuance Allocator does not split issuance between data services, it splits issuance between distribution mechanisms.
The difference might seem less clear currently because Rewards Manager was not designed for a context with multiple data services, and there is only one data service (the Subgraph Service) being distributed to currently.
The Issuance Allocator does not split issuance between data services. It was not designed for that; that is contrary to protocol design and does not fit the distribution model.