Thank you, Pablo and the team, for publicly explaining in detail the nature of the long-discussed Horizon. Special kudos for even providing prototype smart contracts! I understand Horizon as a new, minimal set of contracts focused on basic staking functionality, which forms the foundation for adding modules with their own rules. These modules are essentially individual Data Services (GraphQL, SQL, Substreams, Firehose, etc.), linked to the core contracts.
-
Green v. Brown
In the context of The Graph expanding to additional data services, adopting a greenfield approach is tempting. Deploying the Horizon contracts sooner rather than later would facilitate the introduction of new data services using the new staking mechanism. This approach allows for the quick launch of these services, enabling us to refine the tooling and address any issues as demand gradually increases. Subsequently, we can consider migrating the “legacy” monolithic L2 staking to the new staking layer. This migration might resemble the L1 to L2 migration that is nearing completion. This is assuming that time-to-market for these new services is crucial, and that deploying them to the legacy staking system is not a simple or preferable alternative. -
Liquid staking and Restaking?
Considering the simplicity of the core functionality and the delegation of reward, slashing, and other business logic to higher-level smart contracts, I wonder if there has been any consideration of applications external to data services. Given its permissionless nature, it seems anyone could develop various applications, including lending, liquid staking and restaking. Will the contracts include any constraints to limit these uses to applications more central to The Graph’s vision around data? It seems there will be some governance (for “limited-upgradability”) so it may be possible enforce some rules. It is interesting to see that the prototype Horizon contracts has a Lending example. -
Economics of new Data Services
Additionally, are there discussions or proposals for further modifications to the Graph mechanisms? We are aware of the Direct Indexer Rewards and its implications on Curation, but are there expectations for other proposals, or is the Horizon proposal considered the final stage? The individual data service might be good areas for innovation on the economics, I’m wondering if you are already considering new mechanisms. Also curious to hear about potential arbitration implementation. -
Consumer choice dilemma
I don’t want to veer too far off into indexing reward topics, as those are more suitable for the DIP GIP discussions. However, I will address the points raised in the original post. The current in-protocol rewards (indexing rewards) enable the protocol to support a broad range of indexers, contributing to the high-quality service the protocol currently offers. With direct indexer payments, the responsibility for sustaining the indexing ecosystem shifts from the protocol to private entities (gateway operators). While every good gateway operator will understand that a diverse range of indexers enhances performance and resilience, this diversity incurs costs. In the long term, it’s natural for gateway operators to seek cost minimization. The current indexing rewards system, despite seeming inefficient, absorbs this extra cost for the benefit of all.
My concern is that these changes might transition us from a model with a few gateway operators and numerous indexers to one with a handful of large indexers serving every gateway operator, fostering direct relationships and long-term commitments. This could lead to further consolidation between gateways and indexers, with gateway operators potentially running their own in-house indexers. Such market dynamics might not be favorable to a strong GRT ecosystem.
I struggle to find many real-life parallels to a scenario where an entity retains multiple providers. This typically occurs when the job-donor holds a dominant or monopolistic position, such as government agencies or the military. These organizations deliberately support multiple contractors to foster competition and ensure future alternatives. In a similar vein, E&N currently plays this role regarding query fees, distributing queries equitably among all capable indexers. The indexing rewards system complements this by handling the remaining aspects.
Again thank you for sharing this description with the community. As always the more that is shared, the more I’m eager to know more so please continue with this approach of posting updates and research tidbits before proposals are finalized.