graphprotocol · benface · May 16, 2025 · May 16, 2025 · May 16, 2025 · May 16, 2025
@@ -1,67 +1,46 @@
 ---
-title: حول The Graph
+title: About The Graph
+description: This page summarizes the core concepts and basics of The Graph Network.
 ---
 
 ## What is The Graph?
 
-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.
+The Graph is a decentralized protocol for indexing and querying blockchain data across [90+ networks](/supported-networks/).
 
-## Understanding the Basics
+Its data services include:
 
-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.
+- [Subgraphs](/subgraphs/developing/subgraphs/): Open APIs to query blockchain data that can be created or queried by anyone.
+- [Substreams](/substreams/introduction/): High-performance data streams for real-time blockchain processing, built with modular components.
+- [Token API Beta](/token-api/quick-start/): Instant access to standardized token data requiring zero setup.
 
-### Challenges Without The Graph
+### Why Blockchain Data is Difficult 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 data from blockchains requires processing smart contract events, parsing metadata from IPFS, and manually aggregating data.
 
-- 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**.
+The result is slow performance, complex infrastructure, and scalability issues.
 
-- 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 uses a combination of cutting-edge research, core dev expertise, and independent Indexers to make blockchain data accessible for developers.
 
-### Why is this a problem?
+Find the perfect data service for you:
 
-It would take **hours or even days** for a decentralized application (dapp) running in a browser to get an answer to these simple questions.
+### 1. Custom Real-Time Data Streams
 
-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.
+**Use Case:** High-frequency trading, live analytics.
 
-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.
+- [Build Substreams](/substreams/introduction/)
+- [Browse Community Substreams](https://substreams.dev/)
 
-## The Graph Provides a Solution
+### 2. Instant Token Data
 
-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.
+**Use Case:** Wallet balances, liquidity pools, transfer events.
 
-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.
+- [Start with Token API](/token-api/quick-start/)
 
-### How The Graph Functions
+### 3. Flexible Historical Queries
 
-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.
+**Use Case:** Dapp frontends, custom analytics.
 
-#### 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.
-
-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 Subgraphs](https://thegraph.com/explorer)
+- [Build Your Subgraph](/subgraphs/quick-start)
@@ -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).