graphprotocol · benface · Apr 23, 2025 · Apr 23, 2025 · Apr 23, 2025 · Apr 23, 2025
@@ -1,67 +1,55 @@
 ---
-title: حول The Graph
+title: About The Graph
+description: This page summarizes the core concepts and basics of The Graph Network.
 ---
 
-## What is The Graph?
+## Explanation
 
-The Graph is a powerful decentralized protocol that enables seamless querying and indexing of blockchain data. It simplifies the complex process of querying blockchain data, making dapp development faster and easier.
+### What is The Graph?
 
-## Understanding the Basics
+The Graph is a decentralized protocol for indexing and querying blockchain data. Its suite includes [Subgraphs](/subgraphs/developing/subgraphs/), [Substreams](/substreams/introduction/), [Token API BETA](/token-api/quick-start/), and tools like [Graph Explorer](/subgraphs/explorer/) and [Subgraph Studio](/subgraphs/developing/deploying/using-subgraph-studio/).
 
-Projects with complex smart contracts such as [Uniswap](https://uniswap.org/) and NFTs initiatives like [Bored Ape Yacht Club](https://boredapeyachtclub.com/) store data on the Ethereum blockchain, making it very difficult to read anything other than basic data directly from the blockchain.
+The Graph supports [90+ blockchains](/supported-networks/), enhancing dapp development and data retrieval.
 
-### Challenges Without The Graph
+### Why is Blockchain Data Hard to Query?
 
-In the case of the example listed above, Bored Ape Yacht Club, you can perform basic read operations on [the contract](https://etherscan.io/address/0xbc4ca0eda7647a8ab7c2061c2e118a18a936f13d#code). You can read the owner of a certain Ape, read the content URI of an Ape based on their ID, or read the total supply.
+Reading onchain data from the blockchain (e.g., ownership history, metadata, relationships between assets) typically requires processing smart contract events, parsing metadata from IPFS, and aggregating data manually. This is very slow, complex, and resource-intensive.
 
-- This can be done because these read operations are programmed directly into the smart contract itself. However, more advanced, specific, and real-world queries and operations like aggregation, search, relationships, and non-trivial filtering, **are not possible**.
+## Solution
 
-- For instance, if you want to inquire about Apes owned by a specific address and refine your search based on a particular characteristic, you would not be able to obtain that information by directly interacting with the contract itself.
+### How The Graph Solves This
 
-- To get more data, you would have to process every single [`transfer`](https://etherscan.io/address/0xbc4ca0eda7647a8ab7c2061c2e118a18a936f13d#code#L1746) event ever emitted, read the metadata from IPFS using the Token ID and IPFS hash, and then aggregate it.
+The Graph simplifies the complex process of retrieving blockchain data through a global, decentralized network of Indexers that index Subgraphs. This infrastructure facilitates efficient, censorship-resistant query handling, allowing developers to build applications using blockchain data without the hassle of managing servers or custom indexing.
 
-### Why is this a problem?
+Each Subgraph defines:
 
-It would take **hours or even days** for a decentralized application (dapp) running in a browser to get an answer to these simple questions.
+- Which smart contracts to watch
+- Which events to extract
+- How to map event data into a queryable format using [GraphQL](https://graphql.org/learn/)
 
-Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/resources/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
+### [Building a Subgraph](/subgraphs/developing/creating/starting-your-subgraph/)
 
-Blockchain properties, such as finality, chain reorganizations, and uncled blocks, add complexity to the process, making it time-consuming and conceptually challenging to retrieve accurate query results from blockchain data.
+1. Define a [Subgraph Manifest](/subgraphs/developing/creating/subgraph-manifest/) with data sources and mappings.
+2. Use [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) to deploy the manifest to IPFS.
+3. An [Indexer](/indexing/overview/) picks it up and starts indexing Ethereum blocks.
+4. Data becomes queryable via a [GraphQL endpoint](/subgraphs/querying/graphql-api/).
 
-## The Graph Provides a Solution
+### Data Flow Overview
 
-The Graph solves this challenge with a decentralized protocol that indexes and enables the efficient and high-performance querying of blockchain data. These APIs (indexed "Subgraphs") can then be queried with a standard GraphQL API.
+1. A dapp triggers a transaction on Ethereum by interacting with a smart contract.
 
-Today, there is a decentralized protocol that is backed by the open source implementation of [Graph Node](https://github.com/graphprotocol/graph-node) that enables this process.
+2. As the transaction is processed, the smart contract emits one or more events.
 
-### How The Graph Functions
+3. [Graph Node](/indexing/tooling/graph-node/) continuously scans the Ethereum blockchain for new blocks and filters for events relevant to a deployed Subgraph.
 
-Indexing blockchain data is very difficult, but The Graph makes it easy. The Graph learns how to index Ethereum data by using Subgraphs. Subgraphs are custom APIs built on blockchain data that extract data from a blockchain, processes it, and stores it so that it can be seamlessly queried via GraphQL.
+4. When a matching event is identified, Graph Node executes the Subgraph’s mapping logic, which is a WASM module that transforms event data into structured entities. These entities are subsequently stored and indexed.
 
-#### Specifics
-
-- The Graph uses Subgraph descriptions, which are known as the Subgraph manifest inside the Subgraph.
-
-- The Subgraph description outlines the smart contracts of interest for a Subgraph, the events within those contracts to focus on, and how to map event data to the data that The Graph will store in its database.
-
-- When creating a Subgraph, you need to write a Subgraph manifest.
-
-- After writing the `subgraph manifest`, you can use the Graph CLI to store the definition in IPFS and instruct an Indexer to start indexing data for that Subgraph.
+5. The dapp queries the Graph Node via a [GraphQL API](https://graphql.org/learn/), retrieving indexed data to render in the UI. Users can then take actions that generate new transactions, continuing the cycle.
 
 The diagram below provides more detailed information about the flow of data after a Subgraph manifest has been deployed with Ethereum transactions.
 
 ![A graphic explaining how The Graph uses Graph Node to serve queries to data consumers](/img/graph-dataflow.png)
 
-تدفق البيانات يتبع الخطوات التالية:
-
-1.  A dapp adds data to Ethereum through a transaction on a smart contract.
-2.  العقد الذكي يصدر حدثا واحدا أو أكثر أثناء معالجة الإجراء.
-3.  Graph Node continually scans Ethereum for new blocks and the data for your Subgraph they may contain.
-4.  Graph Node finds Ethereum events for your Subgraph in these blocks and runs the mapping handlers you provided. The mapping is a WASM module that creates or updates the data entities that Graph Node stores in response to Ethereum events.
-5.  The dapp queries the Graph Node for data indexed from the blockchain, using the node's [GraphQL endpoint](https://graphql.org/learn/). The Graph Node in turn translates the GraphQL queries into queries for its underlying data store in order to fetch this data, making use of the store's indexing capabilities. The dapp displays this data in a rich UI for end-users, which they use to issue new transactions on Ethereum. The cycle repeats.
-
 ## الخطوات التالية
 
-The following sections provide a more in-depth look at Subgraphs, their deployment and data querying.
-
-Before you write your own Subgraph, it's recommended to explore [Graph Explorer](https://thegraph.com/explorer) and review some of the already deployed Subgraphs. Each Subgraph's page includes a GraphQL playground, allowing you to query its data.
+Explore [Graph Explorer](https://thegraph.com/explorer) to view and query existing Subgraphs.
@@ -79,10 +79,22 @@
         "title": "Subgraph quick start",
         "description": "Kickstart your journey into subgraph development."
       },
-      "substreams": {
-        "title": "متعدد-السلاسل",
+      "substreamsQuickStart": {
+        "title": "Substreams quick start",
         "description": "Stream high-speed data for real-time indexing."
       },
+      "tokenapi": {
+        "title": "The Graph's Token API",
+        "description": "Query token data and leverage native MCP support."
+      },
+      "graphExplorer": {
+        "title": "Graph Explorer",
+        "description": "Find and query existing blockchain data."
+      },
+      "substreamsDev": {
+        "title": "Substreams.dev",
+        "description": "Access tutorials, templates, and documentation to build custom data modules."
+      },
       "timeseries": {
         "title": "Timeseries & Aggregations",
         "description": "Learn to track metrics like daily volumes or user growth."
@@ -109,12 +121,16 @@
         "title": "Substreams.dev",
         "description": "Access tutorials, templates, and documentation to build custom data modules."
       },
+      "customSubstreamsSinks": {
+        "title": "Custom Substreams Sinks",
+        "description": "Leverage existing Substreams sinks to access data."
+      },
       "substreamsStarter": {
         "title": "Substreams starter",
         "description": "Leverage this boilerplate to create your first Substreams module."
       },
       "substreamsRepo": {
-        "title": "Substreams repo",
+        "title": "Substreams GitHub repository",
         "description": "Study, contribute to, or customize the core Substreams framework."
       }
     }

@@ -25,7 +25,7 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`، ضمن طلب دفعة استدعاء الإجراء عن بُعد باستخدام تمثيل كائنات جافا سكريبت
-- `trace_filter` *(limited tracing and optionally required for Graph Node)*
+- `trace_filter` _(limited tracing and optionally required for Graph Node)_
 
 ### 2. Firehose Integration
 

@@ -110,12 +110,12 @@ Indexers may differentiate themselves by applying advanced techniques for making
 - **Medium** - Production Indexer supporting 100 Subgraphs and 200-500 requests per second.
 - **Large** - Prepared to index all currently used Subgraphs and serve requests for the related traffic.
 
-| Setup | Postgres<br />(CPUs) | Postgres<br />(memory in GBs) | Postgres<br />(disk in TBs) | VMs<br />(CPUs) | VMs<br />(memory in GBs) |
-| --- | :-: | :-: | :-: | :-: | :-: |
-| Small | 4 | 8 | 1 | 4 | 16 |
-| Standard | 8 | 30 | 1 | 12 | 48 |
-| Medium | 16 | 64 | 2 | 32 | 64 |
-| Large | 72 | 468 | 3.5 | 48 | 184 |
+| Setup    | Postgres<br />(CPUs) | Postgres<br />(memory in GBs) | Postgres<br />(disk in TBs) | VMs<br />(CPUs) | VMs<br />(memory in GBs) |
+| -------- | :------------------: | :---------------------------: | :-------------------------: | :-------------: | :----------------------: |
+| Small    |           4          |               8               |              1              |        4        |            16            |
+| Standard |           8          |               30              |              1              |        12       |            48            |
+| Medium   |          16          |               64              |              2              |        32       |            64            |
+| Large    |          72          |              468              |             3.5             |        48       |            184           |
 
 ### What are some basic security precautions an Indexer should take?
 
@@ -147,20 +147,20 @@ Note: To support agile scaling, it is recommended that query and indexing concer
 
 #### Graph Node
 
-| Port | Purpose | Routes | CLI Argument | Environment Variable |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP server<br />(for Subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port | - |
-| 8001 | GraphQL WS<br />(for Subgraph subscriptions) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port | - |
-| 8020 | JSON-RPC<br />(for managing deployments) | / | \--admin-port | - |
-| 8030 | Subgraph indexing status API | /graphql | \--index-node-port | - |
-| 8040 | Prometheus metrics | /metrics | \--metrics-port | - |
+| Port | Purpose                                         | Routes                                         | CLI Argument       | Environment Variable |
+| ---- | ----------------------------------------------- | ---------------------------------------------- | ------------------ | -------------------- |
+| 8000 | GraphQL HTTP server<br />(for Subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                    |
+| 8001 | GraphQL WS<br />(for Subgraph subscriptions)    | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                    |
+| 8020 | JSON-RPC<br />(for managing deployments)        | /                                              | \--admin-port      | -                    |
+| 8030 | Subgraph indexing status API                    | /graphql                                       | \--index-node-port | -                    |
+| 8040 | Prometheus metrics                              | /metrics                                       | \--metrics-port    | -                    |
 
 #### Indexer Service
 
-| Port | Purpose | Routes | CLI Argument | Environment Variable |
-| --- | --- | --- | --- | --- |
-| 7600 | GraphQL HTTP server<br />(for paid Subgraph queries) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | \--port | `INDEXER_SERVICE_PORT` |
-| 7300 | Prometheus metrics | /metrics | \--metrics-port | - |
+| Port | Purpose                                              | Routes                                                      | CLI Argument    | Environment Variable   |
+| ---- | ---------------------------------------------------- | ----------------------------------------------------------- | --------------- | ---------------------- |
+| 7600 | GraphQL HTTP server<br />(for paid Subgraph queries) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | \--port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Prometheus metrics                                   | /metrics                                                    | \--metrics-port | -                      |
 
 #### Indexer Agent
 

@@ -77,13 +77,13 @@ A complete Kubernetes example configuration can be found in the [indexer reposit
 
 When it is running Graph Node exposes the following ports:
 
-| Port | Purpose | Routes | CLI Argument | Environment Variable |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP server<br />(for Subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port | - |
-| 8001 | GraphQL WS<br />(for Subgraph subscriptions) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port | - |
-| 8020 | JSON-RPC<br />(for managing deployments) | / | \--admin-port | - |
-| 8030 | Subgraph indexing status API | /graphql | \--index-node-port | - |
-| 8040 | Prometheus metrics | /metrics | \--metrics-port | - |
+| Port | Purpose                                         | Routes                                         | CLI Argument       | Environment Variable |
+| ---- | ----------------------------------------------- | ---------------------------------------------- | ------------------ | -------------------- |
+| 8000 | GraphQL HTTP server<br />(for Subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                    |
+| 8001 | GraphQL WS<br />(for Subgraph subscriptions)    | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                    |
+| 8020 | JSON-RPC<br />(for managing deployments)        | /                                              | \--admin-port      | -                    |
+| 8030 | Subgraph indexing status API                    | /graphql                                       | \--index-node-port | -                    |
+| 8040 | Prometheus metrics                              | /metrics                                       | \--metrics-port    | -                    |
 
 > **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
 
@@ -330,7 +330,7 @@ Database tables that store entities seem to generally come in two varieties: 'tr
 
 For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table.
 
-The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
+The command `graphman stats show <sgdNNNN>` shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
 
 In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
 
@@ -340,6 +340,4 @@ For Uniswap-like Subgraphs, the `pair` and `token` tables are prime candidates f
 
 #### Removing Subgraphs
 
-> This is new functionality, which will be available in Graph Node 0.29.x
-
 At some point an indexer might want to remove a given Subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a Subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).