Horizon went live on 2025-12-11. The idea behind it was written down on 2022-12-01, three years earlier, in a proposal that never mentions Horizon by name.
Following that thread is the clearest illustration available of how this protocol actually changes, and it is all in public.
2022: somebody writes down what is wrong
GIP-0042, “A World of Data Services”, opens with an admission that would not appear in marketing material:
subgraphs are not well-suited for a number of use cases
The argument has two halves. Developers had been saying for years that analytics pipelines and anything combining chain data with off-chain sources fit subgraphs badly. And a healthy indexer network “requires specialization and reuse of data already generated by the network”: one operator running Firehose, another doing Substreams processing, another serving subgraphs, trading with each other.
The proposal’s insight is the part worth stealing. The protocol already had a decentralised market for one kind of data. It “merely needs to be extended to support more data services”. Not a new protocol. A generalisation of the noun.
2024: the design lands
GIP-0066 was created on 2024-05-03 and last updated on 2025-03-06. It describes itself as “the result of almost two years of work from researchers and developers from various core dev teams”, and it does not arrive alone: it depends on GIP-0068, the Subgraph Service, and says the two “should be treated as a unit, meaning one cannot be implemented without the other”.
That pairing is itself a design statement. Horizon is the substrate, and the thing everyone currently uses had to be rebuilt as an application on top of it before the substrate could be said to work. If the first data service could not be expressed in the new primitives, the primitives were wrong.
Two vocabulary choices in it are worth noticing, because vocabulary is where intent leaks.
The GIP uses service provider, not indexer, and says why: to “accommodate any future data services where the indexing term might not make sense”. And it notes that “a lot of DePIN use-cases could be served by the same primitives”. Neither is a promise. Both tell you what the authors thought they were building.
The decision that actually mattered: brownfield
The interesting choice is not the architecture. It is the transition.
GIP-0066 records that “the Graph Council has expressed support for the brownfield approach”, against the alternative of greenfield.
Greenfield means deploying the new protocol alongside the old one and moving everybody across. Clean contracts, no compatibility burden, and a migration that every indexer, delegator and curator has to actively perform, with the network split in two while it happens.
Brownfield means upgrading the existing contracts in place. Everyone’s stake, delegation and signal stays where it is. The cost is paid by the engineers: every new mechanism has to coexist with the state left by the old one, and the proposal carries a “Backward Compatibility” section and a whole set of “data service restrictions during transition period”.
You can see the price of that choice in the protocol today. It is why allocations are indefinite in the protocol but still recycled by the shipped stack, and why several parameters exist in a capability-present-but-switched-off state, like delegated stake slashing. Those are not oversights. They are what a brownfield transition looks like from the inside.
Before reading on: why choose the option that is harder to build?
Because the difficulty was moved to the people best placed to absorb it.
A greenfield migration is easier to engineer and pushes the work onto every participant: thousands of people who did not choose this project, on their own time, each of whom can fail to act. A protocol whose security rests on staked capital cannot casually ask all of that capital to move.
Brownfield keeps the hard part with the core developers, who are paid to do it and can be held to it through governance. The visible cost, the transition-period restrictions and the switched-off capabilities, lands on people who read GIPs rather than on a delegator who has not opened Explorer in a year.
There is a version of this decision that is just conservatism. This one is not: it is a choice about who carries the risk of a migration, and it put the risk on the parties who understood it.
How to follow a thread like this yourself
Every GIP names its dependencies and its prior art. GIP-0066’s “Prior Art” section links GIP-0042, GIP-0054 for payments, and GIP-0058 for curation, which is how you reconstruct a three-year argument in an afternoon.
The forum thread on each proposal carries the objections, which the merged document does not. Read both. A GIP tells you what was decided; its thread tells you what was contested.