• A monolithic protocol controlled by the Council is hard to extend to add more data services, and imposes unnecessary restrictions by making it permissioned
  • Horizon addresses this by allowing data services to be permissionlessly added as a field in stake deposits / allocations (even if the Council keeps rewards for only a permissioned subset)
• The current protocol’s mechanism for allocations provides a very restrictive API for implementing data services. There is no way to use different arbitration mechanisms, dispute periods, fee distribution logic, or include any additional data for allocations other than a subgraph deployment ID.
  • Horizon addresses this by making allocations or stake deposits a generic interface for arbitrary data services with permissionless configuration of dispute periods, arbitration, and any other relevant parameters.
• Delegation does not meaningfully contribute to economic security: it may act as a signal for how trustworthy an Indexer is, but it does not actually increase protection for consumers
  • Horizon addresses this by making delegation slashable
• Indexing Rewards involve many centralization risks where the Council could stop a subgraph (SAO, EBO, issuance config, arbitration), so having them as the only mechanism to get a subgraph indexed is not censorship-resistant
  • Horizon addresses this by introducing indexing fees as a way to get a subgraph indexed (even if rewards are denied), reducing the scope of these centralization risks
• Indexing Rewards are finite, and potential growth of the network is not, so Indexing Rewards can eventually be insufficient to cover new subgraphs
  • Horizon addresses this by introducing indexing fees as a way to get a subgraph indexed (even if rewards are insufficient)
• Indexing Rewards based on Curation to get subgraphs indexed provides no predictability for consumers or Indexers, as actions by other actors may affect the profitability of Indexing a subgraph
  • Horizon addresses this by introducing indexing fees as a way to get a subgraph indexed (even if rewards are insufficient)
• Based on research results, there is no way to produce a fully permissionless mechanism to reward Indexing that is Sybil-resistant and not gameable - therefore we have no way to make a fully permissionless protocol unless we move rewards outside of the core flow
  • Horizon addresses this by introducing indexing fees as a way to get a subgraph indexed (even if rewards are denied) and opens a path to plug issuance as an external way to incentivize desired outcomes (e.g. create indexing fees agreements, or subsidize actors directly)
• The current mechanisms for rewards and rebates redirect a large percentage of consumer-to-indexer payments to other places (curators, taxes), which in the long run can mean unsustainable prices or giving advantage to centralized competitors
  • Horizon addresses this by adding an alternative to rebates (requiring a specific amount of stake to collect a specific amount of fees), and by allowing permissionless data service to configure variable values for curator fees / taxes / etc as desired by the data service dev
• The core Staking contract being upgradeable is a huge centralization risk, as a malicious or compromised Council could essentially take all the Indexers and Delegators’ tokens
  • Horizon addresses this by either deploying a new non-upgradeable Staking contract, or removing upgradeability of the Staking contract (after reducing its scope and applying all required changes for permissionless data services)
• Building UX-improving subscriptions on top of opaque mechanisms adds costs to the subscriptions and makes The Graph less competitive.
  • Horizon addresses this by enabling clear and transparent pricing on indexing fees (in parallel to rewards, until rewards change)

These are problems that may be solved depending on how we implement Horizon (there are other tradeoffs):

• Per-subgraph allocations are expensive
  • If we change to deposits/allocations at the data service level, Horizon would fix this as there’d be no need for subgraph-specific ongoing transactions
• Choosing what Indexer to delegate to is hard
  • If we deploy a new delegation mechanism based on pools, then Horizon would fix this by allowing delegators to choose a pool that delegates to many Indexers. Alternatively, this can be solved extra-protocol by liquid delegation providers like Tenderize.