Most confusion about The Graph’s roadmap comes from reading a proposal as though it were a decision. The process distinguishes them clearly, and once you can tell them apart the ecosystem becomes considerably easier to follow.
GIP: the proposal.
A Graph Improvement Proposal is a written argument for a change. It lives in the public repository, carries a number, and goes through discussion on the forum.
A GIP has a status. Draft, under discussion, approved, and so on. A GIP existing means somebody wrote it down. It does not mean anybody agreed.
GIPs are also where the reasoning is recorded, which makes them the best documentation of why the protocol is shaped as it is. GIP-0051 on exponential rebates, for instance, explains the Cobb-Douglas problem more clearly than any secondary source, and openly records where the new mechanism could be gamed.
GGP: the vote.
A Graph Governance Proposal is what actually gets voted on. Several GIPs may be bundled into a release and voted as one GGP.
The vote happens on Snapshot, with each Council member able to vote. Six positive votes mean the proposal is accepted, which follows directly from the Council being a six-of-ten multisig.
Why two stages.
The separation does real work. Anyone can write a GIP, so the proposal stage is permissionless and open. Executing a change to contracts holding a great deal of value cannot be, so the decision stage is bounded and accountable.
Bundling into releases also reflects reality: protocol changes ship together, get audited together, and are deployed together. Voting on each individually would produce combinations nobody tested.
Reading status correctly.
This is the practical skill. When you read that The Graph “is adding” something, work out which stage it is at:
- A GIP in draft or discussion is somebody’s argument. It may never ship.
- A GIP approved but not deployed is decided and not yet real. The distinction matters if you are planning around it.
- A deployed change is current behaviour, and even then the tooling may lag, which the allocations lesson shows concretely.
Announcements, conference talks and enthusiastic threads routinely blur these. The repository does not, which is why it is worth going there.
A live example.
GIP-0089, the Innovation Allocation, is worth following through the whole pipeline because it completed recently and it changed real numbers.
It was written as a GIP, discussed publicly, approved by Council on 2026-08-26, and took effect on 2026-08-31, redirecting a share of protocol issuance to the Foundation treasury. The forum thread carries the argument, the figures and the objections.
Read it as a specimen of the process rather than only for its content. Everything about how change happens here is visible in that one thread.
What is the difference between a GIP and a GGP?
Proposal and decision are separate stages. Anyone can write a GIP, which keeps the proposal stage permissionless. Executing changes to contracts holding significant value is bounded and accountable instead.
How many positive Council votes accept a GGP?
Six, which follows directly from the Council being a six-of-ten multisig. The threshold is the multisig, not a separate rule layered on top of it.
You read that The Graph 'is adding' a feature. What should you check first?
A GIP existing only means somebody wrote it down. Approved but undeployed is decided and not yet real, and even deployed changes can outrun the tooling, as the allocation lifecycle shows.
0 of 3 answered