---
title: Graph Horizon Overview
sidebarTitle: Horizon Overview
---

This document provides a high level overview of Graph Horizon. For a deep dive the following GIPs are recommended:

- [GIP-0066: Introducing Graph Horizon - A data services protocol](https://github.com/graphprotocol/graph-improvement-proposals/blob/3da23cbba56fbd211de61f08c60b8c3e93ba5bc5/gips/0066-graph-horizon.md)
- [GIP-0068: Subgraph Service - A subgraph data service in Graph Horizon](https://github.com/graphprotocol/graph-improvement-proposals/blob/3da23cbba56fbd211de61f08c60b8c3e93ba5bc5/gips/0068-subgraph-service.md)
- [GIP-0085: Graph Horizon: Arbitration Charter](https://github.com/graphprotocol/graph-improvement-proposals/blob/3da23cbba56fbd211de61f08c60b8c3e93ba5bc5/gips/0085-horizon-arbitration-charter.md)

The Graph Protocol is evolving with Horizon, a major upgrade that transforms the protocol into a more flexible and modular data services platform. While The Graph's core mission of organizing the world's public data remains unchanged, Horizon introduces a new architecture that enables permissionless innovation and improved economic mechanisms.

This upgrade represents the next evolution of The Graph, making it more composable, efficient, and capable of supporting various types of data services beyond just subgraphs.

## Graph Horizon in a nutshell

The Graph Protocol as originally designed and launched back in 2021 is comprised of three distinct parts:

- Staking mechanisms to provide economic security to the network
- Payments mechanisms to allow users to pay for access to data
- Support for the subgraphs use case

The protocol achieves this goals very well however it was designed specifically with the subgraph use case in mind. This resulted in those three components being very tightly coupled, making changes to the protocol hard to do and risky, and also not providing enough flexibility to support other use cases.

Graph Horizon’s main goal is to transform The Graph into a protocol capable of serving a multitude of data services, not just subgraphs. It achieves this by extracting the core functionality into primitives that can be reused by arbitrary data service implementations:

- Core staking protocol
- Core payments protocol
- Arbitrary data service implementations

These primitives can be permissionlessly composed by developers by means of the Data Service Framework.

## The Data Service Framework

Horizon introduces a modular Data Service Framework that allows different types of data services to be built on top of The Graph's core staking and payments infrastructure.

The **`SubgraphService`** is the first and currently only data service implementation, supporting the existing functionality of indexing subgraphs and serving queries. This modular approach means that in the future, other data services could be added to support different use cases like SQL queries, data streams, or other data delivery mechanisms. A key benefit of Horizon is that new data services can be developed and deployed permissionlessly with minimal cost and development time, as they can leverage the existing staking and payments infrastructure.

## Enhanced Payment System

### Integrated Payments Protocol

Horizon brings the payments infrastructure directly into the core protocol. The payments protocol in Horizon was designed as a generalized framework, with [GraphTally](/indexing/tap) (formerly TAP) as the integrated payment collection system. This architecture also supports other arbitrary payment collection systems in the future.

### GraphPayments and PaymentsEscrow

A new set of contracts `GraphPayments` and `PaymentsEscrow` contracts handle the escrow and distribution of fees to all relevant parties. This contracts enforce things like the protocol tax and ensures that payments are properly distributed between data services, delegators, and indexers, making the payment process transparent.
