From f9c6e3b6fb86fc27c911964c68fb962a399525d4 Mon Sep 17 00:00:00 2001 From: Brandon Kramer Date: Fri, 10 Jul 2026 16:46:33 -0400 Subject: [PATCH 1/7] docs: restructure Subgraphs, Substreams, Indexing & Resources --- nginx.conf | 105 ++-- website/next.config.js | 16 +- website/route-lockfile.txt | 65 +-- website/src/HomePage.tsx | 10 +- website/src/pages/en/about.mdx | 6 +- website/src/pages/en/ai-overview.mdx | 10 +- .../src/pages/en/archived/_meta-titles.json | 3 - .../src/pages/en/archived/arbitrum/_meta.js | 5 - .../en/archived/arbitrum/arbitrum-faq.mdx | 80 --- .../arbitrum/l2-transfer-tools-faq.mdx | 418 -------------- .../arbitrum/l2-transfer-tools-guide.mdx | 167 ------ website/src/pages/en/archived/sunrise.mdx | 80 --- website/src/pages/en/contracts.mdx | 2 +- .../src/pages/en/graph-horizon/overview.mdx | 2 +- website/src/pages/en/indexing/_meta.js | 12 +- .../en/indexing/{tooling => }/firehose.mdx | 0 .../en/indexing/{tooling => }/graph-node.mdx | 0 .../en/indexing/{tooling => }/graphcast.mdx | 0 .../src/pages/en/indexing/tooling/_meta.js | 5 - .../src/pages/en/resources/_meta-titles.json | 3 +- website/src/pages/en/resources/_meta.js | 2 - website/src/pages/en/resources/benefits.mdx | 2 +- .../en/resources/migration-guides/_meta.js | 4 - .../assemblyscript-migration-guide.mdx | 524 ----------------- .../graphql-validations-migration-guide.mdx | 538 ------------------ .../migration-guides/migrate-from-alchemy.mdx | 161 ------ .../src/pages/en/resources/roles/curating.mdx | 4 +- website/src/pages/en/resources/tokenomics.mdx | 6 +- .../src/pages/en/subgraphs/_meta-titles.json | 6 +- website/src/pages/en/subgraphs/_meta.js | 14 +- .../en/subgraphs/best-practices/_meta.js | 4 +- .../en/subgraphs/developing/_meta-titles.json | 3 +- .../pages/en/subgraphs/developing/_meta.js | 6 +- .../en/subgraphs/developing/creating/_meta.js | 11 +- .../developing/creating/graph-ts/api.mdx | 4 +- .../developing/creating/install-the-cli.mdx | 2 +- .../creating/starting-your-subgraph.mdx | 4 +- .../_meta.js | 1 + .../multiple-networks.mdx | 2 +- .../publishing-a-subgraph.mdx | 6 +- .../using-subgraph-studio.mdx | 3 +- .../en/subgraphs/developing/introduction.mdx | 2 +- .../subgraphs/developing/publishing/_meta.js | 3 - .../en/subgraphs/existing-subgraphs/_meta.js | 6 + .../{guides => existing-subgraphs}/agent0.mdx | 0 .../{ => existing-subgraphs}/explorer.mdx | 6 +- .../polymarket.mdx | 0 .../existing-subgraphs/standard-subgraphs.mdx | 68 +++ .../src/pages/en/subgraphs/guides/_meta.js | 20 +- .../guides/secure-api-keys-nextjs.mdx | 2 +- .../subgraphs.mdx => overview.mdx} | 11 +- .../en/subgraphs/providers/_meta-titles.json | 3 + .../providers}/_meta.js | 3 +- .../providers/subgraph-studio/_meta.js | 7 + .../subgraph-studio}/fair-use-policy.mdx | 4 +- .../subgraph-studio/introduction.mdx} | 3 +- .../subgraph-studio}/managing-api-keys.mdx | 4 +- .../providers/subgraph-studio/studio-faq.mdx} | 1 + .../subgraph-studio}/upgrade-indexer.mdx | 2 +- .../src/pages/en/subgraphs/querying/_meta.js | 10 +- .../en/subgraphs/querying/best-practices.mdx | 6 +- .../querying/distributed-systems.mdx | 134 ----- .../querying/from-an-application.mdx | 2 +- .../en/subgraphs/querying/introduction.mdx | 6 +- .../en/subgraphs/tooling/_meta-titles.json | 3 + .../src/pages/en/subgraphs/tooling/_meta.js | 11 + .../{guides => tooling}/contract-analyzer.mdx | 0 .../en/subgraphs/{ => tooling}/skills.mdx | 2 +- .../{guides => tooling}/subgraph-linter.mdx | 0 .../{ => tooling}/subgraph-mcp/_meta.js | 0 .../{ => tooling}/subgraph-mcp/claude.mdx | 0 .../{ => tooling}/subgraph-mcp/cline.mdx | 0 .../{ => tooling}/subgraph-mcp/cursor.mdx | 0 .../subgraph-mcp/introduction.mdx | 2 +- .../subgraph-uncrashable.mdx | 0 .../unit-testing-framework.mdx | 0 .../{guides => tooling}/x402-payments.mdx | 0 .../src/pages/en/substreams/_meta-titles.json | 4 +- website/src/pages/en/substreams/_meta.js | 7 +- .../{introduction.mdx => overview.mdx} | 2 +- .../pages/en/substreams/providers/_meta.js | 3 + .../substreams/providers/the-graph-market.mdx | 103 ++++ .../en/substreams/public-substreams/_meta.js | 3 + .../public-substreams/substreams-dev.mdx | 146 +++++ .../en/substreams/tooling/_meta-titles.json | 3 + .../src/pages/en/substreams/tooling/_meta.js | 6 + .../en/substreams/{ => tooling}/skills.mdx | 0 .../{ => tooling}/substreams-mcp/_meta.js | 0 .../{ => tooling}/substreams-mcp/search.mdx | 0 .../src/supportedNetworks/NetworksTable.tsx | 15 +- .../src/supportedNetworks/ResourceCards.tsx | 8 +- 91 files changed, 579 insertions(+), 2338 deletions(-) delete mode 100644 website/src/pages/en/archived/_meta-titles.json delete mode 100644 website/src/pages/en/archived/arbitrum/_meta.js delete mode 100644 website/src/pages/en/archived/arbitrum/arbitrum-faq.mdx delete mode 100644 website/src/pages/en/archived/arbitrum/l2-transfer-tools-faq.mdx delete mode 100644 website/src/pages/en/archived/arbitrum/l2-transfer-tools-guide.mdx delete mode 100644 website/src/pages/en/archived/sunrise.mdx rename website/src/pages/en/indexing/{tooling => }/firehose.mdx (100%) rename website/src/pages/en/indexing/{tooling => }/graph-node.mdx (100%) rename website/src/pages/en/indexing/{tooling => }/graphcast.mdx (100%) delete mode 100644 website/src/pages/en/indexing/tooling/_meta.js delete mode 100644 website/src/pages/en/resources/migration-guides/_meta.js delete mode 100644 website/src/pages/en/resources/migration-guides/assemblyscript-migration-guide.mdx delete mode 100644 website/src/pages/en/resources/migration-guides/graphql-validations-migration-guide.mdx delete mode 100644 website/src/pages/en/resources/migration-guides/migrate-from-alchemy.mdx rename website/src/pages/en/subgraphs/developing/{deploying => deploying-publishing}/_meta.js (61%) rename website/src/pages/en/subgraphs/developing/{deploying => deploying-publishing}/multiple-networks.mdx (99%) rename website/src/pages/en/subgraphs/developing/{publishing => deploying-publishing}/publishing-a-subgraph.mdx (89%) rename website/src/pages/en/subgraphs/developing/{deploying => deploying-publishing}/using-subgraph-studio.mdx (98%) delete mode 100644 website/src/pages/en/subgraphs/developing/publishing/_meta.js create mode 100644 website/src/pages/en/subgraphs/existing-subgraphs/_meta.js rename website/src/pages/en/subgraphs/{guides => existing-subgraphs}/agent0.mdx (100%) rename website/src/pages/en/subgraphs/{ => existing-subgraphs}/explorer.mdx (98%) rename website/src/pages/en/subgraphs/{guides => existing-subgraphs}/polymarket.mdx (100%) create mode 100644 website/src/pages/en/subgraphs/existing-subgraphs/standard-subgraphs.mdx rename website/src/pages/en/subgraphs/{developing/subgraphs.mdx => overview.mdx} (90%) create mode 100644 website/src/pages/en/subgraphs/providers/_meta-titles.json rename website/src/pages/en/{archived => subgraphs/providers}/_meta.js (53%) create mode 100644 website/src/pages/en/subgraphs/providers/subgraph-studio/_meta.js rename website/src/pages/en/subgraphs/{ => providers/subgraph-studio}/fair-use-policy.mdx (87%) rename website/src/pages/en/subgraphs/{billing.mdx => providers/subgraph-studio/introduction.mdx} (99%) rename website/src/pages/en/subgraphs/{querying => providers/subgraph-studio}/managing-api-keys.mdx (97%) rename website/src/pages/en/{resources/subgraph-studio-faq.mdx => subgraphs/providers/subgraph-studio/studio-faq.mdx} (98%) rename website/src/pages/en/subgraphs/{ => providers/subgraph-studio}/upgrade-indexer.mdx (88%) delete mode 100644 website/src/pages/en/subgraphs/querying/distributed-systems.mdx create mode 100644 website/src/pages/en/subgraphs/tooling/_meta-titles.json create mode 100644 website/src/pages/en/subgraphs/tooling/_meta.js rename website/src/pages/en/subgraphs/{guides => tooling}/contract-analyzer.mdx (100%) rename website/src/pages/en/subgraphs/{ => tooling}/skills.mdx (97%) rename website/src/pages/en/subgraphs/{guides => tooling}/subgraph-linter.mdx (100%) rename website/src/pages/en/subgraphs/{ => tooling}/subgraph-mcp/_meta.js (100%) rename website/src/pages/en/subgraphs/{ => tooling}/subgraph-mcp/claude.mdx (100%) rename website/src/pages/en/subgraphs/{ => tooling}/subgraph-mcp/cline.mdx (100%) rename website/src/pages/en/subgraphs/{ => tooling}/subgraph-mcp/cursor.mdx (100%) rename website/src/pages/en/subgraphs/{ => tooling}/subgraph-mcp/introduction.mdx (84%) rename website/src/pages/en/subgraphs/{guides => tooling}/subgraph-uncrashable.mdx (100%) rename website/src/pages/en/subgraphs/{developing/creating => tooling}/unit-testing-framework.mdx (100%) rename website/src/pages/en/subgraphs/{guides => tooling}/x402-payments.mdx (100%) rename website/src/pages/en/substreams/{introduction.mdx => overview.mdx} (98%) create mode 100644 website/src/pages/en/substreams/providers/_meta.js create mode 100644 website/src/pages/en/substreams/providers/the-graph-market.mdx create mode 100644 website/src/pages/en/substreams/public-substreams/_meta.js create mode 100644 website/src/pages/en/substreams/public-substreams/substreams-dev.mdx create mode 100644 website/src/pages/en/substreams/tooling/_meta-titles.json create mode 100644 website/src/pages/en/substreams/tooling/_meta.js rename website/src/pages/en/substreams/{ => tooling}/skills.mdx (100%) rename website/src/pages/en/substreams/{ => tooling}/substreams-mcp/_meta.js (100%) rename website/src/pages/en/substreams/{ => tooling}/substreams-mcp/search.mdx (100%) diff --git a/nginx.conf b/nginx.conf index 0d8fb0a275a1..657d1b0e3ac4 100644 --- a/nginx.conf +++ b/nginx.conf @@ -56,10 +56,7 @@ http { # Permanent redirects (301) rewrite ^/docs/en/about/introduction/$ $scheme://$http_host/docs/en/about/ permanent; - rewrite ^/docs/en/arbitrum-faq/$ $scheme://$http_host/docs/en/archived/arbitrum/arbitrum-faq/ permanent; - rewrite ^/docs/en/arbitrum/l2-transfer-tools-faq/$ $scheme://$http_host/docs/en/archived/arbitrum/l2-transfer-tools-faq/ permanent; - rewrite ^/docs/en/arbitrum/l2-transfer-tools-guide/$ $scheme://$http_host/docs/en/archived/arbitrum/l2-transfer-tools-guide/ permanent; - rewrite ^/docs/en/billing/$ $scheme://$http_host/docs/en/subgraphs/billing/ permanent; + rewrite ^/docs/en/billing/$ $scheme://$http_host/docs/en/subgraphs/providers/subgraph-studio/introduction/ permanent; rewrite ^/docs/en/chain-integration-overview/$ $scheme://$http_host/docs/en/indexing/chain-integration-overview/ permanent; rewrite ^/docs/en/cookbook/arweave/$ $scheme://$http_host/docs/en/subgraphs/cookbook/arweave/ permanent; rewrite ^/docs/en/cookbook/avoid-eth-calls/$ $scheme://$http_host/docs/en/subgraphs/best-practices/avoid-eth-calls/ permanent; @@ -86,12 +83,12 @@ http { rewrite ^/docs/en/subgraphs/cookbook/(.*)$ $scheme://$http_host/docs/en/subgraphs/guides/$1 permanent; rewrite ^/docs/en/curating/$ $scheme://$http_host/docs/en/resources/roles/curating/ permanent; rewrite ^/docs/en/delegating/$ $scheme://$http_host/docs/en/resources/roles/delegating/delegating/ permanent; - rewrite ^/docs/en/deploying/deploy-using-subgraph-studio/$ $scheme://$http_host/docs/en/subgraphs/developing/deploying/using-subgraph-studio/ permanent; - rewrite ^/docs/en/deploying/deploying-a-subgraph-to-studio/$ $scheme://$http_host/docs/en/subgraphs/developing/deploying/using-subgraph-studio/ permanent; - rewrite ^/docs/en/deploying/multiple-networks/$ $scheme://$http_host/docs/en/subgraphs/developing/deploying/multiple-networks/ permanent; - rewrite ^/docs/en/deploying/subgraph-studio-faqs/$ $scheme://$http_host/docs/en/resources/subgraph-studio-faq/ permanent; - rewrite ^/docs/en/subgraphs/developing/deploying/subgraph-studio-faq/$ $scheme://$http_host/docs/en/resources/subgraph-studio-faq/ permanent; - rewrite ^/docs/en/deploying/subgraph-studio/$ $scheme://$http_host/docs/en/subgraphs/developing/deploying/using-subgraph-studio/ permanent; + rewrite ^/docs/en/deploying/deploy-using-subgraph-studio/$ $scheme://$http_host/docs/en/subgraphs/developing/deploying-publishing/using-subgraph-studio/ permanent; + rewrite ^/docs/en/deploying/deploying-a-subgraph-to-studio/$ $scheme://$http_host/docs/en/subgraphs/developing/deploying-publishing/using-subgraph-studio/ permanent; + rewrite ^/docs/en/deploying/multiple-networks/$ $scheme://$http_host/docs/en/subgraphs/developing/deploying-publishing/multiple-networks/ permanent; + rewrite ^/docs/en/deploying/subgraph-studio-faqs/$ $scheme://$http_host/docs/en/subgraphs/providers/subgraph-studio/studio-faq/ permanent; + rewrite ^/docs/en/subgraphs/developing/deploying-publishing/subgraph-studio-faq/$ $scheme://$http_host/docs/en/subgraphs/providers/subgraph-studio/studio-faq/ permanent; + rewrite ^/docs/en/deploying/subgraph-studio/$ $scheme://$http_host/docs/en/subgraphs/developing/deploying-publishing/using-subgraph-studio/ permanent; rewrite ^/docs/en/developer/quick-start/$ $scheme://$http_host/docs/en/subgraphs/quick-start/ permanent; rewrite ^/docs/en/developing/assemblyscript-api/$ $scheme://$http_host/docs/en/subgraphs/developing/creating/graph-ts/api/ permanent; rewrite ^/docs/en/developing/creating-a-subgraph/$ $scheme://$http_host/docs/en/subgraphs/developing/creating/starting-your-subgraph/ permanent; @@ -108,56 +105,49 @@ http { rewrite ^/docs/en/developing/graph-ts/README/$ $scheme://$http_host/docs/en/subgraphs/developing/creating/graph-ts/README/ permanent; rewrite ^/docs/en/developing/substreams-powered-subgraphs-faq/$ $scheme://$http_host/docs/en/substreams/sps/faq/ permanent; rewrite ^/docs/en/developing/supported-networks/$ $scheme://$http_host/docs/en/supported-networks/ permanent; - rewrite ^/docs/en/developing/unit-testing-framework/$ $scheme://$http_host/docs/en/subgraphs/developing/creating/unit-testing-framework/ permanent; - rewrite ^/docs/en/explorer/$ $scheme://$http_host/docs/en/subgraphs/explorer/ permanent; - rewrite ^/docs/en/firehose/$ $scheme://$http_host/docs/en/indexing/tooling/firehose/ permanent; + rewrite ^/docs/en/developing/unit-testing-framework/$ $scheme://$http_host/docs/en/subgraphs/tooling/unit-testing-framework/ permanent; + rewrite ^/docs/en/explorer/$ $scheme://$http_host/docs/en/subgraphs/existing-subgraphs/explorer/ permanent; + rewrite ^/docs/en/firehose/$ $scheme://$http_host/docs/en/indexing/firehose/ permanent; rewrite ^/docs/en/glossary/$ $scheme://$http_host/docs/en/resources/glossary/ permanent; - rewrite ^/docs/en/graphcast/$ $scheme://$http_host/docs/en/indexing/tooling/graphcast/ permanent; + rewrite ^/docs/en/graphcast/$ $scheme://$http_host/docs/en/indexing/graphcast/ permanent; rewrite ^/docs/en/indexing/$ $scheme://$http_host/docs/en/indexing/overview/ permanent; rewrite ^/docs/en/managing/delete-a-subgraph/$ $scheme://$http_host/docs/en/subgraphs/developing/managing/deleting-a-subgraph/ permanent; rewrite ^/docs/en/managing/deprecate-a-subgraph/$ $scheme://$http_host/docs/en/subgraphs/developing/managing/deleting-a-subgraph/ permanent; rewrite ^/docs/en/managing/transfer-a-subgraph/$ $scheme://$http_host/docs/en/subgraphs/developing/managing/transferring-a-subgraph/ permanent; - rewrite ^/docs/en/network-transition-faq/$ $scheme://$http_host/docs/en/archived/arbitrum/arbitrum-faq/ permanent; rewrite ^/docs/en/network/benefits/$ $scheme://$http_host/docs/en/resources/benefits/ permanent; rewrite ^/docs/en/network/contracts/$ $scheme://$http_host/docs/en/contracts/ permanent; rewrite ^/docs/en/network/curating/$ $scheme://$http_host/docs/en/resources/roles/curating/ permanent; rewrite ^/docs/en/network/delegating/$ $scheme://$http_host/docs/en/resources/roles/delegating/delegating/ permanent; rewrite ^/docs/en/network/developing/$ $scheme://$http_host/docs/en/subgraphs/developing/introduction/ permanent; - rewrite ^/docs/en/network/explorer/$ $scheme://$http_host/docs/en/subgraphs/explorer/ permanent; + rewrite ^/docs/en/network/explorer/$ $scheme://$http_host/docs/en/subgraphs/existing-subgraphs/explorer/ permanent; rewrite ^/docs/en/network/indexing/$ $scheme://$http_host/docs/en/indexing/overview/ permanent; rewrite ^/docs/en/new-chain-integration/$ $scheme://$http_host/docs/en/indexing/new-chain-integration/ permanent; - rewrite ^/docs/en/operating-graph-node/$ $scheme://$http_host/docs/en/indexing/tooling/graph-node/ permanent; - rewrite ^/docs/en/publishing/publishing-a-subgraph/$ $scheme://$http_host/docs/en/subgraphs/developing/publishing/publishing-a-subgraph/ permanent; - rewrite ^/docs/en/querying/distributed-systems/$ $scheme://$http_host/docs/en/subgraphs/querying/distributed-systems/ permanent; + rewrite ^/docs/en/operating-graph-node/$ $scheme://$http_host/docs/en/indexing/graph-node/ permanent; + rewrite ^/docs/en/publishing/publishing-a-subgraph/$ $scheme://$http_host/docs/en/subgraphs/developing/deploying-publishing/publishing-a-subgraph/ permanent; rewrite ^/docs/en/querying/graph-client/README/$ $scheme://$http_host/docs/en/subgraphs/querying/graph-client/README/ permanent; rewrite ^/docs/en/querying/graph-client/architecture/$ $scheme://$http_host/docs/en/subgraphs/querying/graph-client/architecture/ permanent; rewrite ^/docs/en/querying/graph-client/live/$ $scheme://$http_host/docs/en/subgraphs/querying/graph-client/live/ permanent; rewrite ^/docs/en/querying/graphql-api/$ $scheme://$http_host/docs/en/subgraphs/querying/graphql-api/ permanent; - rewrite ^/docs/en/querying/managing-api-keys/$ $scheme://$http_host/docs/en/subgraphs/querying/managing-api-keys/ permanent; + rewrite ^/docs/en/querying/managing-api-keys/$ $scheme://$http_host/docs/en/subgraphs/providers/subgraph-studio/managing-api-keys/ permanent; rewrite ^/docs/en/querying/querying-best-practices/$ $scheme://$http_host/docs/en/subgraphs/querying/best-practices/ permanent; rewrite ^/docs/en/querying/querying-by-subgraph-id-vs-deployment-id/$ $scheme://$http_host/docs/en/subgraphs/querying/subgraph-id-vs-deployment-id/ permanent; rewrite ^/docs/en/querying/querying-from-an-application/$ $scheme://$http_host/docs/en/subgraphs/querying/from-an-application/ permanent; rewrite ^/docs/en/querying/querying-the-graph/$ $scheme://$http_host/docs/en/subgraphs/querying/introduction/ permanent; rewrite ^/docs/en/querying/querying-with-python/$ $scheme://$http_host/docs/en/subgraphs/querying/python/ permanent; rewrite ^/docs/en/quick-start/$ $scheme://$http_host/docs/en/subgraphs/quick-start/ permanent; - rewrite ^/docs/en/release-notes/assemblyscript-migration-guide/$ $scheme://$http_host/docs/en/resources/migration-guides/assemblyscript-migration-guide/ permanent; - rewrite ^/docs/en/resources/release-notes/assemblyscript-migration-guide/$ $scheme://$http_host/docs/en/resources/migration-guides/assemblyscript-migration-guide/ permanent; - rewrite ^/docs/en/release-notes/graphql-validations-migration-guide/$ $scheme://$http_host/docs/en/resources/migration-guides/graphql-validations-migration-guide/ permanent; - rewrite ^/docs/en/resources/release-notes/graphql-validations-migration-guide/$ $scheme://$http_host/docs/en/resources/migration-guides/graphql-validations-migration-guide/ permanent; rewrite ^/docs/en/sps/sps-faq/$ $scheme://$http_host/docs/en/substreams/sps/faq/ permanent; rewrite ^/docs/en/sps/(.*)$ $scheme://$http_host/docs/en/substreams/sps/$1 permanent; - rewrite ^/docs/en/studio/billing/$ $scheme://$http_host/docs/en/subgraphs/billing/ permanent; - rewrite ^/docs/en/studio/deploy-subgraph-studio/$ $scheme://$http_host/docs/en/subgraphs/developing/deploying/using-subgraph-studio/ permanent; - rewrite ^/docs/en/studio/managing-api-keys/$ $scheme://$http_host/docs/en/subgraphs/querying/managing-api-keys/ permanent; + rewrite ^/docs/en/studio/billing/$ $scheme://$http_host/docs/en/subgraphs/providers/subgraph-studio/introduction/ permanent; + rewrite ^/docs/en/studio/deploy-subgraph-studio/$ $scheme://$http_host/docs/en/subgraphs/developing/deploying-publishing/using-subgraph-studio/ permanent; + rewrite ^/docs/en/studio/managing-api-keys/$ $scheme://$http_host/docs/en/subgraphs/providers/subgraph-studio/managing-api-keys/ permanent; rewrite ^/docs/en/studio/multisig/$ $scheme://$http_host/docs/en/subgraphs/cookbook/multisig/ permanent; - rewrite ^/docs/en/studio/studio-faq/$ $scheme://$http_host/docs/en/resources/subgraph-studio-faq/ permanent; - rewrite ^/docs/en/studio/subgraph-studio/$ $scheme://$http_host/docs/en/subgraphs/developing/deploying/using-subgraph-studio/ permanent; + rewrite ^/docs/en/studio/studio-faq/$ $scheme://$http_host/docs/en/subgraphs/providers/subgraph-studio/studio-faq/ permanent; + rewrite ^/docs/en/studio/subgraph-studio/$ $scheme://$http_host/docs/en/subgraphs/developing/deploying-publishing/using-subgraph-studio/ permanent; rewrite ^/docs/en/studio/transferring-subgraph-ownership/$ $scheme://$http_host/docs/en/subgraphs/developing/managing/transferring-a-subgraph/ permanent; - rewrite ^/docs/en/subgraphs/$ $scheme://$http_host/docs/en/subgraphs/quick-start/ permanent; + rewrite ^/docs/en/subgraphs/$ $scheme://$http_host/docs/en/subgraphs/overview/ permanent; rewrite ^/docs/en/substreams/$ $scheme://$http_host/docs/en/substreams/quick-start/ permanent; rewrite ^/docs/en/substreams/developing/sinks/sinks/$ $scheme://$http_host/docs/en/substreams/developing/sinks/ permanent; rewrite ^/docs/en/substreams/sps/$ $scheme://$http_host/docs/en/substreams/sps/introduction/ permanent; - rewrite ^/docs/en/sunrise/$ $scheme://$http_host/docs/en/archived/sunrise/ permanent; rewrite ^/docs/en/supported-network-requirements/$ $scheme://$http_host/docs/en/indexing/supported-network-requirements/ permanent; rewrite ^/docs/en/supported-networks/arweave/$ $scheme://$http_host/docs/en/subgraphs/cookbook/arweave/ permanent; rewrite ^/docs/en/supported-networks/near/$ $scheme://$http_host/docs/en/subgraphs/cookbook/near/ permanent; @@ -165,12 +155,12 @@ http { rewrite ^/docs/en/tokenomics/$ $scheme://$http_host/docs/en/resources/tokenomics/ permanent; rewrite ^/docs/en/ai-suite/$ $scheme://$http_host/docs/en/ai-overview/ permanent; rewrite ^/docs/en/ai-suite/ai-introduction/$ $scheme://$http_host/docs/en/ai-overview/ permanent; - rewrite ^/docs/en/ai-suite/subgraph-skills/$ $scheme://$http_host/docs/en/subgraphs/skills/ permanent; - rewrite ^/docs/en/ai-suite/subgraph-mcp/$ $scheme://$http_host/docs/en/subgraphs/subgraph-mcp/introduction/ permanent; - rewrite ^/docs/en/subgraphs/subgraph-mcp/$ $scheme://$http_host/docs/en/subgraphs/subgraph-mcp/introduction/ permanent; - rewrite ^/docs/en/ai-suite/substreams-skills/$ $scheme://$http_host/docs/en/substreams/skills/ permanent; - rewrite ^/docs/en/ai-suite/substreams-mcp/$ $scheme://$http_host/docs/en/substreams/substreams-mcp/search/ permanent; - rewrite ^/docs/en/substreams/substreams-mcp/$ $scheme://$http_host/docs/en/substreams/substreams-mcp/search/ permanent; + rewrite ^/docs/en/ai-suite/subgraph-skills/$ $scheme://$http_host/docs/en/subgraphs/tooling/skills/ permanent; + rewrite ^/docs/en/ai-suite/subgraph-mcp/$ $scheme://$http_host/docs/en/subgraphs/tooling/subgraph-mcp/introduction/ permanent; + rewrite ^/docs/en/subgraphs/tooling/subgraph-mcp/$ $scheme://$http_host/docs/en/subgraphs/tooling/subgraph-mcp/introduction/ permanent; + rewrite ^/docs/en/ai-suite/substreams-skills/$ $scheme://$http_host/docs/en/substreams/tooling/skills/ permanent; + rewrite ^/docs/en/ai-suite/substreams-mcp/$ $scheme://$http_host/docs/en/substreams/tooling/substreams-mcp/search/ permanent; + rewrite ^/docs/en/substreams/tooling/substreams-mcp/$ $scheme://$http_host/docs/en/substreams/tooling/substreams-mcp/search/ permanent; # Token API redirects rewrite ^/docs/en/token-api/quick-start/$ https://app.pinax.network/docs/api/ permanent; @@ -254,6 +244,47 @@ http { # Temporary redirects (302) rewrite ^/docs/en/querying/graph-client/$ $scheme://$http_host/docs/en/subgraphs/querying/graph-client/README/ redirect; rewrite ^/docs/en/developing/graph-ts/$ $scheme://$http_host/docs/en/subgraphs/developing/creating/graph-ts/README/ redirect; + # --- subgraphs section reorg (subgraph-reorg) --- + rewrite ^/docs/en/subgraphs/billing/$ $scheme://$http_host/docs/en/subgraphs/providers/subgraph-studio/introduction/ permanent; + rewrite ^/docs/en/subgraphs/upgrade-indexer/$ $scheme://$http_host/docs/en/subgraphs/providers/subgraph-studio/upgrade-indexer/ permanent; + rewrite ^/docs/en/subgraphs/fair-use-policy/$ $scheme://$http_host/docs/en/subgraphs/providers/subgraph-studio/fair-use-policy/ permanent; + rewrite ^/docs/en/subgraphs/skills/$ $scheme://$http_host/docs/en/subgraphs/tooling/skills/ permanent; + rewrite ^/docs/en/subgraphs/subgraph-mcp/(.*)$ $scheme://$http_host/docs/en/subgraphs/tooling/subgraph-mcp/$1 permanent; + rewrite ^/docs/en/subgraphs/developing/subgraphs/$ $scheme://$http_host/docs/en/subgraphs/overview/ permanent; + rewrite ^/docs/en/subgraphs/developing/deploying/(.*)$ $scheme://$http_host/docs/en/subgraphs/developing/deploying-publishing/$1 permanent; + rewrite ^/docs/en/subgraphs/developing/publishing/(.*)$ $scheme://$http_host/docs/en/subgraphs/developing/deploying-publishing/$1 permanent; + rewrite ^/docs/en/resources/subgraph-studio-faq/$ $scheme://$http_host/docs/en/subgraphs/providers/subgraph-studio/studio-faq/ permanent; + rewrite ^/docs/en/substreams/introduction/$ $scheme://$http_host/docs/en/substreams/overview/ permanent; + # --- round4 reorg --- + rewrite ^/docs/en/subgraphs/explorer/$ $scheme://$http_host/docs/en/subgraphs/existing-subgraphs/explorer/ permanent; + rewrite ^/docs/en/subgraphs/guides/agent0/$ $scheme://$http_host/docs/en/subgraphs/existing-subgraphs/agent0/ permanent; + rewrite ^/docs/en/subgraphs/guides/polymarket/$ $scheme://$http_host/docs/en/subgraphs/existing-subgraphs/polymarket/ permanent; + rewrite ^/docs/en/subgraphs/guides/x402-payments/$ $scheme://$http_host/docs/en/subgraphs/tooling/x402-payments/ permanent; + rewrite ^/docs/en/subgraphs/guides/subgraph-uncrashable/$ $scheme://$http_host/docs/en/subgraphs/tooling/subgraph-uncrashable/ permanent; + rewrite ^/docs/en/subgraphs/guides/subgraph-linter/$ $scheme://$http_host/docs/en/subgraphs/tooling/subgraph-linter/ permanent; + rewrite ^/docs/en/subgraphs/guides/contract-analyzer/$ $scheme://$http_host/docs/en/subgraphs/tooling/contract-analyzer/ permanent; + rewrite ^/docs/en/substreams/skills/$ $scheme://$http_host/docs/en/substreams/tooling/skills/ permanent; + rewrite ^/docs/en/substreams/substreams-mcp/(.*)$ $scheme://$http_host/docs/en/substreams/tooling/substreams-mcp/$1 permanent; + rewrite ^/docs/en/resources/migration-guides/migrate-from-alchemy/$ $scheme://$http_host/docs/en/subgraphs/guides/transfer-to-the-graph/ permanent; + # --- round5 reorg --- + rewrite ^/docs/en/subgraphs/querying/managing-api-keys/$ $scheme://$http_host/docs/en/subgraphs/providers/subgraph-studio/managing-api-keys/ permanent; + # --- round6 reorg --- + rewrite ^/docs/en/subgraphs/developing/creating/unit-testing-framework/$ $scheme://$http_host/docs/en/subgraphs/tooling/unit-testing-framework/ permanent; + rewrite ^/docs/en/indexing/tooling/firehose/$ $scheme://$http_host/docs/en/indexing/firehose/ permanent; + rewrite ^/docs/en/indexing/tooling/graph-node/$ $scheme://$http_host/docs/en/indexing/graph-node/ permanent; + rewrite ^/docs/en/indexing/tooling/graphcast/$ $scheme://$http_host/docs/en/indexing/graphcast/ permanent; + # --- round8 migration-guide redirects --- + rewrite ^/docs/en/resources/migration-guides/assemblyscript-migration-guide/$ $scheme://$http_host/docs/en/subgraphs/developing/creating/graph-ts/README/ permanent; + rewrite ^/docs/en/resources/migration-guides/graphql-validations-migration-guide/$ $scheme://$http_host/docs/en/subgraphs/querying/graphql-api/ permanent; + # --- round9 archived blog redirects --- + rewrite ^/docs/en/archived/sunrise/$ https://thegraph.com/blog/unveiling-updated-sunrise-decentralized-data/ permanent; + rewrite ^/docs/en/archived/arbitrum/(.*)$ https://thegraph.com/blog/the-graph-L2-scaling-with-arbitrum/ permanent; + # --- round10 legacy archived aliases --- + rewrite ^/docs/en/sunrise/$ https://thegraph.com/blog/unveiling-updated-sunrise-decentralized-data/ permanent; + rewrite ^/docs/en/network-transition-faq/$ https://thegraph.com/blog/the-graph-L2-scaling-with-arbitrum/ permanent; + rewrite ^/docs/en/arbitrum-faq/$ https://thegraph.com/blog/the-graph-L2-scaling-with-arbitrum/ permanent; + rewrite ^/docs/en/arbitrum/l2-transfer-tools-faq/$ https://thegraph.com/blog/the-graph-L2-scaling-with-arbitrum/ permanent; + rewrite ^/docs/en/arbitrum/l2-transfer-tools-guide/$ https://thegraph.com/blog/the-graph-L2-scaling-with-arbitrum/ permanent; location / { try_files $uri $uri.html $uri/index.html =404; diff --git a/website/next.config.js b/website/next.config.js index 5de19d5038d1..c1b8a7841dce 100644 --- a/website/next.config.js +++ b/website/next.config.js @@ -53,6 +53,10 @@ const withNextra = nextra({ '---1': { type: 'separator', }, + 'ai-overview': 'AI Tooling', + '---1b': { + type: 'separator', + }, subgraphs: { type: 'children', title: t('global.navigation.subgraphs'), @@ -67,20 +71,16 @@ const withNextra = nextra({ '---3': { type: 'separator', }, - 'ai-overview': '', - '---4': { - type: 'separator', - }, indexing: { type: 'children', - title: t('global.navigation.indexing'), + title: 'Indexer Tooling', }, '---5': { type: 'separator', }, 'graph-horizon': { type: 'children', - title: t('global.navigation.graph-horizon'), + title: 'Data Services', }, '---6': { type: 'separator', @@ -89,10 +89,6 @@ const withNextra = nextra({ type: 'children', title: t('global.navigation.resources'), }, - archived: { - type: 'children', - title: t('global.navigation.archived'), - }, } return [ diff --git a/website/route-lockfile.txt b/website/route-lockfile.txt index 3f1ea187eef4..8ea5708db956 100644 --- a/website/route-lockfile.txt +++ b/website/route-lockfile.txt @@ -3,31 +3,23 @@ /en/404/ /en/about/ /en/ai-overview/ -/en/archived/arbitrum/arbitrum-faq/ -/en/archived/arbitrum/l2-transfer-tools-faq/ -/en/archived/arbitrum/l2-transfer-tools-guide/ -/en/archived/sunrise/ /en/contracts/ /en/graph-horizon/migration-guide/ /en/graph-horizon/overview/ /en/graph-horizon/what-changes/ /en/indexing/chain-integration-overview/ +/en/indexing/firehose/ +/en/indexing/graph-node/ +/en/indexing/graphcast/ /en/indexing/new-chain-integration/ /en/indexing/overview/ /en/indexing/supported-network-requirements/ /en/indexing/tap/ -/en/indexing/tooling/firehose/ -/en/indexing/tooling/graph-node/ -/en/indexing/tooling/graphcast/ /en/resources/benefits/ /en/resources/glossary/ -/en/resources/migration-guides/assemblyscript-migration-guide/ -/en/resources/migration-guides/graphql-validations-migration-guide/ -/en/resources/migration-guides/migrate-from-alchemy/ /en/resources/roles/curating/ /en/resources/roles/delegating/delegating/ /en/resources/roles/delegating/undelegating/ -/en/resources/subgraph-studio-faq/ /en/resources/tokenomics/ /en/subgraphs/best-practices/avoid-eth-calls/ /en/subgraphs/best-practices/derivedfrom/ @@ -35,7 +27,6 @@ /en/subgraphs/best-practices/immutable-entities-bytes-as-ids/ /en/subgraphs/best-practices/pruning/ /en/subgraphs/best-practices/timeseries/ -/en/subgraphs/billing/ /en/subgraphs/developing/creating/advanced/ /en/subgraphs/developing/creating/assemblyscript-mappings/ /en/subgraphs/developing/creating/graph-node-dev/ @@ -47,57 +38,59 @@ /en/subgraphs/developing/creating/ql-schema/ /en/subgraphs/developing/creating/starting-your-subgraph/ /en/subgraphs/developing/creating/subgraph-manifest/ -/en/subgraphs/developing/creating/unit-testing-framework/ -/en/subgraphs/developing/deploying/multiple-networks/ -/en/subgraphs/developing/deploying/using-subgraph-studio/ +/en/subgraphs/developing/deploying-publishing/multiple-networks/ +/en/subgraphs/developing/deploying-publishing/publishing-a-subgraph/ +/en/subgraphs/developing/deploying-publishing/using-subgraph-studio/ /en/subgraphs/developing/developer-faq/ /en/subgraphs/developing/introduction/ /en/subgraphs/developing/managing/deleting-a-subgraph/ /en/subgraphs/developing/managing/transferring-a-subgraph/ -/en/subgraphs/developing/publishing/publishing-a-subgraph/ -/en/subgraphs/developing/subgraphs/ -/en/subgraphs/explorer/ -/en/subgraphs/fair-use-policy/ -/en/subgraphs/guides/agent0/ -/en/subgraphs/guides/contract-analyzer/ +/en/subgraphs/existing-subgraphs/agent0/ +/en/subgraphs/existing-subgraphs/explorer/ +/en/subgraphs/existing-subgraphs/polymarket/ +/en/subgraphs/existing-subgraphs/standard-subgraphs/ /en/subgraphs/guides/enums/ /en/subgraphs/guides/grafting/ /en/subgraphs/guides/near/ -/en/subgraphs/guides/polymarket/ /en/subgraphs/guides/secure-api-keys-nextjs/ /en/subgraphs/guides/subgraph-composition/ /en/subgraphs/guides/subgraph-debug-forking/ -/en/subgraphs/guides/subgraph-linter/ -/en/subgraphs/guides/subgraph-uncrashable/ /en/subgraphs/guides/transfer-to-the-graph/ -/en/subgraphs/guides/x402-payments/ +/en/subgraphs/overview/ +/en/subgraphs/providers/subgraph-studio/fair-use-policy/ +/en/subgraphs/providers/subgraph-studio/introduction/ +/en/subgraphs/providers/subgraph-studio/managing-api-keys/ +/en/subgraphs/providers/subgraph-studio/studio-faq/ +/en/subgraphs/providers/subgraph-studio/upgrade-indexer/ /en/subgraphs/querying/best-practices/ -/en/subgraphs/querying/distributed-systems/ /en/subgraphs/querying/from-an-application/ /en/subgraphs/querying/graph-client/README/ /en/subgraphs/querying/graph-client/architecture/ /en/subgraphs/querying/graph-client/live/ /en/subgraphs/querying/graphql-api/ /en/subgraphs/querying/introduction/ -/en/subgraphs/querying/managing-api-keys/ /en/subgraphs/querying/python/ /en/subgraphs/querying/subgraph-id-vs-deployment-id/ /en/subgraphs/quick-start/ -/en/subgraphs/skills/ -/en/subgraphs/subgraph-mcp/claude/ -/en/subgraphs/subgraph-mcp/cline/ -/en/subgraphs/subgraph-mcp/cursor/ -/en/subgraphs/subgraph-mcp/introduction/ -/en/subgraphs/upgrade-indexer/ +/en/subgraphs/tooling/contract-analyzer/ +/en/subgraphs/tooling/skills/ +/en/subgraphs/tooling/subgraph-linter/ +/en/subgraphs/tooling/subgraph-mcp/claude/ +/en/subgraphs/tooling/subgraph-mcp/cline/ +/en/subgraphs/tooling/subgraph-mcp/cursor/ +/en/subgraphs/tooling/subgraph-mcp/introduction/ +/en/subgraphs/tooling/subgraph-uncrashable/ +/en/subgraphs/tooling/unit-testing-framework/ +/en/subgraphs/tooling/x402-payments/ /en/substreams/developing/dev-container/ /en/substreams/developing/sinks/ /en/substreams/developing/solana/account-changes/ /en/substreams/developing/solana/transactions/ -/en/substreams/introduction/ +/en/substreams/overview/ /en/substreams/publishing/ /en/substreams/quick-start/ -/en/substreams/skills/ -/en/substreams/substreams-mcp/search/ +/en/substreams/tooling/skills/ +/en/substreams/tooling/substreams-mcp/search/ /en/supported-networks/ /en/supported-networks/arbitrum-nova/ /en/supported-networks/arbitrum-one/ diff --git a/website/src/HomePage.tsx b/website/src/HomePage.tsx index 3ded0b7d291b..d2b1e47fdcdf 100644 --- a/website/src/HomePage.tsx +++ b/website/src/HomePage.tsx @@ -128,7 +128,7 @@ export default function HomePage({ supportedNetworks }: { supportedNetworks: Sup title={t('index.products.graphNode.title')} description={t('index.products.graphNode.description')} cta={ - + {t('index.products.graphNode.cta')} } @@ -142,7 +142,7 @@ export default function HomePage({ supportedNetworks }: { supportedNetworks: Sup title={t('index.products.firehose.title')} description={t('index.products.firehose.description')} cta={ - + {t('index.products.firehose.cta')} } @@ -210,14 +210,14 @@ export default function HomePage({ supportedNetworks }: { supportedNetworks: Sup
} slotAboveTitle={} /> } @@ -245,7 +245,7 @@ export default function HomePage({ supportedNetworks }: { supportedNetworks: Sup slotAboveTitle={} /> } diff --git a/website/src/pages/en/about.mdx b/website/src/pages/en/about.mdx index 80c34b1d9b1e..eb34a8776c32 100644 --- a/website/src/pages/en/about.mdx +++ b/website/src/pages/en/about.mdx @@ -34,7 +34,7 @@ The result: raw, hard-to-access on-chain data becomes fast, structured, and read ## The Graph's Core Products -### 1. [Subgraphs](/subgraphs/developing/subgraphs/) +### 1. [Subgraphs](/subgraphs/overview/) **Overview:** Custom APIs that extract data from a blockchain, process it, and serve it via GraphQL. The original and most widely used data service on The Graph. @@ -43,14 +43,14 @@ The result: raw, hard-to-access on-chain data becomes fast, structured, and read - [Explore existing Subgraphs](https://thegraph.com/explorer) - [Build a Subgraph](/subgraphs/quick-start) -### 2. [Substreams](/substreams/introduction/) +### 2. [Substreams](/substreams/overview/) **Overview:** A parallel blockchain indexing technology for high-performance, real-time data streams. Built for use cases that need faster sync and larger throughput than traditional Subgraphs. **Use Case:** Best when you need low-latency data at scale: live liquidity and price feeds, trading and liquidation events, analytics pipelines, and large-scale backfills across chains. - [Browse existing Substreams](https://substreams.dev/) -- [Build with Substreams](/substreams/introduction/) +- [Build with Substreams](/substreams/overview/) ### 3. [Amp](https://ampup.sh/docs) diff --git a/website/src/pages/en/ai-overview.mdx b/website/src/pages/en/ai-overview.mdx index 4f49b719cd3c..2ffe7ac0aac2 100644 --- a/website/src/pages/en/ai-overview.mdx +++ b/website/src/pages/en/ai-overview.mdx @@ -5,7 +5,7 @@ description: Build with speed and scale faster with The Graph’s MCPs and skill ## Using AI on The Graph -Instead of relying on static datasets or centralized APIs, you can now use our AI-native tooling via the [Subgraph MCP](/subgraphs/subgraph-mcp/introduction/), [Substreams MCP](/substreams/substreams-mcp/search/), and agent skills for both Subgraphs and Substreams. +Instead of relying on static datasets or centralized APIs, you can now use our AI-native tooling via the [Subgraph MCP](/subgraphs/tooling/subgraph-mcp/introduction/), [Substreams MCP](/substreams/tooling/substreams-mcp/search/), and agent skills for both Subgraphs and Substreams. ### Why Use Onchain Data with AI? @@ -23,7 +23,7 @@ Agent Skills extend AI coding assistants like Claude Code and Cursor with deep, ### Subgraph MCP -The [Subgraph MCP](/subgraphs/subgraph-mcp/introduction/) server connects models to Subgraphs on The Graph Network. It allows language models to explore Subgraph schemas, execute GraphQL queries, find relevant Subgraphs by keyword or contract, and surface usage metrics using natural language. +The [Subgraph MCP](/subgraphs/tooling/subgraph-mcp/introduction/) server connects models to Subgraphs on The Graph Network. It allows language models to explore Subgraph schemas, execute GraphQL queries, find relevant Subgraphs by keyword or contract, and surface usage metrics using natural language. #### Benefits of Using Subgraph MCP @@ -34,7 +34,7 @@ The [Subgraph MCP](/subgraphs/subgraph-mcp/introduction/) server connects models ### Substreams MCP -The [Substreams MCP](/substreams/substreams-mcp/search/) server lets AI agents search, inspect, and analyze Substreams packages — from registry discovery to sink deployment. It supports dual transport for local clients and SSE/HTTP for remote agents. +The [Substreams MCP](/substreams/tooling/substreams-mcp/search/) server lets AI agents search, inspect, and analyze Substreams packages — from registry discovery to sink deployment. It supports dual transport for local clients and SSE/HTTP for remote agents. #### Tools @@ -53,7 +53,7 @@ The [Substreams MCP](/substreams/substreams-mcp/search/) server lets AI agents s ### Agent Skills for Subgraphs -[Subgraph Skills](/subgraphs/skills/) is a collection of AI agent skills that provide expert knowledge for developing, testing, and deploying Subgraphs. Skills are available as Claude Code plugins or OpenClaw skills. +[Subgraph Skills](/subgraphs/tooling/skills/) is a collection of AI agent skills that provide expert knowledge for developing, testing, and deploying Subgraphs. Skills are available as Claude Code plugins or OpenClaw skills. #### Available Skills @@ -65,7 +65,7 @@ The [Substreams MCP](/substreams/substreams-mcp/search/) server lets AI agents s ### Agent Skills for Substreams -[Substreams Skills](/substreams/skills/) enhance AI coding assistants with specialized Substreams expertise. Install once and your assistant automatically applies Substreams best practices when working on relevant projects. +[Substreams Skills](/substreams/tooling/skills/) enhance AI coding assistants with specialized Substreams expertise. Install once and your assistant automatically applies Substreams best practices when working on relevant projects. #### Available Skills diff --git a/website/src/pages/en/archived/_meta-titles.json b/website/src/pages/en/archived/_meta-titles.json deleted file mode 100644 index 9501304a4305..000000000000 --- a/website/src/pages/en/archived/_meta-titles.json +++ /dev/null @@ -1,3 +0,0 @@ -{ - "arbitrum": "Scaling with Arbitrum" -} diff --git a/website/src/pages/en/archived/arbitrum/_meta.js b/website/src/pages/en/archived/arbitrum/_meta.js deleted file mode 100644 index 6e0db9442939..000000000000 --- a/website/src/pages/en/archived/arbitrum/_meta.js +++ /dev/null @@ -1,5 +0,0 @@ -export default { - 'arbitrum-faq': '', - 'l2-transfer-tools-faq': '', - 'l2-transfer-tools-guide': '', -} diff --git a/website/src/pages/en/archived/arbitrum/arbitrum-faq.mdx b/website/src/pages/en/archived/arbitrum/arbitrum-faq.mdx deleted file mode 100644 index 1d4d957e102e..000000000000 --- a/website/src/pages/en/archived/arbitrum/arbitrum-faq.mdx +++ /dev/null @@ -1,80 +0,0 @@ ---- -title: Arbitrum FAQ ---- - -> [!IMPORTANT] L2 Transfer Tools have been deprecated, and The Graph now runs on Arbitrum, a Layer 2 blockchain. - -Click [here](#billing-on-arbitrum-faqs) if you would like to skip to the Arbitrum Billing FAQs. - -## Why did The Graph implement an L2 Solution? - -By scaling The Graph on L2, network participants can now benefit from: - -- Upwards of 26x savings on gas fees - -- Faster transaction speed - -- Security inherited from Ethereum Mainnet - -Scaling the protocol smart contracts onto L2 allows network participants to interact more frequently at a reduced cost in gas fees. For example, Indexers can open and close allocations more frequently to index a greater number of Subgraphs. Developers can deploy and update Subgraphs more easily, and Delegators can delegate GRT more frequently. Curators can add or remove signal to a larger number of Subgraphs–actions previously considered too cost-prohibitive to perform frequently due to gas. - -The Graph community decided to move forward with Arbitrum One last year after the outcome of the [GIP-0031](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) discussion. - -## What do I need to do to use The Graph on L2? - -The Graph’s billing system accepts GRT on Arbitrum One, and users will need ETH on Arbitrum One to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One. - -Consequently, to pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this: - -- If you already have GRT on Ethereum Mainnet, you can bridge it to Arbitrum One. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges: - - [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161) - - [TransferTo](https://transferto.xyz/swap) - -- If you have other assets on Arbitrum, you can swap them for GRT through a swapping protocol like Uniswap. -- Alternatively, you can acquire GRT directly on Arbitrum through a decentralized exchange. - -Once you have GRT on Arbitrum, you can add it to your billing balance. - -To take advantage of using The Graph on L2, use this dropdown switcher to toggle between chains. - -![Dropdown switcher to toggle Arbitrum](/img/arbitrum-screenshot-toggle.png) - -## As a Subgraph developer, data consumer, Indexer, Curator, or Delegator, what do I need to do now? - -Network participants must move to Arbitrum to continue participating in The Graph Network. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) for additional support. - -All indexing rewards are now entirely on Arbitrum. - -## Were there any risks associated with scaling the network to L2? - -All smart contracts have been thoroughly [audited](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/audits/OpenZeppelin/2022-07-graph-arbitrum-bridge-audit.pdf). - -Everything has been tested thoroughly, and a contingency plan is in place to ensure a safe and seamless transition. Details can be found [here](https://forum.thegraph.com/t/gip-0037-the-graph-arbitrum-deployment-with-linear-rewards-minted-in-l2/3551#risks-and-security-considerations-20). - -## Are existing Subgraphs on Ethereum Mainnet working? - -All Subgraphs are now on Arbitrum. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) to ensure your Subgraphs operate seamlessly. - -## Does GRT have a new smart contract deployed on Arbitrum? - -Yes, GRT has an additional [smart contract on Arbitrum](https://arbiscan.io/address/0x9623063377ad1b27544c965ccd7342f7ea7e88c7). However, the Ethereum Mainnet [GRT contract](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7) will remain operational. - -## Billing on Arbitrum FAQs - -## What do I need to do about the GRT in my billing balance? - -Nothing! Your GRT has been securely migrated to Arbitrum and is being used to pay for queries as you read this. - -## How do I know my funds have migrated securely to Arbitrum? - -All GRT billing balances have already been successfully migrated to Arbitrum. You can view the billing contract on Arbitrum [here](https://arbiscan.io/address/0x1B07D3344188908Fb6DEcEac381f3eE63C48477a). - -## How do I know the Arbitrum bridge is secure? - -The bridge has been [heavily audited](https://code4rena.com/contests/2022-10-the-graph-l2-bridge-contest) to ensure safety and security for all users. - -## What do I need to do if I'm adding fresh GRT from my Ethereum Mainnet wallet? - -Adding GRT to your Arbitrum billing balance can be done with a one-click experience in [Subgraph Studio](https://thegraph.com/studio/). You'll be able to easily bridge your GRT to Arbitrum and fill your API keys in one transaction. - -Visit the [Billing page](/subgraphs/billing/) for more detailed instructions on adding, withdrawing, or acquiring GRT. diff --git a/website/src/pages/en/archived/arbitrum/l2-transfer-tools-faq.mdx b/website/src/pages/en/archived/arbitrum/l2-transfer-tools-faq.mdx deleted file mode 100644 index 4a12ec8c7a3b..000000000000 --- a/website/src/pages/en/archived/arbitrum/l2-transfer-tools-faq.mdx +++ /dev/null @@ -1,418 +0,0 @@ ---- -title: L2 Transfer Tools FAQ ---- - -> [!IMPORTANT] L2 Transfer Tools have been deprecated, and The Graph now runs on Arbitrum, a Layer 2 blockchain. - -## General - -### What are L2 Transfer Tools? - -The Graph has made it 26x cheaper for contributors to participate in the network by deploying the protocol to Arbitrum One. The L2 Transfer Tools were created by core devs to make it easy to move to L2. - -For each network participant, a set of L2 Transfer Tools are available to make the experience seamless when moving to L2, avoiding thawing periods or having to manually withdraw and bridge GRT. - -These tools will require you to follow a specific set of steps depending on what your role is within The Graph and what you are transferring to L2. - -### Can I use the same wallet I use on Ethereum Mainnet? - -If you are using an [EOA](https://ethereum.org/en/developers/docs/accounts/#types-of-account) wallet you can use the same address. If your Ethereum Mainnet wallet is a contract (e.g. a multisig) then you must specify an [Arbitrum wallet address](/archived/arbitrum/arbitrum-faq/#what-do-i-need-to-do-to-use-the-graph-on-l2) where your transfer will be sent. Please check the address carefully as any transfers to an incorrect address can result in permanent loss. If you'd like to use a multisig on L2, make sure you deploy a multisig contract on Arbitrum One. - -Wallets on EVM blockchains like Ethereum Mainnet and Arbitrum One are a pair of keys (public and private), that you create without any need to interact with the blockchain. So any wallet that was created for Ethereum Mainnet will also work on Arbitrum One without having to do anything else. - -The exception is with smart contract wallets like multisigs: these are smart contracts that are deployed separately on each chain, and get their address when they are deployed. If a multisig was deployed to Ethereum Mainnet, it won't exist with the same address on Arbitrum One. A new multisig must be created first on Arbitrum One, and may get a different address. - -### What happens if I don’t finish my transfer in 7 days? - -The L2 Transfer Tools use Arbitrum’s native mechanism to send messages from L1 to L2. This mechanism is called a “retryable ticket” and is used by all native token bridges, including the Arbitrum GRT bridge. You can read more about retryable tickets in the [Arbitrum One docs](https://docs.arbitrum.io/arbos/l1-to-l2-messaging). - -When you transfer your assets (Subgraph, stake, delegation or curation) to L2, a message is sent through the Arbitrum GRT bridge which creates a retryable ticket in L2. The transfer tool includes some ETH value in the transaction, that is used to 1) pay to create the ticket and 2) pay for the gas to execute the ticket in L2. However, because gas prices might vary in the time until the ticket is ready to execute in L2, it is possible that this auto-execution attempt fails. When that happens, the Arbitrum bridge will keep the retryable ticket alive for up to 7 days, and anyone can retry “redeeming” the ticket (which requires a wallet with some ETH bridged to Arbitrum). - -This is what we call the “Confirm” step in all the transfer tools - it will run automatically in most cases, as the auto-execution is most often successful, but it is important that you check back to make sure it went through. If it doesn’t succeed and there are no successful retries in 7 days, the Arbitrum bridge will discard the ticket, and your assets (Subgraph, stake, delegation or curation) will be lost and can’t be recovered. The Graph core devs have a monitoring system in place to detect these situations and try to redeem the tickets before it’s too late, but it is ultimately your responsibility to ensure your transfer is completed in time. If you’re having trouble confirming your transaction, please reach out using [this form](https://noteforms.com/forms/notionform-l2-transfer-tooling-issues-0ogqfu?notionforms=1&utm_source=notionforms) and core devs will be there help you. - -### I started my delegation/stake/curation transfer and I'm not sure if it made it through to L2, how can I confirm that it was transferred correctly? - -If you don't see a banner on your profile asking you to finish the transfer, then it's likely the transaction made it safely to L2 and no more action is needed. If in doubt, you can check if Explorer shows your delegation, stake or curation on Arbitrum One. - -If you have the L1 transaction hash (which you can find by looking at the recent transactions in your wallet), you can also confirm if the "retryable ticket" that carried the message to L2 was redeemed here: https://retryable-dashboard.arbitrum.io/ - if the auto-redeem failed, you can also connect your wallet there and redeem it. Rest assured that core devs are also monitoring for messages that get stuck, and will attempt to redeem them before they expire. - -## Subgraph Transfer - -### How do I transfer my Subgraph? - - - -To transfer your Subgraph, you will need to complete the following steps: - -1. Initiate the transfer on Ethereum Mainnet - -2. Wait 20 minutes for confirmation - -3. Confirm Subgraph transfer on Arbitrum\* - -4. Finish publishing Subgraph on Arbitrum - -5. Update Query URL (recommended) - -\*Note that you must confirm the transfer within 7 days otherwise your Subgraph may be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol). - -### Where should I initiate my transfer from? - -You can initiate your transfer from the [Subgraph Studio](https://thegraph.com/studio/), [Explorer,](https://thegraph.com/explorer) or any Subgraph details page. Click the "Transfer Subgraph" button in the Subgraph details page to start the transfer. - -### How long do I need to wait until my Subgraph is transferred - -The transfer time takes approximately 20 minutes. The Arbitrum bridge is working in the background to complete the bridge transfer automatically. In some cases, gas costs may spike and you will need to confirm the transaction again. - -### Will my Subgraph still be discoverable after I transfer it to L2? - -Your Subgraph will only be discoverable on the network it is published to. For example, if your Subgraph is on Arbitrum One, then you can only find it in Explorer on Arbitrum One and will not be able to find it on Ethereum Mainnet. Please ensure that you have Arbitrum One selected in the network switcher at the top of the page to ensure you are on the correct network.  After the transfer, the L1 Subgraph will appear as deprecated. - -### Does my Subgraph need to be published to transfer it? - -To take advantage of the Subgraph transfer tool, your Subgraph must be already published to Ethereum Mainnet and must have some curation signal owned by the wallet that owns the Subgraph. If your Subgraph is not published, it is recommended you simply publish directly on Arbitrum One - the associated gas fees will be considerably lower. If you want to transfer a published Subgraph but the owner account hasn't curated any signal on it, you can signal a small amount (e.g. 1 GRT) from that account; make sure to choose "auto-migrating" signal. - -### What happens to the Ethereum Mainnet version of my Subgraph after I transfer to Arbitrum? - -After transferring your Subgraph to Arbitrum, the Ethereum Mainnet version will be deprecated. We recommend you update your query URL within 48 hours. However, there is a grace period in place that keeps your mainnet URL functioning so that any third-party dapp support can be updated. - -### After I transfer, do I also need to re-publish on Arbitrum? - -After the 20 minute transfer window, you will need to confirm the transfer with a transaction in the UI to finish the transfer, but the transfer tool will guide you through this. Your L1 endpoint will continue to be supported during the transfer window and a grace period after. It is encouraged that you update your endpoint when convenient for you. - -### Will my endpoint experience downtime while re-publishing? - -It is unlikely, but possible to experience a brief downtime depending on which Indexers are supporting the Subgraph on L1 and whether they keep indexing it until the Subgraph is fully supported on L2. - -### Is publishing and versioning the same on L2 as Ethereum Mainnet? - -Yes. Select Arbitrum One as your published network when publishing in Subgraph Studio. In the Studio, the latest endpoint will be available which points to the latest updated version of the Subgraph. - -### Will my Subgraph's curation move with my Subgraph? - -If you've chosen auto-migrating signal, 100% of your own curation will move with your Subgraph to Arbitrum One. All of the Subgraph's curation signal will be converted to GRT at the time of the transfer, and the GRT corresponding to your curation signal will be used to mint signal on the L2 Subgraph. - -Other Curators can choose whether to withdraw their fraction of GRT, or also transfer it to L2 to mint signal on the same Subgraph. - -### Can I move my Subgraph back to Ethereum Mainnet after I transfer? - -Once transferred, your Ethereum Mainnet version of this Subgraph will be deprecated. If you would like to move back to mainnet, you will need to redeploy and publish back to mainnet. However, transferring back to Ethereum Mainnet is strongly discouraged as indexing rewards will eventually be distributed entirely on Arbitrum One. - -### Why do I need bridged ETH to complete my transfer? - -Gas fees on Arbitrum One are paid using bridged ETH (i.e. ETH that has been bridged to Arbitrum One). However, the gas fees are significantly lower when compared to Ethereum Mainnet. - -## Delegation - -### How do I transfer my delegation? - - - -To transfer your delegation, you will need to complete the following steps: - -1. Initiate delegation transfer on Ethereum Mainnet -2. Wait 20 minutes for confirmation -3. Confirm delegation transfer on Arbitrum - -\*\*\*\*You must confirm the transaction to complete the delegation transfer on Arbitrum. This step must be completed within 7 days or the delegation could be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol). - -### What happens to my rewards if I initiate a transfer with an open allocation on Ethereum Mainnet? - -If the Indexer to whom you're delegating has started transferring stake to L2 but is still operating on L1, when you transfer to Arbitrum you will forfeit any delegation rewards from open allocations on Ethereum Mainnet. This means that you will lose the rewards from, at most, the last 28-day period. If you time the transfer right after the Indexer has closed allocations you can make sure this is the least amount possible. If you have a communication channel with your Indexer(s), consider discussing with them to find the best time to do your transfer. Other than this, your unrealized rewards will be transferred to L2 with the delegation. - -If the Indexer has transferred all their stake to L2, they will not have open allocations on L1 and therefore all your rewards will be transferred to L2 with the delegation transfer. - -### What happens if the Indexer I currently delegate to isn't on Arbitrum One? - -The L2 transfer tool will only be enabled if the Indexer you have delegated to has transferred their own stake to Arbitrum. - -### Do Delegators have the option to delegate to another Indexer? - -If you wish to delegate to another Indexer, you can transfer to the same Indexer on Arbitrum, then undelegate and wait for the thawing period. After this, you can select another active Indexer to delegate to. - -### What if I can't find the Indexer I'm delegating to on L2? - -The L2 transfer tool will automatically detect the Indexer you previously delegated to. - -### Will I be able to mix and match or 'spread' my delegation across new or several Indexers instead of the prior Indexer? - -The L2 transfer tool will always move your delegation to the same Indexer you delegated to previously. Once you have moved to L2, you can undelegate, wait for the thawing period, and decide if you'd like to split up your delegation. - -### Am I subject to the cooldown period or can I withdraw immediately after using the L2 delegation transfer tool? - -The transfer tool allows you to immediately move to L2. If you would like to undelegate you will have to wait for the thawing period. However, if an Indexer has transferred all of their stake to L2, you can withdraw on Ethereum Mainnet immediately. - -### Can my rewards be negatively impacted if I do not transfer my delegation? - -It is anticipated that all network participation will move to Arbitrum One in the future. - -### How long does it take to complete the transfer of my delegation to L2? - -A 20-minute confirmation is required for delegation transfer. Please note that after the 20-minute period, you must come back and complete step 3 of the transfer process within 7 days. If you fail to do this, then your delegation may be lost. Note that in most cases the transfer tool will complete this step for you automatically. In case of a failed auto-attempt, you will need to complete it manually. If any issues arise during this process, don't worry, we'll be here to help: contact us at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol). - -### Can I transfer my delegation if I'm using a GRT vesting contract/token lock wallet? - -Yes! The process is a bit different because vesting contracts can't forward the ETH needed to pay for the L2 gas, so you need to deposit it beforehand. If your vesting contract is not fully vested, you will also have to first initialize a counterpart vesting contract on L2 and will only be able to transfer the delegation to this L2 vesting contract. The UI on Explorer can guide you through this process when you've connected to Explorer using the vesting lock wallet. - -### Does my Arbitrum vesting contract allow releasing GRT just like on mainnet? - -No, the vesting contract that is created on Arbitrum will not allow releasing any GRT until the end of the vesting timeline, i.e. until your contract is fully vested. This is to prevent double spending, as otherwise it would be possible to release the same amounts on both layers. - -If you'd like to release GRT from the vesting contract, you can transfer them back to the L1 vesting contract using Explorer: in your Arbitrum One profile, you will see a banner saying you can transfer GRT back to the mainnet vesting contract. This requires a transaction on Arbitrum One, waiting 7 days, and a final transaction on mainnet, as it uses the same native bridging mechanism from the GRT bridge. - -### Is there any delegation tax? - -No. Received tokens on L2 are delegated to the specified Indexer on behalf of the specified Delegator without charging a delegation tax. - -### Will my unrealized rewards be transferred when I transfer my delegation? - -​Yes! The only rewards that can't be transferred are the ones for open allocations, as those won't exist until the Indexer closes the allocations (usually every 28 days). If you've been delegating for a while, this is likely only a small fraction of rewards. - -At the smart contract level, unrealized rewards are already part of your delegation balance, so they will be transferred when you transfer your delegation to L2. ​ - -### Is moving delegations to L2 mandatory? Is there a deadline? - -​Moving delegation to L2 is not mandatory, but indexing rewards are increasing on L2 following the timeline described in [GIP-0052](https://forum.thegraph.com/t/gip-0052-timeline-and-requirements-to-increase-rewards-in-l2/4193). Eventually, if the Council keeps approving the increases, all rewards will be distributed in L2 and there will be no indexing rewards for Indexers and Delegators on L1. ​ - -### If I am delegating to an Indexer that has already transferred stake to L2, do I stop receiving rewards on L1? - -​Many Indexers are transferring stake gradually so Indexers on L1 will still be earning rewards and fees on L1, which are then shared with Delegators. Once an Indexer has transferred all of their stake, then they will stop operating on L1, so Delegators will not receive any more rewards unless they transfer to L2. - -Eventually, if the Council keeps approving the indexing rewards increases in L2, all rewards will be distributed on L2 and there will be no indexing rewards for Indexers and Delegators on L1. ​ - -### I don't see a button to transfer my delegation. Why is that? - -​Your Indexer has probably not used the L2 transfer tools to transfer stake yet. - -If you can contact the Indexer, you can encourage them to use the L2 Transfer Tools so that Delegators can transfer delegations to their L2 Indexer address. ​ - -### My Indexer is also on Arbitrum, but I don't see a button to transfer the delegation in my profile. Why is that? - -​It is possible that the Indexer has set up operations on L2, but hasn't used the L2 transfer tools to transfer stake. The L1 smart contracts will therefore not know about the Indexer's L2 address. If you can contact the Indexer, you can encourage them to use the transfer tool so that Delegators can transfer delegations to their L2 Indexer address. ​ - -### Can I transfer my delegation to L2 if I have started the undelegating process and haven't withdrawn it yet? - -​No. If your delegation is thawing, you have to wait the 28 days and withdraw it. - -The tokens that are being undelegated are "locked" and therefore cannot be transferred to L2. - -## Curation Signal - -### How do I transfer my curation? - -To transfer your curation, you will need to complete the following steps: - -1. Initiate signal transfer on Ethereum Mainnet - -2. Specify an L2 Curator address\* - -3. Wait 20 minutes for confirmation - -\*If necessary - i.e. you are using a contract address. - -### How will I know if the Subgraph I curated has moved to L2? - -When viewing the Subgraph details page, a banner will notify you that this Subgraph has been transferred. You can follow the prompt to transfer your curation. You can also find this information on the Subgraph details page of any Subgraph that has moved. - -### What if I do not wish to move my curation to L2? - -When a Subgraph is deprecated you have the option to withdraw your signal. Similarly, if a Subgraph has moved to L2, you can choose to withdraw your signal in Ethereum Mainnet or send the signal to L2. - -### How do I know my curation successfully transferred? - -Signal details will be accessible via Explorer approximately 20 minutes after the L2 transfer tool is initiated. - -### Can I transfer my curation on more than one Subgraph at a time? - -There is no bulk transfer option at this time. - -## Indexer Stake - -### How do I transfer my stake to Arbitrum? - -> Disclaimer: If you are currently unstaking any portion of your GRT on your Indexer, you will not be able to use L2 Transfer Tools. - - - -To transfer your stake, you will need to complete the following steps: - -1. Initiate stake transfer on Ethereum Mainnet - -2. Wait 20 minutes for confirmation - -3. Confirm stake transfer on Arbitrum - -\*Note that you must confirm the transfer within 7 days otherwise your stake may be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol). - -### Will all of my stake transfer? - -You can choose how much of your stake to transfer. If you choose to transfer all of your stake at once, you will need to close any open allocations first. - -If you plan on transferring parts of your stake over multiple transactions, you must always specify the same beneficiary address. - -Note: You must meet the minimum stake requirements on L2 the first time you use the transfer tool. Indexers must send the minimum 100k GRT (when calling this function the first time). If leaving a portion of stake on L1, it must also be over the 100k GRT minimum and be sufficient (together with your delegations) to cover your open allocations. - -### How much time do I have to confirm my stake transfer to Arbitrum? - -\*\*\* You must confirm your transaction to complete the stake transfer on Arbitrum. This step must be completed within 7 days or stake could be lost. - -### What if I have open allocations? - -If you are not sending all of your stake, the L2 transfer tool will validate that at least the minimum 100k GRT remains in Ethereum Mainnet and your remaining stake and delegation is enough to cover any open allocations. You may need to close open allocations if your GRT balance does not cover the minimums + open allocations. - -### Using the transfer tools, is it necessary to wait 28 days to unstake on Ethereum Mainnet before transferring? - -No, you can transfer your stake to L2 immediately, there's no need to unstake and wait before using the transfer tool. The 28-day wait only applies if you'd like to withdraw the stake back to your wallet, on Ethereum Mainnet or L2. - -### How long will it take to transfer my stake? - -It will take approximately 20 minutes for the L2 transfer tool to complete transferring your stake. - -### Do I have to index on Arbitrum before I transfer my stake? - -You can effectively transfer your stake first before setting up indexing, but you will not be able to claim any rewards on L2 until you allocate to Subgraphs on L2, index them, and present POIs. - -### Can Delegators move their delegation before I move my indexing stake? - -No, in order for Delegators to transfer their delegated GRT to Arbitrum, the Indexer they are delegating to must be active on L2. - -### Can I transfer my stake if I'm using a GRT vesting contract / token lock wallet? - -Yes! The process is a bit different, because vesting contracts can't forward the ETH needed to pay for the L2 gas, so you need to deposit it beforehand. If your vesting contract is not fully vested, you will also have to first initialize a counterpart vesting contract on L2 and will only be able to transfer the stake to this L2 vesting contract. The UI on Explorer can guide you through this process when you've connected to Explorer using the vesting lock wallet. - -### I already have stake on L2. Do I still need to send 100k GRT when I use the transfer tools the first time? - -​Yes. The L1 smart contracts will not be aware of your L2 stake, so they will require you to transfer at least 100k GRT when you transfer for the first time. ​ - -### Can I transfer my stake to L2 if I am in the process of unstaking GRT? - -​No. If any fraction of your stake is thawing, you have to wait the 28 days and withdraw it before you can transfer stake. The tokens that are being staked are "locked" and will prevent any transfers or stake to L2. - -## Vesting Contract Transfer - -### How do I transfer my vesting contract? - -To transfer your vesting, you will need to complete the following steps: - -1. Initiate the vesting transfer on Ethereum Mainnet - -2. Wait 20 minutes for confirmation - -3. Confirm vesting transfer on Arbitrum - -### How do I transfer my vesting contract if I am only partially vested? - - - -1. Deposit some ETH into the transfer tool contract (UI can help estimate a reasonable amount) - -2. Send some locked GRT through the transfer tool contract, to L2 to initialize the L2 vesting lock. This will also set their L2 beneficiary address. - -3. Send their stake/delegation to L2 through the "locked" transfer tool functions in the L1Staking contract. - -4. Withdraw any remaining ETH from the transfer tool contract - -### How do I transfer my vesting contract if I am fully vested? - - - -For those that are fully vested, the process is similar: - -1. Deposit some ETH into the transfer tool contract (UI can help estimate a reasonable amount) - -2. Set your L2 address with a call to the transfer tool contract - -3. Send your stake/delegation to L2 through the "locked" transfer tool functions in the L1 Staking contract. - -4. Withdraw any remaining ETH from the transfer tool contract - -### Can I transfer my vesting contract to Arbitrum? - -You can transfer your vesting contract's GRT balance to a vesting contract in L2. This is a prerequisite for transferring stake or delegation from your vesting contract to L2. The vesting contract must hold a nonzero amount of GRT (you can transfer a small amount like 1 GRT to it if needed). - -When you transfer GRT from your L1 vesting contract to L2, you can choose the amount to send and you can do this as many times as you like. The L2 vesting contract will be initialized the first time you transfer GRT. - -The transfers are done using a Transfer Tool that will be visible on your Explorer profile when you connect with the vesting contract account. - -Please note that you will not be able to release/withdraw GRT from the L2 vesting contract until the end of your vesting timeline when your contract is fully vested. If you need to release GRT before then, you can transfer the GRT back to the L1 vesting contract using another transfer tool that is available for that purpose. - -If you haven't transferred any vesting contract balance to L2, and your vesting contract is fully vested, you should not transfer your vesting contract to L2. Instead, you can use the transfer tools to set an L2 wallet address, and directly transfer your stake or delegation to this regular wallet on L2. - -### I'm using my vesting contract to stake on mainnet. Can I transfer my stake to Arbitrum? - -Yes, but if your contract is still vesting, you can only transfer the stake so that it is owned by your L2 vesting contract. You must first initialize this L2 contract by transferring some GRT balance using the vesting contract transfer tool on Explorer. If your contract is fully vested, you can transfer your stake to any address in L2, but you must set it beforehand and deposit some ETH for the L2 transfer tool to pay for L2 gas. - -### I'm using my vesting contract to delegate on mainnet. Can I transfer my delegations to Arbitrum? - -Yes, but if your contract is still vesting, you can only transfer the delegation so that it is owned by your L2 vesting contract. You must first initialize this L2 contract by transferring some GRT balance using the vesting contract transfer tool on Explorer. If your contract is fully vested, you can transfer your delegation to any address in L2, but you must set it beforehand and deposit some ETH for the L2 transfer tool to pay for L2 gas. - -### Can I specify a different beneficiary for my vesting contract on L2? - -Yes, the first time you transfer a balance and set up your L2 vesting contract, you can specify an L2 beneficiary. Make sure this beneficiary is a wallet that can perform transactions on Arbitrum One, i.e. it must be an EOA or a multisig deployed to Arbitrum One. - -If your contract is fully vested, you will not set up a vesting contract on L2; instead, you will set an L2 wallet address and this will be the receiving wallet for your stake or delegation on Arbitrum. - -### My contract is fully vested. Can I transfer my stake or delegation to another address that is not an L2 vesting contract? - -Yes. If you haven't transferred any vesting contract balance to L2, and your vesting contract is fully vested, you should not transfer your vesting contract to L2. Instead, you can use the transfer tools to set an L2 wallet address, and directly transfer your stake or delegation to this regular wallet on L2. - -This allows you to transfer your stake or delegation to any L2 address. - -### My vesting contract is still vesting. How do I transfer my vesting contract balance to L2? - -These steps only apply if your contract is still vesting, or if you've used this process before when your contract was still vesting. - -To transfer your vesting contract to L2, you will send any GRT balance to L2 using the transfer tools, which will initialize your L2 vesting contract: - -1. Deposit some ETH into the transfer tool contract (this will be used to pay for L2 gas) - -2. Revoke protocol access to the vesting contract (needed for the next step) - -3. Give protocol access to the vesting contract (will allow your contract to interact with the transfer tool) - -4. Specify an L2 beneficiary address\* and initiate the balance transfer on Ethereum Mainnet - -5. Wait 20 minutes for confirmation - -6. Confirm the balance transfer on L2 - -\*If necessary - i.e. you are using a contract address. - -\*\*\*\*You must confirm your transaction to complete the balance transfer on Arbitrum. This step must be completed within 7 days or the balance could be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol). - -### My vesting contract shows 0 GRT so I cannot transfer it, why is this and how do I fix it? - -​To initialize your L2 vesting contract, you need to transfer a nonzero amount of GRT to L2. This is required by the Arbitrum GRT bridge that is used by the L2 Transfer Tools. The GRT must come from the vesting contract's balance, so it does not include staked or delegated GRT. - -If you've staked or delegated all your GRT from the vesting contract, you can manually send a small amount like 1 GRT to the vesting contract address from anywhere else (e.g. from another wallet, or an exchange). ​ - -### I am using a vesting contract to stake or delegate, but I don't see a button to transfer my stake or delegation to L2, what do I do? - -​If your vesting contract hasn't finished vesting, you need to first create an L2 vesting contract that will receive your stake or delegation on L2. This vesting contract will not allow releasing tokens in L2 until the end of the vesting timeline, but will allow you to transfer GRT back to the L1 vesting contract to be released there. - -When connected with the vesting contract on Explorer, you should see a button to initialize your L2 vesting contract. Follow that process first, and you will then see the buttons to transfer your stake or delegation in your profile. ​ - -### If I initialize my L2 vesting contract, will this also transfer my delegation to L2 automatically? - -​No, initializing your L2 vesting contract is a prerequisite for transferring stake or delegation from the vesting contract, but you still need to transfer these separately. - -You will see a banner on your profile prompting you to transfer your stake or delegation after you have initialized your L2 vesting contract. - -### Can I move my vesting contract back to L1? - -There is no need to do so because your vesting contract is still in L1. When you use the transfer tools, you just create a new contract in L2 that is connected with your L1 vesting contract, and you can send GRT back and forth between the two. - -### Why do I need to move my vesting contract to begin with? - -You need to set up an L2 vesting contract so that this account can own your stake or delegation on L2. Otherwise, there'd be no way for you to transfer the stake/delegation to L2 without "escaping" the vesting contract. - -### What happens if I try to cash out my contract when it is only partially vested? Is this possible? - -This is not a possibility. You can move funds back to L1 and withdraw them there. - -### What if I don't want to move my vesting contract to L2? - -You can keep staking/delegating on L1. Over time, you may want to consider moving to L2 to enable rewards there as the protocol scales on Arbitrum. Note that these transfer tools are for vesting contracts that are allowed to stake and delegate in the protocol. If your contract does not allow staking or delegating, or is revocable, then there is no transfer tool available. You will still be able to withdraw your GRT from L1 when available. diff --git a/website/src/pages/en/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/src/pages/en/archived/arbitrum/l2-transfer-tools-guide.mdx deleted file mode 100644 index bd720aeb72ce..000000000000 --- a/website/src/pages/en/archived/arbitrum/l2-transfer-tools-guide.mdx +++ /dev/null @@ -1,167 +0,0 @@ ---- -title: L2 Transfer Tools Guide ---- - -> [!IMPORTANT] L2 Transfer Tools have been deprecated, and The Graph now runs on Arbitrum, a Layer 2 blockchain. - -The Graph has made it easy to move to L2 on Arbitrum One. For each protocol participant, there are a set of L2 Transfer Tools to make transferring to L2 seamless for all network participants. These tools will require you to follow a specific set of steps depending on what you are transferring. - -Some frequent questions about these tools are answered in the [L2 Transfer Tools FAQ](/archived/arbitrum/l2-transfer-tools-faq/). The FAQs contain in-depth explanations of how to use the tools, how they work, and things to keep in mind when using them. - -## How to transfer your Subgraph to Arbitrum (L2) - - - -## Benefits of transferring your Subgraphs - -The Graph's community and core devs have [been preparing](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) to move to Arbitrum over the past year. Arbitrum, a layer 2 or "L2" blockchain, inherits the security from Ethereum Mainnet but provides drastically lower gas fees. - -When you publish or upgrade your Subgraph to The Graph Network, you're interacting with smart contracts on the protocol and this requires paying for gas using ETH. By moving your Subgraphs to Arbitrum, any future updates to your Subgraph will require much lower gas fees. The lower fees, and the fact that curation bonding curves on L2 are flat, also make it easier for other Curators to curate on your Subgraph, increasing the rewards for Indexers on your Subgraph. This lower-cost environment also makes it cheaper for Indexers to index and serve your Subgraph. Indexing rewards will be increasing on Arbitrum and decreasing on Ethereum Mainnet over the coming months, so more and more Indexers will be transferring their stake and setting up their operations on L2. - -## Understanding what happens with signal, your L1 Subgraph and query URLs - -Transferring a Subgraph to Arbitrum uses the Arbitrum GRT bridge, which in turn uses the native Arbitrum bridge, to send the Subgraph to L2. The "transfer" will deprecate the Subgraph on mainnet and send the information to re-create the Subgraph on L2 using the bridge. It will also include the Subgraph owner's signaled GRT, which must be more than zero for the bridge to accept the transfer. - -When you choose to transfer the Subgraph, this will convert all of the Subgraph's curation signal to GRT. This is equivalent to "deprecating" the Subgraph on mainnet. The GRT corresponding to your curation will be sent to L2 together with the Subgraph, where they will be used to mint signal on your behalf. - -Other Curators can choose whether to withdraw their fraction of GRT, or also transfer it to L2 to mint signal on the same Subgraph. If a Subgraph owner does not transfer their Subgraph to L2 and manually deprecates it via a contract call, then Curators will be notified and will be able to withdraw their curation. - -As soon as the Subgraph is transferred, since all curation is converted to GRT, Indexers will no longer receive rewards for indexing the Subgraph. However, there will be Indexers that will 1) keep serving transferred Subgraphs for 24 hours, and 2) immediately start indexing the Subgraph on L2. Since these Indexers already have the Subgraph indexed, there should be no need to wait for the Subgraph to sync, and it will be possible to query the L2 Subgraph almost immediately. - -Queries to the L2 Subgraph will need to be done to a different URL (on `arbitrum-gateway.thegraph.com`), but the L1 URL will continue working for at least 48 hours. After that, the L1 gateway will forward queries to the L2 gateway (for some time), but this will add latency so it is recommended to switch all your queries to the new URL as soon as possible. - -## Choosing your L2 wallet - -When you published your Subgraph on mainnet, you used a connected wallet to create the Subgraph, and this wallet owns the NFT that represents this Subgraph and allows you to publish updates. - -When transferring the Subgraph to Arbitrum, you can choose a different wallet that will own this Subgraph NFT on L2. - -If you're using a "regular" wallet like MetaMask (an Externally Owned Account or EOA, i.e. a wallet that is not a smart contract), then this is optional and it is recommended to keep the same owner address as in L1. - -If you're using a smart contract wallet, like a multisig (e.g. a Safe), then choosing a different L2 wallet address is mandatory, as it is most likely that this account only exists on mainnet and you will not be able to make transactions on Arbitrum using this wallet. If you want to keep using a smart contract wallet or multisig, create a new wallet on Arbitrum and use its address as the L2 owner of your Subgraph. - -**It is very important to use a wallet address that you control, and that can make transactions on Arbitrum. Otherwise, the Subgraph will be lost and cannot be recovered.** - -## Preparing for the transfer: bridging some ETH - -Transferring the Subgraph involves sending a transaction through the bridge, and then executing another transaction on Arbitrum. The first transaction uses ETH on mainnet, and includes some ETH to pay for gas when the message is received on L2. However, if this gas is insufficient, you will have to retry the transaction and pay for the gas directly on L2 (this is "Step 3: Confirming the transfer" below). This step **must be executed within 7 days of starting the transfer**. Moreover, the second transaction ("Step 4: Finishing the transfer on L2") will be done directly on Arbitrum. For these reasons, you will need some ETH on an Arbitrum wallet. If you're using a multisig or smart contract account, the ETH will need to be in the regular (EOA) wallet that you are using to execute the transactions, not on the multisig wallet itself. - -You can buy ETH on some exchanges and withdraw it directly to Arbitrum, or you can use the Arbitrum bridge to send ETH from a mainnet wallet to L2: [bridge.arbitrum.io](http://bridge.arbitrum.io). Since gas fees on Arbitrum are lower, you should only need a small amount. It is recommended that you start at a low threshold (0.e.g. 01 ETH) for your transaction to be approved. - -## Finding the Subgraph Transfer Tool - -You can find the L2 Transfer Tool when you're looking at your Subgraph's page on Subgraph Studio: - -![transfer tool](/img/L2-transfer-tool1.png) - -It is also available on Explorer if you're connected with the wallet that owns a Subgraph and on that Subgraph's page on Explorer: - -![Transferring to L2](/img/transferToL2.png) - -Clicking on the Transfer to L2 button will open the transfer tool where you can start the transfer process. - -## Step 1: Starting the transfer - -Before starting the transfer, you must decide which address will own the Subgraph on L2 (see "Choosing your L2 wallet" above), and it is strongly recommend having some ETH for gas already bridged on Arbitrum (see "Preparing for the transfer: bridging some ETH" above). - -Also please note transferring the Subgraph requires having a nonzero amount of signal on the Subgraph with the same account that owns the Subgraph; if you haven't signaled on the Subgraph you will have to add a bit of curation (adding a small amount like 1 GRT would suffice). - -After opening the Transfer Tool, you will be able to input the L2 wallet address into the "Receiving wallet address" field - **make sure you've entered the correct address here**. Clicking on Transfer Subgraph will prompt you to execute the transaction on your wallet (note some ETH value is included to pay for L2 gas); this will initiate the transfer and deprecate your L1 Subgraph (see "Understanding what happens with signal, your L1 Subgraph and query URLs" above for more details on what goes on behind the scenes). - -If you execute this step, **make sure you proceed until completing step 3 in less than 7 days, or the Subgraph and your signal GRT will be lost.** This is due to how L1-L2 messaging works on Arbitrum: messages that are sent through the bridge are "retry-able tickets" that must be executed within 7 days, and the initial execution might need a retry if there are spikes in the gas price on Arbitrum. - -![Start the transfer to L2](/img/startTransferL2.png) - -## Step 2: Waiting for the Subgraph to get to L2 - -After you start the transfer, the message that sends your L1 Subgraph to L2 must propagate through the Arbitrum bridge. This takes approximately 20 minutes (the bridge waits for the mainnet block containing the transaction to be "safe" from potential chain reorgs). - -Once this wait time is over, Arbitrum will attempt to auto-execute the transfer on the L2 contracts. - -![Wait screen](/img/screenshotOfWaitScreenL2.png) - -## Step 3: Confirming the transfer - -In most cases, this step will auto-execute as the L2 gas included in step 1 should be sufficient to execute the transaction that receives the Subgraph on the Arbitrum contracts. In some cases, however, it is possible that a spike in gas prices on Arbitrum causes this auto-execution to fail. In this case, the "ticket" that sends your Subgraph to L2 will be pending and require a retry within 7 days. - -If this is the case, you will need to connect using an L2 wallet that has some ETH on Arbitrum, switch your wallet network to Arbitrum, and click on "Confirm Transfer" to retry the transaction. - -![Confirm the transfer to L2](/img/confirmTransferToL2.png) - -## Step 4: Finishing the transfer on L2 - -At this point, your Subgraph and GRT have been received on Arbitrum, but the Subgraph is not published yet. You will need to connect using the L2 wallet that you chose as the receiving wallet, switch your wallet network to Arbitrum, and click "Publish Subgraph." - -![Publish the Subgraph](/img/publishSubgraphL2TransferTools.png) - -![Wait for the Subgraph to be published](/img/waitForSubgraphToPublishL2TransferTools.png) - -This will publish the Subgraph so that Indexers that are operating on Arbitrum can start serving it. It will also mint curation signal using the GRT that were transferred from L1. - -## Step 5: Updating the query URL - -Your Subgraph has been successfully transferred to Arbitrum! To query the Subgraph, the new URL will be : - -`https://arbitrum-gateway.thegraph.com/api/[api-key]/subgraphs/id/[l2-subgraph-id]` - -Note that the Subgraph ID on Arbitrum will be a different than the one you had on mainnet, but you can always find it on Explorer or Studio. As mentioned above (see "Understanding what happens with signal, your L1 Subgraph and query URLs") the old L1 URL will be supported for a short while, but you should switch your queries to the new address as soon as the Subgraph has been synced on L2. - -## How to transfer your curation to Arbitrum (L2) - -## Understanding what happens to curation on Subgraph transfers to L2 - -When the owner of a Subgraph transfers a Subgraph to Arbitrum, all of the Subgraph's signal is converted to GRT at the same time. This applies to "auto-migrated" signal, i.e. signal that is not specific to a Subgraph version or deployment but that follows the latest version of a Subgraph. - -This conversion from signal to GRT is the same as what would happen if the Subgraph owner deprecated the Subgraph in L1. When the Subgraph is deprecated or transferred, all curation signal is "burned" simultaneously (using the curation bonding curve) and the resulting GRT is held by the GNS smart contract (that is the contract that handles Subgraph upgrades and auto-migrated signal). Each Curator on that Subgraph therefore has a claim to that GRT proportional to the amount of shares they had for the Subgraph. - -A fraction of these GRT corresponding to the Subgraph owner is sent to L2 together with the Subgraph. - -At this point, the curated GRT will not accrue any more query fees, so Curators can choose to withdraw their GRT or transfer it to the same Subgraph on L2, where it can be used to mint new curation signal. There is no rush to do this as the GRT can be help indefinitely and everybody gets an amount proportional to their shares, irrespective of when they do it. - -## Choosing your L2 wallet - -If you decide to transfer your curated GRT to L2, you can choose a different wallet that will own the curation signal on L2. - -If you're using a "regular" wallet like Metamask (an Externally Owned Account or EOA, i.e. a wallet that is not a smart contract), then this is optional and it is recommended to keep the same Curator address as in L1. - -If you're using a smart contract wallet, like a multisig (e.g. a Safe), then choosing a different L2 wallet address is mandatory, as it is most likely that this account only exists on mainnet and you will not be able to make transactions on Arbitrum using this wallet. If you want to keep using a smart contract wallet or multisig, create a new wallet on Arbitrum and use its address as the L2 receiving wallet address. - -**It is very important to use a wallet address that you control, and that can make transactions on Arbitrum, as otherwise the curation will be lost and cannot be recovered.** - -## Sending curation to L2: Step 1 - -Before starting the transfer, you must decide which address will own the curation on L2 (see "Choosing your L2 wallet" above), and it is recommended having some ETH for gas already bridged on Arbitrum in case you need to retry the execution of the message on L2. You can buy ETH on some exchanges and withdraw it directly to Arbitrum, or you can use the Arbitrum bridge to send ETH from a mainnet wallet to L2: [bridge.arbitrum.io](http://bridge.arbitrum.io) - since gas fees on Arbitrum are so low, you should only need a small amount, e.g. 0.01 ETH will probably be more than enough. - -If a Subgraph that you curate to has been transferred to L2, you will see a message on Explorer telling you that you're curating to a transferred Subgraph. - -When looking at the Subgraph page, you can choose to withdraw or transfer the curation. Clicking on "Transfer Signal to Arbitrum" will open the transfer tool. - -![Transfer signal](/img/transferSignalL2TransferTools.png) - -After opening the Transfer Tool, you may be prompted to add some ETH to your wallet if you don't have any. Then you will be able to input the L2 wallet address into the "Receiving wallet address" field - **make sure you've entered the correct address here**. Clicking on Transfer Signal will prompt you to execute the transaction on your wallet (note some ETH value is included to pay for L2 gas); this will initiate the transfer. - -If you execute this step, **make sure you proceed until completing step 3 in less than 7 days, or your signal GRT will be lost.** This is due to how L1-L2 messaging works on Arbitrum: messages that are sent through the bridge are "retryable tickets" that must be executed within 7 days, and the initial execution might need a retry if there are spikes in the gas price on Arbitrum. - -## Sending curation to L2: step 2 - -Starting the transfer: - -![Send signal to L2](/img/sendingCurationToL2Step2First.png) - -After you start the transfer, the message that sends your L1 curation to L2 must propagate through the Arbitrum bridge. This takes approximately 20 minutes (the bridge waits for the mainnet block containing the transaction to be "safe" from potential chain reorgs). - -Once this wait time is over, Arbitrum will attempt to auto-execute the transfer on the L2 contracts. - -![Sending curation signal to L2](/img/sendingCurationToL2Step2Second.png) - -## Sending curation to L2: step 3 - -In most cases, this step will auto-execute as the L2 gas included in step 1 should be sufficient to execute the transaction that receives the curation on the Arbitrum contracts. In some cases, however, it is possible that a spike in gas prices on Arbitrum causes this auto-execution to fail. In this case, the "ticket" that sends your curation to L2 will be pending and require a retry within 7 days. - -If this is the case, you will need to connect using an L2 wallet that has some ETH on Arbitrum, switch your wallet network to Arbitrum, and click on "Confirm Transfer" to retry the transaction. - -![Send signal to L2](/img/L2TransferToolsFinalCurationImage.png) - -## Withdrawing your curation on L1 - -If you prefer not to send your GRT to L2, or you'd rather bridge the GRT manually, you can withdraw your curated GRT on L1. On the banner on the Subgraph page, choose "Withdraw Signal" and confirm the transaction; the GRT will be sent to your Curator address. diff --git a/website/src/pages/en/archived/sunrise.mdx b/website/src/pages/en/archived/sunrise.mdx deleted file mode 100644 index 058fef0f71ee..000000000000 --- a/website/src/pages/en/archived/sunrise.mdx +++ /dev/null @@ -1,80 +0,0 @@ ---- -title: Post-Sunrise + Upgrading to The Graph Network FAQ -sidebarTitle: Post-Sunrise Upgrade FAQ ---- - -> Note: The Sunrise of Decentralized Data ended June 12th, 2024. - -## What was the Sunrise of Decentralized Data? - -The Sunrise of Decentralized Data was an initiative spearheaded by Edge & Node. This initiative enabled Subgraph developers to upgrade to The Graph’s decentralized network seamlessly. - -This plan drew on previous developments from The Graph ecosystem, including an upgrade Indexer to serve queries on newly published Subgraphs. - -### What happened to the hosted service? - -The hosted service query endpoints are no longer available, and developers cannot deploy new Subgraphs on the hosted service. - -During the upgrade process, owners of hosted service Subgraphs could upgrade their Subgraphs to The Graph Network. Additionally, developers were able to claim auto-upgraded Subgraphs. - -### Was Subgraph Studio impacted by this upgrade? - -No, Subgraph Studio was not impacted by Sunrise. Subgraphs were immediately available for querying, powered by the upgrade Indexer, which uses the same infrastructure as the hosted service. - -### Why were Subgraphs published to Arbitrum, did it start indexing a different network? - -The Graph Network was initially deployed on Ethereum Mainnet but was later moved to Arbitrum One in order to lower gas costs for all users. As a result, all new Subgraphs are published to The Graph Network on Arbitrum so that Indexers can support them. Arbitrum is the network that Subgraphs are published to, but Subgraphs can index any of the [supported networks](/supported-networks/) - -## About the Upgrade Indexer - -> The upgrade Indexer is currently active. - -The upgrade Indexer was implemented to improve the experience of upgrading Subgraphs from the hosted service to The Graph Network and support new versions of existing Subgraphs that had not yet been indexed. - -### What does the upgrade Indexer do? - -- It bootstraps chains that have yet to receive indexing rewards on The Graph Network and ensures that an Indexer is available to serve queries as quickly as possible after a Subgraph is published. -- It supports chains that were previously only available on the hosted service. Find a comprehensive list of supported chains [here](/supported-networks/). -- Indexers that operate an upgrade Indexer do so as a public service to support new Subgraphs and additional chains that lack indexing rewards before The Graph Council approves them. - -### Why is Edge & Node running the upgrade Indexer? - -Edge & Node historically maintained the hosted service and, as a result, already have synced data for hosted service Subgraphs. - -### What does the upgrade indexer mean for existing Indexers? - -Chains previously only supported on the hosted service were made available to developers on The Graph Network without indexing rewards at first. - -However, this action unlocked query fees for any interested Indexer and increased the number of Subgraphs published on The Graph Network. As a result, Indexers have more opportunities to index and serve these Subgraphs in exchange for query fees, even before indexing rewards are enabled for a chain. - -The upgrade Indexer also provides the Indexer community with information about the potential demand for Subgraphs and new chains on The Graph Network. - -### What does this mean for Delegators? - -The upgrade Indexer offers a powerful opportunity for Delegators. As it allowed more Subgraphs to be upgraded from the hosted service to The Graph Network, Delegators benefit from the increased network activity. - -### Did the upgrade Indexer compete with existing Indexers for rewards? - -No, the upgrade Indexer only allocates the minimum amount per Subgraph and does not collect indexing rewards. - -It operates on an “as needed” basis, serving as a fallback until sufficient service quality is achieved by at least three other Indexers in the network for respective chains and Subgraphs. - -### How does this affect Subgraph developers? - -Subgraph developers can query their Subgraphs on The Graph Network almost immediately after upgrading from the hosted service or [publishing from Subgraph Studio](/subgraphs/developing/publishing/publishing-a-subgraph/), as no lead time was required for indexing. Please note that [creating a Subgraph](/developing/creating-a-subgraph/) was not impacted by this upgrade. - -### How does the upgrade Indexer benefit data consumers? - -The upgrade Indexer enables chains on the network that were previously only supported on the hosted service. Therefore, it widens the scope and availability of data that can be queried on the network. - -### How does the upgrade Indexer price queries? - -The upgrade Indexer prices queries at the market rate to avoid influencing the query fee market. - -### When will the upgrade Indexer stop supporting a Subgraph? - -The upgrade Indexer supports a Subgraph until at least 3 other Indexers successfully and consistently serve queries made to it. - -Furthermore, the upgrade Indexer stops supporting a Subgraph if it has not been queried in the last 30 days. - -Other Indexers are incentivized to support Subgraphs with ongoing query volume. The query volume to the upgrade Indexer should trend towards zero, as it has a small allocation size, and other Indexers should be chosen for queries ahead of it. diff --git a/website/src/pages/en/contracts.mdx b/website/src/pages/en/contracts.mdx index 3a3450cfbedf..d9b51ac8b3cb 100644 --- a/website/src/pages/en/contracts.mdx +++ b/website/src/pages/en/contracts.mdx @@ -14,7 +14,7 @@ This is the principal deployment of The Graph Network. ## Ethereum Mainnet -This was the original deployment of The Graph Network. [Learn more](/archived/arbitrum/arbitrum-faq/) about The Graph's scaling with Arbitrum. +This was the original deployment of The Graph Network. Learn more about The Graph's scaling with Arbitrum. diff --git a/website/src/pages/en/graph-horizon/overview.mdx b/website/src/pages/en/graph-horizon/overview.mdx index b626f0686d37..908f5327d509 100644 --- a/website/src/pages/en/graph-horizon/overview.mdx +++ b/website/src/pages/en/graph-horizon/overview.mdx @@ -1,6 +1,6 @@ --- title: Graph Horizon Overview -sidebarTitle: Overview +sidebarTitle: Horizon Overview --- This document provides a high level overview of Graph Horizon. For a deep dive the following GIPs are recommended: diff --git a/website/src/pages/en/indexing/_meta.js b/website/src/pages/en/indexing/_meta.js index 194d7618a935..78e198dda138 100644 --- a/website/src/pages/en/indexing/_meta.js +++ b/website/src/pages/en/indexing/_meta.js @@ -1,10 +1,10 @@ -import titles from './_meta-titles.json' - export default { overview: '', - tooling: titles.tooling ?? '', - tap: '', - 'supported-network-requirements': '', - 'chain-integration-overview': '', + firehose: '', + 'graph-node': '', + graphcast: 'GraphCast', + tap: 'GraphTally for Indexers', + 'supported-network-requirements': 'Supported Networks and Node Requirements', 'new-chain-integration': '', + 'chain-integration-overview': 'Chain Integration Process', } diff --git a/website/src/pages/en/indexing/tooling/firehose.mdx b/website/src/pages/en/indexing/firehose.mdx similarity index 100% rename from website/src/pages/en/indexing/tooling/firehose.mdx rename to website/src/pages/en/indexing/firehose.mdx diff --git a/website/src/pages/en/indexing/tooling/graph-node.mdx b/website/src/pages/en/indexing/graph-node.mdx similarity index 100% rename from website/src/pages/en/indexing/tooling/graph-node.mdx rename to website/src/pages/en/indexing/graph-node.mdx diff --git a/website/src/pages/en/indexing/tooling/graphcast.mdx b/website/src/pages/en/indexing/graphcast.mdx similarity index 100% rename from website/src/pages/en/indexing/tooling/graphcast.mdx rename to website/src/pages/en/indexing/graphcast.mdx diff --git a/website/src/pages/en/indexing/tooling/_meta.js b/website/src/pages/en/indexing/tooling/_meta.js deleted file mode 100644 index 0bbd5b4df3d3..000000000000 --- a/website/src/pages/en/indexing/tooling/_meta.js +++ /dev/null @@ -1,5 +0,0 @@ -export default { - 'graph-node': '', - firehose: '', - graphcast: '', -} diff --git a/website/src/pages/en/resources/_meta-titles.json b/website/src/pages/en/resources/_meta-titles.json index f5971e95a8f6..2ba6b6f58292 100644 --- a/website/src/pages/en/resources/_meta-titles.json +++ b/website/src/pages/en/resources/_meta-titles.json @@ -1,4 +1,3 @@ { - "roles": "Additional Roles", - "migration-guides": "Migration Guides" + "roles": "Additional Roles" } diff --git a/website/src/pages/en/resources/_meta.js b/website/src/pages/en/resources/_meta.js index 38c56cf56c43..761214f7fe61 100644 --- a/website/src/pages/en/resources/_meta.js +++ b/website/src/pages/en/resources/_meta.js @@ -5,6 +5,4 @@ export default { tokenomics: '', benefits: '', roles: titles.roles ?? '', - 'migration-guides': titles['migration-guides'] ?? '', - 'subgraph-studio-faq': '', } diff --git a/website/src/pages/en/resources/benefits.mdx b/website/src/pages/en/resources/benefits.mdx index 87bd1adc9cdd..10885bd1b54a 100644 --- a/website/src/pages/en/resources/benefits.mdx +++ b/website/src/pages/en/resources/benefits.mdx @@ -75,7 +75,7 @@ Query costs may vary; the quoted cost is the average at time of publication (Mar ‡Reflects cost for data consumer. Query fees are still paid to Indexers for Free Plan queries. -Estimated costs are only for Ethereum Mainnet Subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their Subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet. +Estimated costs are only for Ethereum Mainnet Subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their Subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on Arbitrum are substantially lower than Ethereum mainnet. Curating signal on a Subgraph is an optional one-time, net-zero cost (e.g., $1k in signal can be curated on a Subgraph, and later withdrawn—with potential to earn returns in the process). diff --git a/website/src/pages/en/resources/migration-guides/_meta.js b/website/src/pages/en/resources/migration-guides/_meta.js deleted file mode 100644 index 541e5b7f6ea2..000000000000 --- a/website/src/pages/en/resources/migration-guides/_meta.js +++ /dev/null @@ -1,4 +0,0 @@ -export default { - 'assemblyscript-migration-guide': '', - 'graphql-validations-migration-guide': '', -} diff --git a/website/src/pages/en/resources/migration-guides/assemblyscript-migration-guide.mdx b/website/src/pages/en/resources/migration-guides/assemblyscript-migration-guide.mdx deleted file mode 100644 index aead2514ff51..000000000000 --- a/website/src/pages/en/resources/migration-guides/assemblyscript-migration-guide.mdx +++ /dev/null @@ -1,524 +0,0 @@ ---- -title: AssemblyScript Migration Guide ---- - -Up until now, Subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉 - -That will enable Subgraph developers to use newer features of the AS language and standard library. - -This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂 - -> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the Subgraph manifest. - -## Features - -### New functionality - -- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1)) -- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0)) -- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2)) -- Added `StaticArray`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3)) -- Added `Array#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0)) -- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1)) -- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7)) -- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0)) -- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13)) -- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2)) -- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17)) -- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27)) -- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29)) -- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30)) -- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2)) - -### Optimizations - -- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0)) -- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1)) -- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8)) -- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2)) - -### Other - -- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0)) -- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0)) - -## How to upgrade? - -1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.9`: - -```yaml -... -dataSources: - ... - mapping: - ... - apiVersion: 0.0.9 - ... -``` - -2. Update the `graph-cli` you're using to the `latest` version by running: - -```bash -# if you have it globally installed -npm install --global @graphprotocol/graph-cli@latest - -# or in your subgraph if you have it as a dev dependency -npm install --save-dev @graphprotocol/graph-cli@latest -``` - -3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies: - -```bash -npm install --save @graphprotocol/graph-ts@latest -``` - -4. Follow the rest of the guide to fix the language breaking changes. -5. Run `codegen` and `deploy` again. - -## Breaking changes - -### Nullability - -On the older version of AssemblyScript, you could create code like this: - -```typescript -function load(): Value | null { ... } - -let maybeValue = load(); -maybeValue.aMethod(); -``` - -However on the newer version, because the value is nullable, it requires you to check, like this: - -```typescript -let maybeValue = load() - -if (maybeValue) { - maybeValue.aMethod() // `maybeValue` is not null anymore -} -``` - -Or force it like this: - -```typescript -let maybeValue = load()! // breaks in runtime if value is null - -maybeValue.aMethod() -``` - -If you are unsure which to choose, we recommend always using the safe version. If the value doesn't exist you might want to just do an early if statement with a return in you Subgraph handler. - -### Variable Shadowing - -Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work: - -```typescript -let a = 10 -let b = 20 -let a = a + b -``` - -However now this isn't possible anymore, and the compiler returns this error: - -```typescript -ERROR TS2451: Cannot redeclare block-scoped variable 'a' - - let a = a + b; - ~~~~~~~~~~~~~ -in assembly/index.ts(4,3) -``` - -You'll need to rename your duplicate variables if you had variable shadowing. - -### Null Comparisons - -By doing the upgrade on your Subgraph, sometimes you might get errors like these: - -```typescript -ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' is not assignable to type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt'. - if (decimals == null) { - ~~~~ - in src/mappings/file.ts(41,21) -``` - -To solve you can simply change the `if` statement to something like this: - -```typescript - if (!decimals) { - - // or - - if (decimals === null) { -``` - -The same applies if you're doing != instead of ==. - -### Casting - -The common way to do casting before was to just use the `as` keyword, like this: - -```typescript -let byteArray = new ByteArray(10) -let uint8Array = byteArray as Uint8Array // equivalent to: byteArray -``` - -However this only works in two scenarios: - -- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`); -- Upcasting on class inheritance (subclass → superclass) - -Examples: - -```typescript -// primitive casting -let a: usize = 10 -let b: isize = 5 -let c: usize = a + (b as usize) -``` - -```typescript -// upcasting on class inheritance -class Bytes extends Uint8Array {} - -let bytes = new Bytes(2) -// bytes // same as: bytes as Uint8Array -``` - -There are two scenarios where you may want to cast, but using `as`/`var` **isn't safe**: - -- Downcasting on class inheritance (superclass → subclass) -- Between two types that share a superclass - -```typescript -// downcasting on class inheritance -class Bytes extends Uint8Array {} - -let uint8Array = new Uint8Array(2) -// uint8Array // breaks in runtime :( -``` - -```typescript -// between two types that share a superclass -class Bytes extends Uint8Array {} -class ByteArray extends Uint8Array {} - -let bytes = new Bytes(2) -// bytes // breaks in runtime :( -``` - -For those cases, you can use the `changetype` function: - -```typescript -// downcasting on class inheritance -class Bytes extends Uint8Array {} - -let uint8Array = new Uint8Array(2) -changetype(uint8Array) // works :) -``` - -```typescript -// between two types that share a superclass -class Bytes extends Uint8Array {} -class ByteArray extends Uint8Array {} - -let bytes = new Bytes(2) -changetype(bytes) // works :) -``` - -If you just want to remove nullability, you can keep using the `as` operator (or `variable`), but make sure you know that value can't be null, otherwise it will break. - -```typescript -// remove nullability -let previousBalance = AccountBalance.load(balanceId) // AccountBalance | null - -if (previousBalance != null) { - return previousBalance as AccountBalance // safe remove null -} - -let newBalance = new AccountBalance(balanceId) -``` - -For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂 - -Also we've added a few more static methods in some types to ease casting, they are: - -- Bytes.fromByteArray -- Bytes.fromUint8Array -- BigInt.fromByteArray -- ByteArray.fromBigInt - -### Nullability check with property access - -To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this: - -```typescript -let something: string | null = 'data' - -let somethingOrElse = something ? something : 'else' - -// or - -let somethingOrElse - -if (something) { - somethingOrElse = something -} else { - somethingOrElse = 'else' -} -``` - -However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this: - -```typescript -class Container { - data: string | null -} - -let container = new Container() -container.data = 'data' - -let somethingOrElse: string = container.data ? container.data : 'else' // doesn't compile -``` - -Which outputs this error: - -```typescript -ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/string/String'. - - let somethingOrElse: string = container.data ? container.data : "else"; - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -``` - -To fix this issue, you can create a variable for that property access so that the compiler can do the nullability check magic: - -```typescript -class Container { - data: string | null -} - -let container = new Container() -container.data = 'data' - -let data = container.data - -let somethingOrElse: string = data ? data : 'else' // compiles just fine :) -``` - -### Operator overloading with property access - -If you try to sum (for example) a nullable type (from a property access) with a non nullable one, the AssemblyScript compiler instead of giving a compile time error warning that one of the values is nullable, it just compiles silently, giving chance for the code to break at runtime. - -```typescript -class BigInt extends Uint8Array { - @operator('+') - plus(other: BigInt): BigInt { - // ... - } -} - -class Wrapper { - public constructor(public n: BigInt | null) {} -} - -let x = BigInt.fromI32(2) -let y: BigInt | null = null - -x + y // give compile time error about nullability - -let wrapper = new Wrapper(y) - -wrapper.n = wrapper.n + x // doesn't give compile time errors as it should -``` - -We've opened a issue on the AssemblyScript compiler for this, but for now if you do these kind of operations in your Subgraph mappings, you should change them to do a null check before it. - -```typescript -let wrapper = new Wrapper(y) - -if (!wrapper.n) { - wrapper.n = BigInt.fromI32(0) -} - -wrapper.n = wrapper.n + x // now `n` is guaranteed to be a BigInt -``` - -### Value initialization - -If you have any code like this: - -```typescript -var value: Type // null -value.x = 10 -value.y = 'content' -``` - -It will compile but break at runtime, that happens because the value hasn't been initialized, so make sure your Subgraph has initialized their values, like this: - -```typescript -var value = new Type() // initialized -value.x = 10 -value.y = 'content' -``` - -Also if you have nullable properties in a GraphQL entity, like this: - -```graphql -type Total @entity { - id: Bytes! - amount: BigInt -} -``` - -And you have code similar to this: - -```typescript -let total = Total.load('latest') - -if (total === null) { - total = new Total('latest') -} - -total.amount = total.amount + BigInt.fromI32(1) -``` - -You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first: - -```typescript -let total = Total.load('latest') - -if (total === null) { - total = new Total('latest') - total.amount = BigInt.fromI32(0) -} - -total.tokens = total.tokens + BigInt.fromI32(1) -``` - -Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉 - -```graphql -type Total @entity { - id: Bytes! - amount: BigInt! -} -``` - -```typescript -let total = Total.load('latest') - -if (total === null) { - total = new Total('latest') // already initializes non-nullable properties -} - -total.amount = total.amount + BigInt.fromI32(1) -``` - -### Class property initialization - -If you export any classes with properties that are other classes (declared by you or by the standard library) like this: - -```typescript -class Thing {} - -export class Something { - value: Thing -} -``` - -The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator: - -```typescript -export class Something { - constructor(public value: Thing) {} -} - -// or - -export class Something { - value: Thing - - constructor(value: Thing) { - this.value = value - } -} - -// or - -export class Something { - value!: Thing -} -``` - -### Array initialization - -The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example: - -```typescript -let arr = new Array(5) // ["", "", "", "", ""] - -arr.push('something') // ["", "", "", "", "", "something"] // size 6 :( -``` - -Depending on the types you're using, eg nullable ones, and how you're accessing them, you might encounter a runtime error like this one: - -``` -ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey wasm backtrace: 0: 0x19c4 - !~lib/@graphprotocol/graph-ts/index/format 1: 0x1e75 - !~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor 2: 0x30b9 - !node_modules/@graphprotocol/graph-ts/global/global/id_of_type -``` - -To actually push at the beginning you should either, initialize the `Array` with size zero, like this: - -```typescript -let arr = new Array(0) // [] - -arr.push('something') // ["something"] -``` - -Or you should mutate it via index: - -```typescript -let arr = new Array(5) // ["", "", "", "", ""] - -arr[0] = 'something' // ["something", "", "", "", ""] -``` - -### GraphQL schema - -This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file. - -Now you no longer can define fields in your types that are Non-Nullable Lists. If you have a schema like this: - -```graphql -type Something @entity { - id: Bytes! -} - -type MyEntity @entity { - id: Bytes! - invalidField: [Something]! # no longer valid -} -``` - -You'll have to add an `!` to the member of the List type, like this: - -```graphql -type Something @entity { - id: Bytes! -} - -type MyEntity @entity { - id: Bytes! - invalidField: [Something!]! # valid -} -``` - -This changed because of nullability differences between AssemblyScript versions, and it's related to the `src/generated/schema.ts` file (default path, you might have changed this). - -### Other - -- Aligned `Map#set` and `Set#add` with the spec, returning `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2)) -- Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0)) -- Classes initialized from object literals can no longer define a constructor ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0)) -- The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0)) -- Coerce `NaN` to `false` when casting to `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9)) -- When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0)) -- Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8)) diff --git a/website/src/pages/en/resources/migration-guides/graphql-validations-migration-guide.mdx b/website/src/pages/en/resources/migration-guides/graphql-validations-migration-guide.mdx deleted file mode 100644 index ebed96df1002..000000000000 --- a/website/src/pages/en/resources/migration-guides/graphql-validations-migration-guide.mdx +++ /dev/null @@ -1,538 +0,0 @@ ---- -title: GraphQL Validations Migration Guide ---- - -Soon `graph-node` will support 100% coverage of the [GraphQL Validations specification](https://spec.graphql.org/June2018/#sec-Validation). - -Previous versions of `graph-node` did not support all validations and provided more graceful responses - so, in cases of ambiguity, `graph-node` was ignoring invalid GraphQL operations components. - -GraphQL Validations support is the pillar for the upcoming new features and the performance at scale of The Graph Network. - -It will also ensure determinism of query responses, a key requirement on The Graph Network. - -**Enabling the GraphQL Validations will break some existing queries** sent to The Graph API. - -To be compliant with those validations, please follow the migration guide. - -> ⚠️ If you do not migrate your queries before the validations are rolled out, they will return errors and possibly break your frontends/clients. - -## Migration guide - -You can use the CLI migration tool to find any issues in your GraphQL operations and fix them. Alternatively you can update the endpoint of your GraphQL client to use the `https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME` endpoint. Testing your queries against this endpoint will help you find the issues in your queries. - -> Not all Subgraphs will need to be migrated, if you are using [GraphQL ESlint](https://the-guild.dev/graphql/eslint/docs) or [GraphQL Code Generator](https://the-guild.dev/graphql/codegen), they already ensure that your queries are valid. - -## Migration CLI tool - -**Most of the GraphQL operations errors can be found in your codebase ahead of time.** - -For this reason, we provide a smooth experience for validating your GraphQL operations during development or in CI. - -[`@graphql-validate/cli`](https://github.com/saihaj/graphql-validate) is a simple CLI tool that helps validate GraphQL operations against a given schema. - -### **Getting started** - -You can run the tool as follows: - -```bash -npx @graphql-validate/cli -s https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME -o *.graphql -``` - -**Notes:** - -- Set or replace $GITHUB_USER, $SUBGRAPH_NAME with the appropriate values. Like: [`artblocks/art-blocks`](https://api.thegraph.com/subgraphs/name/artblocks/art-blocks) -- The preview schema URL (https://api-next.thegraph.com/) provided is heavily rate-limited and will be sunset once all users have migrated to the new version. **Do not use it in production.** -- Operations are identified in files with the following extensions [`.graphql`,](https://www.graphql-tools.com/docs/schema-loading#graphql-file-loader)[`.ts`, `.tsx`, `.js`, `jsx`](https://www.graphql-tools.com/docs/schema-loading#code-file-loader) (`-o` option). - -### CLI output - -The `[@graphql-validate/cli](https://github.com/saihaj/graphql-validate)` CLI tool will output any GraphQL operations errors as follows: - -![Error output from CLI](https://i.imgur.com/x1cBdhq.png) - -For each error, you will find a description, file path and position, and a link to a solution example (see the following section). - -## Run your local queries against the preview schema - -We provide an endpoint `https://api-next.thegraph.com/` that runs a `graph-node` version that has validations turned on. - -You can try out queries by sending them to: - -- `https://api-next.thegraph.com/subgraphs/id/` - -or - -- `https://api-next.thegraph.com/subgraphs/name//` - -To work on queries that have been flagged as having validation errors, you can use your favorite GraphQL query tool, like Altair or [GraphiQL](https://cloud.hasura.io/public/graphiql), and try your query out. Those tools will also mark those errors in their UI, even before you run it. - -## How to solve issues - -Below, you will find all the GraphQL validations errors that could occur on your existing GraphQL operations. - -### GraphQL variables, operations, fragments, or arguments must be unique - -We applied rules for ensuring that an operation includes a unique set of GraphQL variables, operations, fragments, and arguments. - -A GraphQL operation is only valid if it does not contain any ambiguity. - -To achieve that, we need to ensure that some components in your GraphQL operation must be unique. - -Here's an example of a few invalid operations that violates these rules: - -**Duplicate Query name (#UniqueOperationNamesRule)** - -```graphql -# The following operation violated the UniqueOperationName -# rule, since we have a single operation with 2 queries -# with the same name -query myData { - id -} - -query myData { - name -} -``` - -_Solution:_ - -```graphql -query myData { - id -} - -query myData2 { - # rename the second query - name -} -``` - -**Duplicate Fragment name (#UniqueFragmentNamesRule)** - -```graphql -# The following operation violated the UniqueFragmentName -# rule. -query myData { - id - ...MyFields -} - -fragment MyFields { - metadata -} - -fragment MyFields { - name -} -``` - -_Solution:_ - -```graphql -query myData { - id - ...MyFieldsName - ...MyFieldsMetadata -} - -fragment MyFieldsMetadata { # assign a unique name to fragment - metadata -} - -fragment MyFieldsName { # assign a unique name to fragment - name -} -``` - -**Duplicate variable name (#UniqueVariableNamesRule)** - -```graphql -# The following operation violates the UniqueVariables -query myData($id: String, $id: Int) { - id - ...MyFields -} -``` - -_Solution:_ - -```graphql -query myData($id: String) { - # keep the relevant variable (here: `$id: String`) - id - ...MyFields -} -``` - -**Duplicate argument name (#UniqueArgument)** - -```graphql -# The following operation violated the UniqueArguments -query myData($id: ID!) { - userById(id: $id, id: "1") { - id - } -} -``` - -_Solution:_ - -```graphql -query myData($id: ID!) { - userById(id: $id) { - id - } -} -``` - -**Duplicate anonymous query (#LoneAnonymousOperationRule)** - -Also, using two anonymous operations will violate the `LoneAnonymousOperation` rule due to conflict in the response structure: - -```graphql -# This will fail if executed together in -# a single operation with the following two queries: -query { - someField -} - -query { - otherField -} -``` - -_Solution:_ - -```graphql -query { - someField - otherField -} -``` - -Or name the two queries: - -```graphql -query FirstQuery { - someField -} - -query SecondQuery { - otherField -} -``` - -### Overlapping Fields - -A GraphQL selection set is considered valid only if it correctly resolves the eventual result set. - -If a specific selection set, or a field, creates ambiguity either by the selected field or by the arguments used, the GraphQL service will fail to validate the operation. - -Here are a few examples of invalid operations that violate this rule: - -**Conflicting fields aliases (#OverlappingFieldsCanBeMergedRule)** - -```graphql -# Aliasing fields might cause conflicts, either with -# other aliases or other fields that exist on the -# GraphQL schema. -query { - dogs { - name: nickname - name - } -} -``` - -_Solution:_ - -```graphql -query { - dogs { - name: nickname - originalName: name # alias the original `name` field - } -} -``` - -**Conflicting fields with arguments (#OverlappingFieldsCanBeMergedRule)** - -```graphql -# Different arguments might lead to different data, -# so we can't assume the fields will be the same. -query { - dogs { - doesKnowCommand(dogCommand: SIT) - doesKnowCommand(dogCommand: HEEL) - } -} -``` - -_Solution:_ - -```graphql -query { - dogs { - knowsHowToSit: doesKnowCommand(dogCommand: SIT) - knowsHowToHeel: doesKnowCommand(dogCommand: HEEL) - } -} -``` - -Also, in more complex use-cases, you might violate this rule by using two fragments that might cause a conflict in the eventually expected set: - -```graphql -query { - # Eventually, we have two "x" definitions, pointing - # to different fields! - ...A - ...B -} - -fragment A on Type { - x: a -} - -fragment B on Type { - x: b -} -``` - -In addition to that, client-side GraphQL directives like `@skip` and `@include` might lead to ambiguity, for example: - -```graphql -fragment mergeSameFieldsWithSameDirectives on Dog { - name @include(if: true) - name @include(if: false) -} -``` - -[You can read more about the algorithm here.](https://spec.graphql.org/June2018/#sec-Field-Selection-Merging) - -### Unused Variables or Fragments - -A GraphQL operation is also considered valid only if all operation-defined components (variables, fragments) are used. - -Here are a few examples for GraphQL operations that violates these rules: - -**Unused variable** (#NoUnusedVariablesRule) - -```graphql -# Invalid, because $someVar is never used. -query something($someVar: String) { - someData -} -``` - -_Solution:_ - -```graphql -query something { - someData -} -``` - -**Unused Fragment** (#NoUnusedFragmentsRule) - -```graphql -# Invalid, because fragment AllFields is never used. -query something { - someData -} - -fragment AllFields { # unused :( - name - age -} -``` - -_Solution:_ - -```graphql -# Invalid, because fragment AllFields is never used. -query something { - someData -} - -# remove the `AllFields` fragment -``` - -### Invalid or missing Selection-Set (#ScalarLeafsRule) - -Also, a GraphQL field selection is only valid if the following is validated: - -- An object field must-have selection set specified. -- An edge field (scalar, enum) must not have a selection set specified. - -Here are a few examples of violations of these rules with the following Schema: - -```graphql -type Image { - url: String! -} - -type User { - id: ID! - avatar: Image! -} - -type Query { - user: User! -} -``` - -**Invalid Selection-Set** - -```graphql -query { - user { - id { # Invalid, because "id" is of type ID and does not have sub-fields - - } - } -} -``` - -_Solution:_ - -```graphql -query { - user { - id - } -} -``` - -**Missing Selection-Set** - -```graphql -query { - user { - id - image # `image` requires a Selection-Set for sub-fields! - } -} -``` - -_Solution:_ - -```graphql -query { - user { - id - image { - src - } - } -} -``` - -### Incorrect Arguments values (#VariablesInAllowedPositionRule) - -GraphQL operations that pass hard-coded values to arguments must be valid, based on the value defined in the schema. - -Here are a few examples of invalid operations that violate these rules: - -```graphql -query purposes { - # If "name" is defined as "String" in the schema, - # this query will fail during validation. - purpose(name: 1) { - id - } -} - -# This might also happen when an incorrect variable is defined: - -query purposes($name: Int!) { - # If "name" is defined as `String` in the schema, - # this query will fail during validation, because the - # variable used is of type `Int` - purpose(name: $name) { - id - } -} -``` - -### Unknown Type, Variable, Fragment, or Directive (#UnknownX) - -The GraphQL API will raise an error if any unknown type, variable, fragment, or directive is used. - -Those unknown references must be fixed: - -- rename if it was a typo -- otherwise, remove - -### Fragment: invalid spread or definition - -**Invalid Fragment spread (#PossibleFragmentSpreadsRule)** - -A Fragment cannot be spread on a non-applicable type. - -Example, we cannot apply a `Cat` fragment to the `Dog` type: - -```graphql -query { - dog { - ...CatSimple - } -} - -fragment CatSimple on Cat { - # ... -} -``` - -**Invalid Fragment definition (#FragmentsOnCompositeTypesRule)** - -All Fragment must be defined upon (using `on ...`) a composite type, in short: object, interface, or union. - -The following examples are invalid, since defining fragments on scalars is invalid. - -```graphql -fragment fragOnScalar on Int { - # we cannot define a fragment upon a scalar (`Int`) - something -} - -fragment inlineFragOnScalar on Dog { - ... on Boolean { - # `Boolean` is not a subtype of `Dog` - somethingElse - } -} -``` - -### Directives usage - -**Directive cannot be used at this location (#KnownDirectivesRule)** - -Only GraphQL directives (`@...`) supported by The Graph API can be used. - -Here is an example with The GraphQL supported directives: - -```graphql -query { - dog { - name @include(true) - age @skip(true) - } -} -``` - -_Note: `@stream`, `@live`, `@defer` are not supported._ - -**Directive can only be used once at this location (#UniqueDirectivesPerLocationRule)** - -The directives supported by The Graph can only be used once per location. - -The following is invalid (and redundant): - -```graphql -query { - dog { - name @include(true) @include(true) - } -} -``` diff --git a/website/src/pages/en/resources/migration-guides/migrate-from-alchemy.mdx b/website/src/pages/en/resources/migration-guides/migrate-from-alchemy.mdx deleted file mode 100644 index a1e8abd436f7..000000000000 --- a/website/src/pages/en/resources/migration-guides/migrate-from-alchemy.mdx +++ /dev/null @@ -1,161 +0,0 @@ ---- -title: Migrate Your Subgraph From Alchemy to The Graph Network ---- - -Migrate or deploy an existing Subgraph to **[The Graph](https://thegraph.com/)**. - -## Why Build on The Graph? - -- **Effortless migration**: Take your existing Subgraph setup and deploy in minutes. -- **Scalable performance**: The Graph has served trillions of queries over the years. -- **Adoption that matters**: Over 12k active Subgraphs. - -The Graph created Subgraphs, now the industry standard for indexing. - -## Overview - -This guide walks you through: - -1. Preparing your environment and source code -2. Building and testing locally with **Graph Node Dev Mode (`gnd`)** -3. Deploying to [The Graph Studio](https://thegraph.com/studio/). - ---- - -## 1. Prerequisites - -You'll need: - -- Your subgraph source code (`subgraph.yaml`, `schema.graphql`, `src/mapping.ts`) -- [Node.js](https://nodejs.org), Yarn, and `graph-cli`: - ```bash - npm install -g @graphprotocol/graph-cli - ``` -- A [The Graph Studio](https://thegraph.com/studio) account and access token - ---- - -## 2. Install and Authenticate with CLI - -Install and authenticate the CLI: - -```bash -npm install -g @graphprotocol/graph-cli -graph auth -``` - ---- - -## 3. Prepare and Build Your Subgraph - -If you don't already have a project, initialize one from a contract: - -```bash -graph init --from-contract -``` - -Then build it: - -```bash -yarn codegen && yarn build -``` - ---- - -## 4. Test Locally with Subgraph Dev Mode - -`gnd` lets you run a local Graph Node instance for rapid testing—no IPFS or manual database setup required. - -### Install `gnd` - -```bash -graph node install -gnd --version -``` - -### Run Locally - -From your subgraph directory: - -```bash -gnd --ethereum-rpc mainnet:http://localhost: --watch -``` - -Query your subgraph at:\ -`http://localhost:8000/subgraphs/name/subgraph-0/` - -> On Windows, include a PostgreSQL connection string: -> -> ```bash -> gnd --ethereum-rpc mainnet:http://localhost: > --postgres-url "postgresql://graph:yourpassword@localhost:5432/graph-node" -> ``` - -**Common Flags** | Flag | Description | |------|--------------| | `--watch` | Auto-redeploy when files change | | `--postgres-url` | Required on Windows | | `--ethereum-rpc` | RPC endpoint (required) | - ---- - -## 5. Deploy to The Graph Network - -After verifying locally, deploy your subgraph to Studio: - -```bash -graph deploy --studio -``` - -This command publishes your Subgraph to The Graph Network via Studio. - ---- - -## 6. Monitor and Manage Your Deployment - -Access your Subgraph dashboard to view logs, indexing progress, and query endpoints: - -**Dashboard:**\ -`https://thegraph.com/studio/` - ---- - -## 7. Update Your Application - -Your subgraph's GraphQL endpoint follows this format: - -``` -https://api.studio.thegraph.com/query/{user_id}/{subgraph_slug}/{version} -``` - -**Example:** - -``` -https://api.studio.thegraph.com/query/1234/my-subgraph/v1.0.0 -``` - -Replace your old endpoint with this one in your dApp or backend configuration. - ---- - -## 8. Verify Your Deployment - -Run a quick test query: - -```graphql -{ - transfers(first: 5) { - id - from - to - value - } -} -``` - -Ensure results match your expectations. - ---- - -## 9. Next Steps - -- [Monitor your subgraphs in Studio →](https://thegraph.com/studio) -- [Join The Graph community →](https://discord.gg/graphprotocol) - -> Learn more about **Graph Node Dev Mode** →\ -> [https://thegraph.com/docs/en/subgraphs/developing/creating/graph-node-dev/](https://thegraph.com/docs/en/subgraphs/developing/creating/graph-node-dev/) diff --git a/website/src/pages/en/resources/roles/curating.mdx b/website/src/pages/en/resources/roles/curating.mdx index a228ebfb3267..8a38711e8d61 100644 --- a/website/src/pages/en/resources/roles/curating.mdx +++ b/website/src/pages/en/resources/roles/curating.mdx @@ -12,7 +12,7 @@ Curators make The Graph network efficient and [signaling](#how-to-signal) is the Curator signals are represented as ERC20 tokens called Graph Curation Shares (GCS). Those that want to earn more query fees should signal their GRT to Subgraphs that they predict will generate a strong flow of fees to the network. Curators cannot be slashed for bad behavior, but there is a deposit tax on Curators to disincentivize poor decision-making that could harm the integrity of the network. Curators will also earn fewer query fees if they curate on a low-quality Subgraph because there will be fewer queries to process or fewer Indexers to process them. -The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all Subgraphs, signaling GRT on a particular Subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability. +The Sunrise Upgrade Indexer ensures the indexing of all Subgraphs, signaling GRT on a particular Subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability. When signaling, Curators can decide to signal on a specific version of the Subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version. @@ -24,7 +24,7 @@ Indexers can find Subgraphs to index based on curation signals they see in Graph ## How to Signal -Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain Subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/) +Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain Subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/existing-subgraphs/explorer/) A curator can choose to signal on a specific Subgraph version, or they can choose to have their signal automatically migrate to the newest production build of that Subgraph. Both are valid strategies and come with their own pros and cons. diff --git a/website/src/pages/en/resources/tokenomics.mdx b/website/src/pages/en/resources/tokenomics.mdx index 9b62872b41d5..b748f80dd6e0 100644 --- a/website/src/pages/en/resources/tokenomics.mdx +++ b/website/src/pages/en/resources/tokenomics.mdx @@ -12,7 +12,7 @@ The Graph is a decentralized protocol that enables easy access to blockchain dat The Graph's model is akin to a B2B2C model, but it's driven by a decentralized network where participants collaborate to provide data to end users in exchange for GRT rewards. GRT is the utility token for The Graph. It coordinates and incentivizes the interaction between data providers and consumers within the network. -The Graph plays a vital role in making blockchain data more accessible and supports a marketplace for its exchange. To learn more about The Graph's pay-for-what-you-need model, check out its [free and growth plans](/subgraphs/billing/). +The Graph plays a vital role in making blockchain data more accessible and supports a marketplace for its exchange. To learn more about The Graph's pay-for-what-you-need model, check out its [free and growth plans](/subgraphs/providers/subgraph-studio/introduction/). - GRT Token Address on Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7) @@ -60,11 +60,11 @@ Developers build and query Subgraphs to retrieve blockchain data. Since Subgraph Developers can [create a Subgraph](/developing/creating-a-subgraph/) to index data on the blockchain. Subgraphs are instructions for Indexers about which data should be served to consumers. -Once developers have built and tested their Subgraph, they can [publish their Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/) on The Graph's decentralized network. +Once developers have built and tested their Subgraph, they can [publish their Subgraph](/subgraphs/developing/deploying-publishing/publishing-a-subgraph/) on The Graph's decentralized network. ### Querying an existing Subgraph -Once a Subgraph is [published](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph's decentralized network, anyone can create an API key, add GRT to their billing balance, and query the Subgraph. +Once a Subgraph is [published](/subgraphs/developing/deploying-publishing/publishing-a-subgraph/) to The Graph's decentralized network, anyone can create an API key, add GRT to their billing balance, and query the Subgraph. Subgraphs are [queried using GraphQL](/subgraphs/querying/introduction/), and the query fees are paid for with GRT in [Subgraph Studio](https://thegraph.com/studio/). Query fees are distributed to network participants based on their contributions to the protocol. diff --git a/website/src/pages/en/subgraphs/_meta-titles.json b/website/src/pages/en/subgraphs/_meta-titles.json index 6643385de383..c9cd8f4959cc 100644 --- a/website/src/pages/en/subgraphs/_meta-titles.json +++ b/website/src/pages/en/subgraphs/_meta-titles.json @@ -1,7 +1,9 @@ { - "subgraph-mcp": "Subgraph MCP", + "existing-subgraphs": "Public Subgraphs", + "providers": "Providers", "querying": "Querying", "developing": "Developing", "guides": "How-to Guides", - "best-practices": "Best Practices" + "best-practices": "Best Practices", + "tooling": "Tooling" } diff --git a/website/src/pages/en/subgraphs/_meta.js b/website/src/pages/en/subgraphs/_meta.js index e76cc5491aeb..cbad796477b8 100644 --- a/website/src/pages/en/subgraphs/_meta.js +++ b/website/src/pages/en/subgraphs/_meta.js @@ -1,15 +1,13 @@ import titles from './_meta-titles.json' export default { + overview: '', 'quick-start': '', - explorer: '', - querying: titles.querying ?? '', + providers: titles.providers ?? '', + 'existing-subgraphs': titles['existing-subgraphs'] ?? '', developing: titles.developing ?? '', - billing: '', - guides: titles.guides ?? '', + querying: titles.querying ?? '', + tooling: titles.tooling ?? '', 'best-practices': titles['best-practices'] ?? '', - 'fair-use-policy': '', - 'upgrade-indexer': '', - skills: '', - 'subgraph-mcp': titles['subgraph-mcp'] ?? '', + guides: titles.guides ?? '', } diff --git a/website/src/pages/en/subgraphs/best-practices/_meta.js b/website/src/pages/en/subgraphs/best-practices/_meta.js index fab0571f4d0c..361d05d987ea 100644 --- a/website/src/pages/en/subgraphs/best-practices/_meta.js +++ b/website/src/pages/en/subgraphs/best-practices/_meta.js @@ -1,7 +1,7 @@ export default { - pruning: '', - derivedfrom: '', 'immutable-entities-bytes-as-ids': '', + derivedfrom: '', + pruning: '', 'avoid-eth-calls': '', timeseries: '', 'grafting-hotfix': '', diff --git a/website/src/pages/en/subgraphs/developing/_meta-titles.json b/website/src/pages/en/subgraphs/developing/_meta-titles.json index 01a91b09ed77..0e27c952055a 100644 --- a/website/src/pages/en/subgraphs/developing/_meta-titles.json +++ b/website/src/pages/en/subgraphs/developing/_meta-titles.json @@ -1,6 +1,5 @@ { "creating": "Creating", - "deploying": "Deploying", - "publishing": "Publishing", + "deploying-publishing": "Deploying/Publishing", "managing": "Managing" } diff --git a/website/src/pages/en/subgraphs/developing/_meta.js b/website/src/pages/en/subgraphs/developing/_meta.js index 51ad1ee1f5f9..99e41e791623 100644 --- a/website/src/pages/en/subgraphs/developing/_meta.js +++ b/website/src/pages/en/subgraphs/developing/_meta.js @@ -2,10 +2,8 @@ import titles from './_meta-titles.json' export default { introduction: '', - subgraphs: '', creating: titles.creating ?? '', - deploying: titles.deploying ?? '', - publishing: titles.publishing ?? '', + 'deploying-publishing': titles['deploying-publishing'] ?? '', managing: titles.managing ?? '', - 'developer-faq': '', + 'developer-faq': 'Developer FAQ', } diff --git a/website/src/pages/en/subgraphs/developing/creating/_meta.js b/website/src/pages/en/subgraphs/developing/creating/_meta.js index fba73e37424c..58b91d816f12 100644 --- a/website/src/pages/en/subgraphs/developing/creating/_meta.js +++ b/website/src/pages/en/subgraphs/developing/creating/_meta.js @@ -2,12 +2,11 @@ import titles from './_meta-titles.json' export default { 'starting-your-subgraph': '', - 'install-the-cli': '', + 'install-the-cli': 'Graph CLI', 'subgraph-manifest': '', - 'ql-schema': '', - 'assemblyscript-mappings': '', - 'graph-node-dev': '', - advanced: '', + 'ql-schema': 'GraphQL Schema', + 'assemblyscript-mappings': 'AssemblyScript Mappings', 'graph-ts': titles['graph-ts'] ?? '', - 'unit-testing-framework': '', + 'graph-node-dev': 'Local Dev Mode', + advanced: 'Advanced Features', } diff --git a/website/src/pages/en/subgraphs/developing/creating/graph-ts/api.mdx b/website/src/pages/en/subgraphs/developing/creating/graph-ts/api.mdx index 447c13b33bb3..34dcb2b318b9 100644 --- a/website/src/pages/en/subgraphs/developing/creating/graph-ts/api.mdx +++ b/website/src/pages/en/subgraphs/developing/creating/graph-ts/api.mdx @@ -2,7 +2,7 @@ title: AssemblyScript API --- -> Note: If you created a Subgraph prior to `graph-cli`/`graph-ts` version `0.22.0`, then you're using an older version of AssemblyScript. It is recommended to review the [`Migration Guide`](/resources/migration-guides/assemblyscript-migration-guide/). +> Note: If you created a Subgraph prior to `graph-cli`/`graph-ts` version `0.22.0`, then you're using an older version of AssemblyScript. It is recommended to review the `Migration Guide`. Learn what built-in APIs can be used when writing Subgraph mappings. There are two kinds of APIs available out of the box: @@ -35,7 +35,7 @@ The `apiVersion` in the Subgraph manifest specifies the mapping API version whic | 0.0.8 | Adds validation for existence of fields in the schema when saving an entity. | | 0.0.7 | Added `TransactionReceipt` and `Log` classes to the Ethereum types
Added `receipt` field to the Ethereum Event object | | 0.0.6 | Added `nonce` field to the Ethereum Transaction object
Added `baseFeePerGas` to the Ethereum Block object | -| 0.0.5 | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/resources/migration-guides/assemblyscript-migration-guide/))
`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` | +| 0.0.5 | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the `Migration Guide`)
`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` | | 0.0.4 | Added `functionSignature` field to the Ethereum SmartContractCall object | | 0.0.3 | Added `from` field to the Ethereum Call object
`ethereum.call.address` renamed to `ethereum.call.to` | | 0.0.2 | Added `input` field to the Ethereum Transaction object | diff --git a/website/src/pages/en/subgraphs/developing/creating/install-the-cli.mdx b/website/src/pages/en/subgraphs/developing/creating/install-the-cli.mdx index eeb82acd8c98..8f313d2540ac 100644 --- a/website/src/pages/en/subgraphs/developing/creating/install-the-cli.mdx +++ b/website/src/pages/en/subgraphs/developing/creating/install-the-cli.mdx @@ -2,7 +2,7 @@ title: Install the Graph CLI --- -> In order to use your Subgraph on The Graph's decentralized network, you will need to [create an API key](/resources/subgraph-studio-faq/#2-how-do-i-create-an-api-key) in [Subgraph Studio](https://thegraph.com/studio/apikeys/). It is recommended that you add signal to your Subgraph with at least 3,000 GRT to attract 2-3 Indexers. To learn more about signaling, check out [curating](/resources/roles/curating/). +> In order to use your Subgraph on The Graph's decentralized network, you will need to [create an API key](/subgraphs/providers/subgraph-studio/studio-faq/#2-how-do-i-create-an-api-key) in [Subgraph Studio](https://thegraph.com/studio/apikeys/). It is recommended that you add signal to your Subgraph with at least 3,000 GRT to attract 2-3 Indexers. To learn more about signaling, check out [curating](/resources/roles/curating/). ## Overview diff --git a/website/src/pages/en/subgraphs/developing/creating/starting-your-subgraph.mdx b/website/src/pages/en/subgraphs/developing/creating/starting-your-subgraph.mdx index 180a343470b1..726af8e3514c 100644 --- a/website/src/pages/en/subgraphs/developing/creating/starting-your-subgraph.mdx +++ b/website/src/pages/en/subgraphs/developing/creating/starting-your-subgraph.mdx @@ -6,7 +6,7 @@ title: Starting Your Subgraph The Graph is home to thousands of Subgraphs already available for query, so check [The Graph Explorer](https://thegraph.com/explorer) and find one that already matches your needs. -When you create a [Subgraph](/subgraphs/developing/subgraphs/), you create a custom open API that extracts data from a blockchain, processes it, stores it, and makes it easy to query via GraphQL. +When you create a [Subgraph](/subgraphs/overview/), you create a custom open API that extracts data from a blockchain, processes it, stores it, and makes it easy to query via GraphQL. Subgraph development ranges from simple scaffold Subgraphs to advanced, specifically tailored Subgraphs. @@ -20,7 +20,7 @@ Start the process and build a Subgraph that matches your needs: 4. [Writing AssemblyScript Mappings](/subgraphs/developing/creating/assemblyscript-mappings/) - Write your mappings 5. [Advanced Features](/subgraphs/developing/creating/advanced/) - Customize your Subgraph with advanced features -Explore additional [resources for APIs](/subgraphs/developing/creating/graph-ts/README/) and conduct local testing with [Matchstick](/subgraphs/developing/creating/unit-testing-framework/). +Explore additional [resources for APIs](/subgraphs/developing/creating/graph-ts/README/) and conduct local testing with [Matchstick](/subgraphs/tooling/unit-testing-framework/). | Version | Release notes | | :-: | --- | diff --git a/website/src/pages/en/subgraphs/developing/deploying/_meta.js b/website/src/pages/en/subgraphs/developing/deploying-publishing/_meta.js similarity index 61% rename from website/src/pages/en/subgraphs/developing/deploying/_meta.js rename to website/src/pages/en/subgraphs/developing/deploying-publishing/_meta.js index cb7ed6c18bcc..695952854521 100644 --- a/website/src/pages/en/subgraphs/developing/deploying/_meta.js +++ b/website/src/pages/en/subgraphs/developing/deploying-publishing/_meta.js @@ -1,4 +1,5 @@ export default { 'using-subgraph-studio': '', 'multiple-networks': '', + 'publishing-a-subgraph': 'Publish to Network', } diff --git a/website/src/pages/en/subgraphs/developing/deploying/multiple-networks.mdx b/website/src/pages/en/subgraphs/developing/deploying-publishing/multiple-networks.mdx similarity index 99% rename from website/src/pages/en/subgraphs/developing/deploying/multiple-networks.mdx rename to website/src/pages/en/subgraphs/developing/deploying-publishing/multiple-networks.mdx index 5c8016b18c91..f2b041568734 100644 --- a/website/src/pages/en/subgraphs/developing/deploying/multiple-networks.mdx +++ b/website/src/pages/en/subgraphs/developing/deploying-publishing/multiple-networks.mdx @@ -1,6 +1,6 @@ --- title: Deploying a Subgraph to Multiple Networks -sidebarTitle: Deploying to Multiple Networks +sidebarTitle: Deploy to Multiple Networks --- This page explains how to deploy a Subgraph to multiple networks. To deploy a Subgraph you need to first install the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli). If you have not created a Subgraph already, see [Creating a Subgraph](/developing/creating-a-subgraph/). diff --git a/website/src/pages/en/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/src/pages/en/subgraphs/developing/deploying-publishing/publishing-a-subgraph.mdx similarity index 89% rename from website/src/pages/en/subgraphs/developing/publishing/publishing-a-subgraph.mdx rename to website/src/pages/en/subgraphs/developing/deploying-publishing/publishing-a-subgraph.mdx index acb211f2c9f1..8f8ebe5dfc10 100644 --- a/website/src/pages/en/subgraphs/developing/publishing/publishing-a-subgraph.mdx +++ b/website/src/pages/en/subgraphs/developing/deploying-publishing/publishing-a-subgraph.mdx @@ -1,6 +1,6 @@ --- title: Publishing a Subgraph to the Decentralized Network -sidebarTitle: Publishing to the Decentralized Network +sidebarTitle: Publish to the Network --- Once you have [deployed your Subgraph to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/) and it's ready to go into production, you can publish it to the decentralized network. @@ -22,7 +22,7 @@ Check out the list of [supported networks](/supported-networks/). All published versions of an existing Subgraph can: -- Be published to Arbitrum One. [Learn more about The Graph Network on Arbitrum](/archived/arbitrum/arbitrum-faq/). +- Be published to Arbitrum One. Learn more about The Graph Network on Arbitrum. - Index data on any of the [supported networks](/supported-networks/), regardless of the network on which the Subgraph was published. @@ -76,7 +76,7 @@ Developers can add GRT signal to their Subgraphs to incentivize Indexers to quer > If your Subgraph is eligible for rewards, it is recommended that you curate your own Subgraph with at least 3,000 GRT in order to attract additional indexers to index your Subgraph. -The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all Subgraphs. However, signaling GRT on a particular Subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability. +The Sunrise Upgrade Indexer ensures the indexing of all Subgraphs. However, signaling GRT on a particular Subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability. When signaling, Curators can decide to signal on a specific version of the Subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version. diff --git a/website/src/pages/en/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/src/pages/en/subgraphs/developing/deploying-publishing/using-subgraph-studio.mdx similarity index 98% rename from website/src/pages/en/subgraphs/developing/deploying/using-subgraph-studio.mdx rename to website/src/pages/en/subgraphs/developing/deploying-publishing/using-subgraph-studio.mdx index eb6626f4c98c..0a36420cc10c 100644 --- a/website/src/pages/en/subgraphs/developing/deploying/using-subgraph-studio.mdx +++ b/website/src/pages/en/subgraphs/developing/deploying-publishing/using-subgraph-studio.mdx @@ -1,5 +1,6 @@ --- title: Deploying Using Subgraph Studio +sidebarTitle: Deploy to Studio --- Learn how to deploy your Subgraph to Subgraph Studio. @@ -112,7 +113,7 @@ Use Subgraph Studio to check the logs on the dashboard and look for any errors w ## Publish Your Subgraph -In order to publish your Subgraph successfully, review [publishing a Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/). +In order to publish your Subgraph successfully, review [publishing a Subgraph](/subgraphs/developing/deploying-publishing/publishing-a-subgraph/). ## Versioning Your Subgraph with the CLI diff --git a/website/src/pages/en/subgraphs/developing/introduction.mdx b/website/src/pages/en/subgraphs/developing/introduction.mdx index 2e313eed8924..a696b1093180 100644 --- a/website/src/pages/en/subgraphs/developing/introduction.mdx +++ b/website/src/pages/en/subgraphs/developing/introduction.mdx @@ -28,4 +28,4 @@ On The Graph, you can: A Subgraph is a custom API built on blockchain data. It extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL. -Check out the documentation on [Subgraphs](/subgraphs/developing/subgraphs/) to learn specifics. +Check out the documentation on [Subgraphs](/subgraphs/overview/) to learn specifics. diff --git a/website/src/pages/en/subgraphs/developing/publishing/_meta.js b/website/src/pages/en/subgraphs/developing/publishing/_meta.js deleted file mode 100644 index 956339c6b49e..000000000000 --- a/website/src/pages/en/subgraphs/developing/publishing/_meta.js +++ /dev/null @@ -1,3 +0,0 @@ -export default { - 'publishing-a-subgraph': '', -} diff --git a/website/src/pages/en/subgraphs/existing-subgraphs/_meta.js b/website/src/pages/en/subgraphs/existing-subgraphs/_meta.js new file mode 100644 index 000000000000..d6e28b2730b9 --- /dev/null +++ b/website/src/pages/en/subgraphs/existing-subgraphs/_meta.js @@ -0,0 +1,6 @@ +export default { + explorer: 'Using Graph Explorer', + 'standard-subgraphs': 'Standardized Subgraphs', + agent0: 'Agent0 Subgraphs', + polymarket: 'Polymarket Subgraphs', +} diff --git a/website/src/pages/en/subgraphs/guides/agent0.mdx b/website/src/pages/en/subgraphs/existing-subgraphs/agent0.mdx similarity index 100% rename from website/src/pages/en/subgraphs/guides/agent0.mdx rename to website/src/pages/en/subgraphs/existing-subgraphs/agent0.mdx diff --git a/website/src/pages/en/subgraphs/explorer.mdx b/website/src/pages/en/subgraphs/existing-subgraphs/explorer.mdx similarity index 98% rename from website/src/pages/en/subgraphs/explorer.mdx rename to website/src/pages/en/subgraphs/existing-subgraphs/explorer.mdx index facd8bb2bad5..6000bd877ee0 100644 --- a/website/src/pages/en/subgraphs/explorer.mdx +++ b/website/src/pages/en/subgraphs/existing-subgraphs/explorer.mdx @@ -1,5 +1,5 @@ --- -title: Graph Explorer +title: Using Graph Explorer to Find Public Subgraphs --- Use [Graph Explorer](https://thegraph.com/explorer) and take full advantage of its core features. @@ -15,13 +15,13 @@ This guide explains how to use [Graph Explorer](https://thegraph.com/explorer) t - To perform actions, you need a wallet (e.g., MetaMask) connected to [Graph Explorer](https://thegraph.com/explorer). > Make sure your wallet is connected to the correct network (e.g., Arbitrum). Features and data shown are network specific. - GRT tokens if you plan to delegate or curate. -- Basic knowledge of [Subgraphs](/subgraphs/developing/subgraphs/) +- Basic knowledge of [Subgraphs](/subgraphs/overview/) ## Navigating Graph Explorer ### Step 1. Explore Subgraphs -> For additional support, you can watch the [Graph Explorer video guide](/subgraphs/explorer/#video-guide). +> For additional support, you can watch the [Graph Explorer video guide](/subgraphs/existing-subgraphs/explorer/#video-guide). Go to the Subgraphs page in [Graph Explorer](https://thegraph.com/explorer). diff --git a/website/src/pages/en/subgraphs/guides/polymarket.mdx b/website/src/pages/en/subgraphs/existing-subgraphs/polymarket.mdx similarity index 100% rename from website/src/pages/en/subgraphs/guides/polymarket.mdx rename to website/src/pages/en/subgraphs/existing-subgraphs/polymarket.mdx diff --git a/website/src/pages/en/subgraphs/existing-subgraphs/standard-subgraphs.mdx b/website/src/pages/en/subgraphs/existing-subgraphs/standard-subgraphs.mdx new file mode 100644 index 000000000000..ec804d9382b8 --- /dev/null +++ b/website/src/pages/en/subgraphs/existing-subgraphs/standard-subgraphs.mdx @@ -0,0 +1,68 @@ +--- +title: Standardized Subgraphs +--- + +## Overview + +**Standardized Subgraphs** are a family of open, reusable GraphQL schemas that normalize on-chain data across every protocol of the same type. Rather than each protocol exposing its own bespoke schema with its own terminology, every Subgraph built to a standard exposes the *same* entities, fields, and metrics, so a single set of queries works across all of them. + +The most widely adopted set of these schemas was created by [Messari](https://messari.io/), the core subgraph dev that builds and maintains standardized schemas for the major DeFi and web3 protocol categories on top of The Graph. Each schema extracts raw blockchain data and transforms it into meaningful, comparable metrics for products and analytics. + +> A standardized schema is a base contract, not a ceiling. Individual Subgraphs can add protocol-specific entities and fields on top of the standard, but the base is guaranteed, so downstream consumers can always rely on it. + +## Why Standardize + +**One set of queries for every protocol.** Every protocol has slightly different terminology and definitions, which makes it hard to make sense of their data. Because Standardized Subgraphs normalize all data the same way, you only need a single set of queries (or a single data pipeline) to pull data from every supported protocol of a given type. Comparing TVL across ten lending markets, or revenue across every DEX, becomes a single query pattern instead of ten integrations. + +**Normalized, comparable metrics.** Financial concepts like total revenue, supply-side revenue, protocol-side revenue, and total value locked are defined once and computed the same way everywhere. This saves consumers an enormous amount of reconciliation work and makes cross-protocol analytics trustworthy. + +**A battle-tested starting point for developers.** Designing a Subgraph schema from scratch is daunting; there are many edge cases and nuances to consider. The standardized schemas are battle-tested across a large set of production Subgraph implementations, which makes them an excellent foundation for any new Subgraph. Developers also inherit a library of reference implementations, shared common libraries, and validation tooling. + +**Predictable versioning.** Schemas follow [semantic versioning](https://semver.org/) strictly, and each Subgraph embeds three separate version fields on its `Protocol` entity so different stakeholders can track what they care about: + +| Field | Who it's for | What it tracks | +| -------------------- | ------------------- | ------------------------------------------------------------------------------ | +| `schemaVersion` | Data consumers | Which version of the shared schema the Subgraph implements; signals breaking changes. | +| `subgraphVersion` | subgraph developers | The implementation version; refactors bump this with no impact on consumers. | +| `methodologyVersion` | Data consumers | How metrics are calculated, so consumers can diff against methodology changes. | + +## The Schemas + +The standardized schemas each cover one protocol category. Every schema shares a common backbone (`Token`, `Protocol`, pools or markets, daily and hourly snapshots for time-series data, and standardized revenue and usage metrics) while adding the entities specific to its domain. + +| Schema | Version | What it covers | +| ------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------- | +| **Generic** | 3.0.0 | The base template that all schemas build on. Defines `Token`, `Protocol`, `Pool`, `Account`, and the standard usage and financial snapshots. A good fit for protocols that don't map cleanly onto a more specific category. | +| **DEX AMM** | 1.3.2 | Automated market maker exchanges. Models `LiquidityPool`, `Swap`, `Deposit`, and `Withdraw` events, pool fees, and reward tokens. | +| **DEX AMM (Extended)** | 4.0.1 | AMMs with concentrated liquidity (e.g. Uniswap v3). Adds `Tick`, `Position`, and `PositionSnapshot` entities on top of the DEX AMM model. | +| **DEX Aggregator** | 1.0.2 | Trade aggregators that route across venues. Models `VirtualPool`, per-token daily snapshots, and `Swap` activity. | +| **Lending / CDP** | 3.1.0 | Lending, borrowing, and collateralized debt position protocols. Models `Market`, `Position`, `InterestRate`, and the full set of lending events: `Deposit`, `Withdraw`, `Borrow`, `Repay`, `Liquidate`, `Transfer`, and `Flashloan`. | +| **Yield Aggregator** | 1.3.1 | Vaults and yield optimizers. Models `Vault`, `VaultFee`, `Deposit`, and `Withdraw`, with reward-token accounting. | +| **NFT Marketplace** | 2.1.0 | NFT trading venues. Models `Marketplace`, `Collection`, and `Trade`, with support for multiple NFT standards and sale strategies. | +| **Network** | 1.2.0 | Layer-1 and layer-2 chain-level metrics. Models `Block`, `Author`, and `Chunk` with network-wide daily and hourly stats. | +| **Bridge** | 1.2.0 | Cross-chain bridges. Models `Pool`, `PoolRoute`, `CrosschainToken`, `BridgeTransfer`, and `BridgeMessage` to track liquidity and value moving across chains. | +| **Derivatives (Perpetual Futures)** | 1.3.4 | Perpetual futures venues. Models `LiquidityPool`, `Position`, `CollateralIn` and `CollateralOut`, `Borrow`, `Swap`, and `Liquidate`. | +| **Derivatives (Options)** | 1.3.2 | On-chain options protocols. Models `LiquidityPool`, `Position`, and `Option`, with call and put option typing. | + +## Shared Design Principles + +Because the schemas are meant to be consumed the same way regardless of protocol, they follow a consistent set of conventions. + +**Three ways to read quantitative data.** You can query an entity directly for *real-time* values (e.g. `totalValueLockedUSD` on a `Pool`), use [time-travel queries](https://thegraph.com/docs/en/subgraphs/querying/graphql-api/#time-travel-queries) for *point-in-time* historical values, or query the snapshot entities for *time-series* data (e.g. `PoolDailySnapshot`). + +**Standardized financial metrics.** Revenue is split consistently across every schema: + +- **Total Revenue**: all revenue generated by the protocol (e.g. the full swap fee on a DEX, all yield generated by a vault). +- **Supply-Side Revenue**: the portion paid to suppliers, such as LPs on DEXs, depositors on lending protocols, and sellers on NFT marketplaces. +- **Protocol-Side Revenue**: the portion claimed by the protocol itself (e.g. the protocol's cut of a swap fee, or a marketplace's sell fee). + +**Consistent naming and typing.** Token amounts are stored as `BigInt` to preserve precision (in wei), USD amounts and prices as `BigDecimal`, and rates as percentage `BigDecimal` values (70.5% is stored as `70.5`). Field prefixes carry meaning: `cumulative*` is the running sum since day one, `daily*` and `hourly*` apply to snapshot intervals, and unprefixed quantitative fields are spot values as of now. + +**Predictable IDs and usage definitions.** Entity IDs are derived from addresses, transaction hashes, and log indexes in documented ways, and "usage" is defined consistently: external user actions like swaps, deposits, and borrows count, while internal protocol actions, governance votes, and failed transactions do not. + +## Next Steps + +- Browse the standardized schemas and reference implementations in the [Messari Subgraphs repository](https://github.com/messari/subgraphs). +- Read the full [schema documentation](https://github.com/messari/subgraphs/blob/master/docs/SCHEMA.md) for naming conventions, versioning, and entity design. +- Learn how to [query a Subgraph](https://thegraph.com/docs/en/subgraphs/querying/introduction/) with the GraphQL API. +- New to Subgraphs? Start with [Developing a Subgraph](https://thegraph.com/docs/en/subgraphs/developing/introduction/). diff --git a/website/src/pages/en/subgraphs/guides/_meta.js b/website/src/pages/en/subgraphs/guides/_meta.js index cadb6a5fe392..385bc230b75d 100644 --- a/website/src/pages/en/subgraphs/guides/_meta.js +++ b/website/src/pages/en/subgraphs/guides/_meta.js @@ -1,15 +1,9 @@ export default { - 'subgraph-composition': '', - 'subgraph-debug-forking': '', - near: '', - grafting: '', - 'subgraph-linter': '', - 'subgraph-uncrashable': '', - 'transfer-to-the-graph': '', - enums: '', - 'secure-api-keys-nextjs': '', - polymarket: '', - agent0: '', - 'x402-payments': '', - 'contract-analyzer': '', + 'transfer-to-the-graph': 'Transfer to The Graph', + grafting: 'Subgraph Grafting', + 'subgraph-debug-forking': 'Subgraph Forking', + 'subgraph-composition': 'Composable Subgraphs', + enums: 'Using Enums', + 'secure-api-keys-nextjs': 'Securing API Keys with Next.js', + near: 'NEAR Subgraphs', } diff --git a/website/src/pages/en/subgraphs/guides/secure-api-keys-nextjs.mdx b/website/src/pages/en/subgraphs/guides/secure-api-keys-nextjs.mdx index e17e594408ff..d9fda08a321c 100644 --- a/website/src/pages/en/subgraphs/guides/secure-api-keys-nextjs.mdx +++ b/website/src/pages/en/subgraphs/guides/secure-api-keys-nextjs.mdx @@ -120,4 +120,4 @@ Start our Next.js application using `npm run dev`. Verify that the server compon ### Conclusion -By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further. +By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/providers/subgraph-studio/managing-api-keys/) to increase your API key security even further. diff --git a/website/src/pages/en/subgraphs/developing/subgraphs.mdx b/website/src/pages/en/subgraphs/overview.mdx similarity index 90% rename from website/src/pages/en/subgraphs/developing/subgraphs.mdx rename to website/src/pages/en/subgraphs/overview.mdx index b5a75a88e94f..389d7ba4e12b 100644 --- a/website/src/pages/en/subgraphs/developing/subgraphs.mdx +++ b/website/src/pages/en/subgraphs/overview.mdx @@ -1,5 +1,6 @@ --- title: Subgraphs +sidebarTitle: Overview --- ## What is a Subgraph? @@ -37,12 +38,12 @@ Here is a general overview of a Subgraph’s lifecycle: 1. [Create a Subgraph](/developing/creating-a-subgraph/) 2. [Deploy a Subgraph](/deploying/deploying-a-subgraph-to-studio/) 3. [Test a Subgraph](/deploying/subgraph-studio/#testing-your-subgraph-in-subgraph-studio) -4. [Publish a Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/) -5. [Signal on a Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph) +4. [Publish a Subgraph](/subgraphs/developing/deploying-publishing/publishing-a-subgraph/) +5. [Signal on a Subgraph](/subgraphs/developing/deploying-publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph) ### Build locally -Great Subgraphs start with a local development environment and unit tests. Developers use [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli), a command-line interface tool for building and deploying Subgraphs on The Graph. They can also use [Graph TypeScript](/subgraphs/developing/creating/graph-ts/README/) and [Matchstick](/subgraphs/developing/creating/unit-testing-framework/) to create robust Subgraphs. +Great Subgraphs start with a local development environment and unit tests. Developers use [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli), a command-line interface tool for building and deploying Subgraphs on The Graph. They can also use [Graph TypeScript](/subgraphs/developing/creating/graph-ts/README/) and [Matchstick](/subgraphs/tooling/unit-testing-framework/) to create robust Subgraphs. ### Deploy to Subgraph Studio @@ -53,7 +54,7 @@ Once defined, a Subgraph can be [deployed to Subgraph Studio](/deploying/deployi ### Publish to the Network -When you're happy with your Subgraph, you can [publish it](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph Network. +When you're happy with your Subgraph, you can [publish it](/subgraphs/developing/deploying-publishing/publishing-a-subgraph/) to The Graph Network. - This is an onchain action, which registers the Subgraph and makes it discoverable by Indexers. - Published Subgraphs have a corresponding NFT, which defines the ownership of the Subgraph. You can [transfer the Subgraph's ownership](/subgraphs/developing/managing/transferring-a-subgraph/) by sending the NFT. @@ -70,7 +71,7 @@ Published Subgraphs are unlikely to be picked up by Indexers without curation si ### Querying & Application Development -Subgraphs on The Graph Network receive 100,000 free queries per month, after which point developers can either [pay for queries with GRT or a credit card](/subgraphs/billing/). +Subgraphs on The Graph Network receive 100,000 free queries per month, after which point developers can either [pay for queries with GRT or a credit card](/subgraphs/providers/subgraph-studio/introduction/). Learn more about [querying Subgraphs](/subgraphs/querying/introduction/). diff --git a/website/src/pages/en/subgraphs/providers/_meta-titles.json b/website/src/pages/en/subgraphs/providers/_meta-titles.json new file mode 100644 index 000000000000..a7160d70704d --- /dev/null +++ b/website/src/pages/en/subgraphs/providers/_meta-titles.json @@ -0,0 +1,3 @@ +{ + "subgraph-studio": "Subgraph Studio" +} diff --git a/website/src/pages/en/archived/_meta.js b/website/src/pages/en/subgraphs/providers/_meta.js similarity index 53% rename from website/src/pages/en/archived/_meta.js rename to website/src/pages/en/subgraphs/providers/_meta.js index dca32f8a186b..2937129db190 100644 --- a/website/src/pages/en/archived/_meta.js +++ b/website/src/pages/en/subgraphs/providers/_meta.js @@ -1,6 +1,5 @@ import titles from './_meta-titles.json' export default { - sunrise: '', - arbitrum: titles.arbitrum ?? '', + 'subgraph-studio': titles['subgraph-studio'] ?? '', } diff --git a/website/src/pages/en/subgraphs/providers/subgraph-studio/_meta.js b/website/src/pages/en/subgraphs/providers/subgraph-studio/_meta.js new file mode 100644 index 000000000000..717dd623b53c --- /dev/null +++ b/website/src/pages/en/subgraphs/providers/subgraph-studio/_meta.js @@ -0,0 +1,7 @@ +export default { + introduction: '', + 'managing-api-keys': 'Managing API Keys', + 'upgrade-indexer': '', + 'fair-use-policy': '', + 'studio-faq': '', +} diff --git a/website/src/pages/en/subgraphs/fair-use-policy.mdx b/website/src/pages/en/subgraphs/providers/subgraph-studio/fair-use-policy.mdx similarity index 87% rename from website/src/pages/en/subgraphs/fair-use-policy.mdx rename to website/src/pages/en/subgraphs/providers/subgraph-studio/fair-use-policy.mdx index c8c841b28577..1298007bf113 100644 --- a/website/src/pages/en/subgraphs/fair-use-policy.mdx +++ b/website/src/pages/en/subgraphs/providers/subgraph-studio/fair-use-policy.mdx @@ -6,7 +6,7 @@ title: Fair Use Policy ## Overview -This page outlines the fair usage of [Edge & Node's Upgrade Indexer](/subgraphs/upgrade-indexer/). This policy is designed to ensure the efficient use of queries and storage across the free-tier community. +This page outlines the fair usage of [Edge & Node's Upgrade Indexer](/subgraphs/providers/subgraph-studio/upgrade-indexer/). This policy is designed to ensure the efficient use of queries and storage across the free-tier community. Storage limits, sync thresholds, and usage requirements are explained below. Users who exceed specified limits will need to advance to a paid plan. @@ -44,7 +44,7 @@ The Edge & Node Support Team reserves the right to revise fair limits or impose If you exceed your fair use limits, you will receive an email alert giving you a grace period of **7 days** to take action. Here are some options: - Try [pruning Subgraph data](/subgraphs/best-practices/pruning/) to remove unused entities and help stay within storage limits. -- If your subgraph references chains that receive indexing rewards, [indicated by double check marks in the Subgraphs column here](/supported-networks/), then [publish your Subgraph to the Network](/subgraphs/developing/publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph) and [add signal](/subgraphs/developing/publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph) to encourage other Indexers on the network to serve it. +- If your subgraph references chains that receive indexing rewards, [indicated by double check marks in the Subgraphs column here](/supported-networks/), then [publish your Subgraph to the Network](/subgraphs/developing/deploying-publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph) and [add signal](/subgraphs/developing/deploying-publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph) to encourage other Indexers on the network to serve it. - If your Subgraph references a chain that **does not** receive indexing rewards, reach out to InfraDAO [indexing@infradao.com⁠] or @jmulq on Telegram to discuss options that meet your technical needs. Edge & Node's team is committed to helping users avoid unnecessary interruptions and will continue to support all builders. diff --git a/website/src/pages/en/subgraphs/billing.mdx b/website/src/pages/en/subgraphs/providers/subgraph-studio/introduction.mdx similarity index 99% rename from website/src/pages/en/subgraphs/billing.mdx rename to website/src/pages/en/subgraphs/providers/subgraph-studio/introduction.mdx index d816ebb1b6f9..86679ca9de5d 100644 --- a/website/src/pages/en/subgraphs/billing.mdx +++ b/website/src/pages/en/subgraphs/providers/subgraph-studio/introduction.mdx @@ -1,5 +1,6 @@ --- -title: Billing +title: Subgraph Studio +sidebarTitle: Overview --- ## Querying Plans diff --git a/website/src/pages/en/subgraphs/querying/managing-api-keys.mdx b/website/src/pages/en/subgraphs/providers/subgraph-studio/managing-api-keys.mdx similarity index 97% rename from website/src/pages/en/subgraphs/querying/managing-api-keys.mdx rename to website/src/pages/en/subgraphs/providers/subgraph-studio/managing-api-keys.mdx index 136cbf1ef657..f7309a673cb3 100644 --- a/website/src/pages/en/subgraphs/querying/managing-api-keys.mdx +++ b/website/src/pages/en/subgraphs/providers/subgraph-studio/managing-api-keys.mdx @@ -2,7 +2,7 @@ title: How to Manage API keys --- -This guide shows you how to create, manage, and secure API keys for your [Subgraphs](/subgraphs/developing/subgraphs/). +This guide shows you how to create, manage, and secure API keys for your [Subgraphs](/subgraphs/overview/). ## Overview @@ -117,4 +117,4 @@ The “API keys” table lists existing API keys and allows you to manage or del ## Additional Resources -[Deploying Using Subgraph Studio](/subgraphs/developing/deploying/using-subgraph-studio/) +[Deploying Using Subgraph Studio](/subgraphs/developing/deploying-publishing/using-subgraph-studio/) diff --git a/website/src/pages/en/resources/subgraph-studio-faq.mdx b/website/src/pages/en/subgraphs/providers/subgraph-studio/studio-faq.mdx similarity index 98% rename from website/src/pages/en/resources/subgraph-studio-faq.mdx rename to website/src/pages/en/subgraphs/providers/subgraph-studio/studio-faq.mdx index c2d4037bd099..885cef30ada7 100644 --- a/website/src/pages/en/resources/subgraph-studio-faq.mdx +++ b/website/src/pages/en/subgraphs/providers/subgraph-studio/studio-faq.mdx @@ -1,5 +1,6 @@ --- title: Subgraph Studio FAQs +sidebarTitle: Studio FAQs --- ## 1. What is Subgraph Studio? diff --git a/website/src/pages/en/subgraphs/upgrade-indexer.mdx b/website/src/pages/en/subgraphs/providers/subgraph-studio/upgrade-indexer.mdx similarity index 88% rename from website/src/pages/en/subgraphs/upgrade-indexer.mdx rename to website/src/pages/en/subgraphs/providers/subgraph-studio/upgrade-indexer.mdx index 8d6c874bec12..c23739d2be33 100644 --- a/website/src/pages/en/subgraphs/upgrade-indexer.mdx +++ b/website/src/pages/en/subgraphs/providers/subgraph-studio/upgrade-indexer.mdx @@ -18,7 +18,7 @@ Originally designed as a transitional support, its primary purpose was to facili - Does not permanently index Subgraphs. Subgraph owners should curate Subgraphs to use independent Indexers long term. - Does not compete for rewards. The Upgrade Indexer's participation on the Graph Network does not dilute rewards for other Indexers. -- Doesn't support Time Travel Queries (TTQ). All Subgraphs on the Upgrade Indexer are auto-pruned. If TTQs are needed on a Subgraph, [curation signal can be added](/subgraphs/developing/publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph) to attract Indexers that will support this feature. +- Doesn't support Time Travel Queries (TTQ). All Subgraphs on the Upgrade Indexer are auto-pruned. If TTQs are needed on a Subgraph, [curation signal can be added](/subgraphs/developing/deploying-publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph) to attract Indexers that will support this feature. ### Conclusion diff --git a/website/src/pages/en/subgraphs/querying/_meta.js b/website/src/pages/en/subgraphs/querying/_meta.js index aa7d6b63f4eb..aff7099901d0 100644 --- a/website/src/pages/en/subgraphs/querying/_meta.js +++ b/website/src/pages/en/subgraphs/querying/_meta.js @@ -2,12 +2,10 @@ import titles from './_meta-titles.json' export default { introduction: '', - 'managing-api-keys': '', - 'best-practices': '', - 'from-an-application': '', - 'distributed-systems': '', 'graphql-api': '', - 'subgraph-id-vs-deployment-id': '', + 'best-practices': '', + 'from-an-application': 'Querying from Apps', + 'subgraph-id-vs-deployment-id': 'Subgraph vs Deployment IDs', 'graph-client': titles['graph-client'] ?? '', - python: '', + python: 'Querying in Python', } diff --git a/website/src/pages/en/subgraphs/querying/best-practices.mdx b/website/src/pages/en/subgraphs/querying/best-practices.mdx index f10b57eb4624..a0c8aab9f511 100644 --- a/website/src/pages/en/subgraphs/querying/best-practices.mdx +++ b/website/src/pages/en/subgraphs/querying/best-practices.mdx @@ -2,7 +2,7 @@ title: Querying Best Practices --- -Use The Graph's GraphQL API to query [Subgraph](/subgraphs/developing/subgraphs/) data efficiently. This guide outlines essential GraphQL rules, guides, and best practices to help you write optimized, reliable queries. +Use The Graph's GraphQL API to query [Subgraph](/subgraphs/overview/) data efficiently. This guide outlines essential GraphQL rules, guides, and best practices to help you write optimized, reliable queries. --- @@ -55,11 +55,11 @@ query [operationName]([variableName]: [variableType]) { 1. Each `queryName` must only be used once per operation. 2. Each `field` must be used only once in a selection (you cannot query `id` twice under `token`). 3. Complex types require a selection of sub-fields. - - For example, some `fields' or queries (like `tokens`) return complex types which will require a selection of sub-fields. Not providing a selection when expected or providing one when not expected will raise an error, such as `id`. To know a field type, please refer to [Graph Explorer](/subgraphs/explorer/). + - For example, some `fields' or queries (like `tokens`) return complex types which will require a selection of sub-fields. Not providing a selection when expected or providing one when not expected will raise an error, such as `id`. To know a field type, please refer to [Graph Explorer](/subgraphs/existing-subgraphs/explorer/). 4. Any variable assigned to an argument must match its type. 5. Variables must be uniquely defined and used. -**For a complete list of rules with code examples, check out the [GraphQL Validations guide](/resources/migration-guides/graphql-validations-migration-guide/)**. +**For a complete list of rules with code examples, check out the GraphQL Validations guide**. ### How to Send a Query to a GraphQL API diff --git a/website/src/pages/en/subgraphs/querying/distributed-systems.mdx b/website/src/pages/en/subgraphs/querying/distributed-systems.mdx deleted file mode 100644 index 85337206bfd3..000000000000 --- a/website/src/pages/en/subgraphs/querying/distributed-systems.mdx +++ /dev/null @@ -1,134 +0,0 @@ ---- -title: Distributed Systems ---- - -The Graph is a protocol implemented as a distributed system. - -Connections fail. Requests arrive out of order. Different computers with out-of-sync clocks and states process related requests. Servers restart. Re-orgs happen between requests. These problems are inherent to all distributed systems but are exacerbated in systems operating at a global scale. - -Consider this example of what may occur if a client polls an Indexer for the latest data during a re-org. - -1. Indexer ingests block 8 -2. Request served to the client for block 8 -3. Indexer ingests block 9 -4. Indexer ingests block 10A -5. Request served to the client for block 10A -6. Indexer detects reorg to 10B and rolls back 10A -7. Request served to the client for block 9 -8. Indexer ingests block 10B -9. Indexer ingests block 11 -10. Request served to the client for block 11 - -From the point of view of the Indexer, things are progressing forward logically. Time is moving forward, though we did have to roll back an uncle block and play the block under consensus forward on top of it. Along the way, the Indexer serves requests using the latest state it knows about at that time. - -From the point of view of the client, however, things appear chaotic. The client observes that the responses were for blocks 8, 10, 9, and 11 in that order. We call this the "block wobble" problem. When a client experiences block wobble, data may appear to contradict itself over time. The situation worsens when we consider that Indexers do not all ingest the latest blocks simultaneously, and your requests may be routed to multiple Indexers. - -It is the responsibility of the client and server to work together to provide consistent data to the user. Different approaches must be used depending on the desired consistency as there is no one right program for every problem. - -Reasoning through the implications of distributed systems is hard, but the fix may not be! We've established APIs and patterns to help you navigate some common use-cases. The following examples illustrate those patterns but still elide details required by production code (like error handling and cancellation) to not obfuscate the main ideas. - -## Polling for updated data - -The Graph provides the `block: { number_gte: $minBlock }` API, which ensures that the response is for a single block equal or higher to `$minBlock`. If the request is made to a `graph-node` instance and the min block is not yet synced, `graph-node` will return an error. If `graph-node` has synced min block, it will run the response for the latest block. If the request is made to an Edge & Node Gateway, the Gateway will filter out any Indexers that have not yet synced min block and make the request for the latest block the Indexer has synced. - -We can use `number_gte` to ensure that time never travels backward when polling for data in a loop. Here is an example: - -```javascript -/// Updates the protocol.paused variable to the latest -/// known value in a loop by fetching it using The Graph. -async function updateProtocolPaused() { - // It's ok to start with minBlock at 0. The query will be served - // using the latest block available. Setting minBlock to 0 is the - // same as leaving out that argument. - let minBlock = 0 - - for (;;) { - // Schedule a promise that will be ready once - // the next Ethereum block will likely be available. - const nextBlock = new Promise((f) => { - setTimeout(f, 14000) - }) - - const query = ` - query GetProtocol($minBlock: Int!) { - protocol(block: { number_gte: $minBlock } id: "0") { - paused - } - _meta { - block { - number - } - } - }` - - const variables = { minBlock } - const response = await graphql(query, variables) - minBlock = response._meta.block.number - - // TODO: Do something with the response data here instead of logging it. - console.log(response.protocol.paused) - - // Sleep to wait for the next block - await nextBlock - } -} -``` - -## Fetching a set of related items - -Another use-case is retrieving a large set or, more generally, retrieving related items across multiple requests. Unlike the polling case (where the desired consistency was to move forward in time), the desired consistency is for a single point in time. - -Here we will use the `block: { hash: $blockHash }` argument to pin all of our results to the same block. - -```javascript -/// Gets a list of domain names from a single block using pagination -async function getDomainNames() { - // Set a cap on the maximum number of items to pull. - let pages = 5 - const perPage = 1000 - - // The first query will get the first page of results and also get the block - // hash so that the remainder of the queries are consistent with the first. - const listDomainsQuery = ` - query ListDomains($perPage: Int!) { - domains(first: $perPage) { - name - id - } - _meta { - block { - hash - } - } - }` - - let data = await graphql(listDomainsQuery, { perPage }) - let result = data.domains.map((d) => d.name) - let blockHash = data._meta.block.hash - - let query - // Continue fetching additional pages until either we run into the limit of - // 5 pages total (specified above) or we know we have reached the last page - // because the page has fewer entities than a full page. - while (data.domains.length == perPage && --pages) { - let lastID = data.domains[data.domains.length - 1].id - query = ` - query ListDomains($perPage: Int!, $lastID: ID!, $blockHash: Bytes!) { - domains(first: $perPage, where: { id_gt: $lastID }, block: { hash: $blockHash }) { - name - id - } - }` - - data = await graphql(query, { perPage, lastID, blockHash }) - - // Accumulate domain names into the result - for (domain of data.domains) { - result.push(domain.name) - } - } - return result -} -``` - -Note that in case of a re-org, the client will need to retry from the first request to update the block hash to a non-uncle block. diff --git a/website/src/pages/en/subgraphs/querying/from-an-application.mdx b/website/src/pages/en/subgraphs/querying/from-an-application.mdx index 392ddab4f318..56623c4e4b51 100644 --- a/website/src/pages/en/subgraphs/querying/from-an-application.mdx +++ b/website/src/pages/en/subgraphs/querying/from-an-application.mdx @@ -11,7 +11,7 @@ During the development process, you will receive a GraphQL API endpoint at two d ### Subgraph Studio Endpoint -After deploying your Subgraph to [Subgraph Studio](/subgraphs/developing/deploying/using-subgraph-studio/), you will receive an endpoint that looks like this: +After deploying your Subgraph to [Subgraph Studio](/subgraphs/developing/deploying-publishing/using-subgraph-studio/), you will receive an endpoint that looks like this: ``` https://api.studio.thegraph.com/query/// diff --git a/website/src/pages/en/subgraphs/querying/introduction.mdx b/website/src/pages/en/subgraphs/querying/introduction.mdx index db102bb4d4dc..142cc77766ec 100644 --- a/website/src/pages/en/subgraphs/querying/introduction.mdx +++ b/website/src/pages/en/subgraphs/querying/introduction.mdx @@ -3,7 +3,7 @@ title: How to Query a Subgraph Using The Graph sidebarTitle: How to Query --- -To start querying right away, visit [Graph Explorer](https://thegraph.com/explorer). This guide shows you how to find a [Subgraph](/subgraphs/developing/subgraphs/), generate a unique URL, and run queries. +To start querying right away, visit [Graph Explorer](https://thegraph.com/explorer). This guide shows you how to find a [Subgraph](/subgraphs/overview/), generate a unique URL, and run queries. ## Overview @@ -27,11 +27,11 @@ On the Subgraph details page, click Query (top right) or scroll down. Each Subgr ### Step 3: Manage Your API Key -Each query URL requires a valid API key. In [Subgraph Studio](https://thegraph.com/studio), locate the **API Keys** section to create or manage your keys. Learn more about how to use Subgraph Studio [here](/subgraphs/developing/deploying/using-subgraph-studio/). +Each query URL requires a valid API key. In [Subgraph Studio](https://thegraph.com/studio), locate the **API Keys** section to create or manage your keys. Learn more about how to use Subgraph Studio [here](/subgraphs/developing/deploying-publishing/using-subgraph-studio/). ### Step 4: Check Your Usage Plan -Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/). +Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/providers/subgraph-studio/introduction/). ## Handling Errors diff --git a/website/src/pages/en/subgraphs/tooling/_meta-titles.json b/website/src/pages/en/subgraphs/tooling/_meta-titles.json new file mode 100644 index 000000000000..2d36c90184b0 --- /dev/null +++ b/website/src/pages/en/subgraphs/tooling/_meta-titles.json @@ -0,0 +1,3 @@ +{ + "subgraph-mcp": "MCPs" +} diff --git a/website/src/pages/en/subgraphs/tooling/_meta.js b/website/src/pages/en/subgraphs/tooling/_meta.js new file mode 100644 index 000000000000..b3f12a1e7bd1 --- /dev/null +++ b/website/src/pages/en/subgraphs/tooling/_meta.js @@ -0,0 +1,11 @@ +import titles from './_meta-titles.json' + +export default { + 'subgraph-mcp': titles['subgraph-mcp'] ?? '', + skills: 'SKILLs', + 'contract-analyzer': 'Smart Contract Analysis with Cana CLI', + 'subgraph-uncrashable': 'Subgraph Uncrashable', + 'subgraph-linter': 'Subgraph Linter', + 'unit-testing-framework': 'Matchstick Unit Testing', + 'x402-payments': 'x402 Payments', +} diff --git a/website/src/pages/en/subgraphs/guides/contract-analyzer.mdx b/website/src/pages/en/subgraphs/tooling/contract-analyzer.mdx similarity index 100% rename from website/src/pages/en/subgraphs/guides/contract-analyzer.mdx rename to website/src/pages/en/subgraphs/tooling/contract-analyzer.mdx diff --git a/website/src/pages/en/subgraphs/skills.mdx b/website/src/pages/en/subgraphs/tooling/skills.mdx similarity index 97% rename from website/src/pages/en/subgraphs/skills.mdx rename to website/src/pages/en/subgraphs/tooling/skills.mdx index 4b545615a3e0..e87c494aead2 100644 --- a/website/src/pages/en/subgraphs/skills.mdx +++ b/website/src/pages/en/subgraphs/tooling/skills.mdx @@ -98,7 +98,7 @@ Once installed, the AI assistant will have access to subgraph development expert - [Subgraph Composition](/subgraphs/guides/subgraph-composition/) - Combine multiple subgraphs - [Subgraph Linter](/subgraphs/developing/subgraph-linter/) - Static analysis tool - [Subgraph Uncrashable](/subgraphs/developing/subgraph-uncrashable/) - Safe code generation -- [Matchstick Testing Framework](/subgraphs/developing/creating/unit-testing-framework/) +- [Matchstick Testing Framework](/subgraphs/tooling/unit-testing-framework/) - [AssemblyScript API](/subgraphs/developing/creating/assemblyscript-api/) ## Platforms diff --git a/website/src/pages/en/subgraphs/guides/subgraph-linter.mdx b/website/src/pages/en/subgraphs/tooling/subgraph-linter.mdx similarity index 100% rename from website/src/pages/en/subgraphs/guides/subgraph-linter.mdx rename to website/src/pages/en/subgraphs/tooling/subgraph-linter.mdx diff --git a/website/src/pages/en/subgraphs/subgraph-mcp/_meta.js b/website/src/pages/en/subgraphs/tooling/subgraph-mcp/_meta.js similarity index 100% rename from website/src/pages/en/subgraphs/subgraph-mcp/_meta.js rename to website/src/pages/en/subgraphs/tooling/subgraph-mcp/_meta.js diff --git a/website/src/pages/en/subgraphs/subgraph-mcp/claude.mdx b/website/src/pages/en/subgraphs/tooling/subgraph-mcp/claude.mdx similarity index 100% rename from website/src/pages/en/subgraphs/subgraph-mcp/claude.mdx rename to website/src/pages/en/subgraphs/tooling/subgraph-mcp/claude.mdx diff --git a/website/src/pages/en/subgraphs/subgraph-mcp/cline.mdx b/website/src/pages/en/subgraphs/tooling/subgraph-mcp/cline.mdx similarity index 100% rename from website/src/pages/en/subgraphs/subgraph-mcp/cline.mdx rename to website/src/pages/en/subgraphs/tooling/subgraph-mcp/cline.mdx diff --git a/website/src/pages/en/subgraphs/subgraph-mcp/cursor.mdx b/website/src/pages/en/subgraphs/tooling/subgraph-mcp/cursor.mdx similarity index 100% rename from website/src/pages/en/subgraphs/subgraph-mcp/cursor.mdx rename to website/src/pages/en/subgraphs/tooling/subgraph-mcp/cursor.mdx diff --git a/website/src/pages/en/subgraphs/subgraph-mcp/introduction.mdx b/website/src/pages/en/subgraphs/tooling/subgraph-mcp/introduction.mdx similarity index 84% rename from website/src/pages/en/subgraphs/subgraph-mcp/introduction.mdx rename to website/src/pages/en/subgraphs/tooling/subgraph-mcp/introduction.mdx index 6e6a34438d58..b17a5a21bae0 100644 --- a/website/src/pages/en/subgraphs/subgraph-mcp/introduction.mdx +++ b/website/src/pages/en/subgraphs/tooling/subgraph-mcp/introduction.mdx @@ -19,4 +19,4 @@ Think of it as a USB-C hub: it standardizes the plug-and-play connection between - Retrieve 30-day query volumes for Subgraph deployments - Ask questions about Subgraph data without writing GraphQL manually -The Subgraph MCP server allows smooth integration with [Claude](/subgraphs/subgraph-mcp/claude/), [Cline](/subgraphs/subgraph-mcp/cline/), or [Cursor](/subgraphs/subgraph-mcp/cursor/), making blockchain data queries with The Graph Network a conversational experience. +The Subgraph MCP server allows smooth integration with [Claude](/subgraphs/tooling/subgraph-mcp/claude/), [Cline](/subgraphs/tooling/subgraph-mcp/cline/), or [Cursor](/subgraphs/tooling/subgraph-mcp/cursor/), making blockchain data queries with The Graph Network a conversational experience. diff --git a/website/src/pages/en/subgraphs/guides/subgraph-uncrashable.mdx b/website/src/pages/en/subgraphs/tooling/subgraph-uncrashable.mdx similarity index 100% rename from website/src/pages/en/subgraphs/guides/subgraph-uncrashable.mdx rename to website/src/pages/en/subgraphs/tooling/subgraph-uncrashable.mdx diff --git a/website/src/pages/en/subgraphs/developing/creating/unit-testing-framework.mdx b/website/src/pages/en/subgraphs/tooling/unit-testing-framework.mdx similarity index 100% rename from website/src/pages/en/subgraphs/developing/creating/unit-testing-framework.mdx rename to website/src/pages/en/subgraphs/tooling/unit-testing-framework.mdx diff --git a/website/src/pages/en/subgraphs/guides/x402-payments.mdx b/website/src/pages/en/subgraphs/tooling/x402-payments.mdx similarity index 100% rename from website/src/pages/en/subgraphs/guides/x402-payments.mdx rename to website/src/pages/en/subgraphs/tooling/x402-payments.mdx diff --git a/website/src/pages/en/substreams/_meta-titles.json b/website/src/pages/en/substreams/_meta-titles.json index 541dcbe0defe..e2d95de881a7 100644 --- a/website/src/pages/en/substreams/_meta-titles.json +++ b/website/src/pages/en/substreams/_meta-titles.json @@ -1,4 +1,6 @@ { "developing": "Developing", - "substreams-mcp": "Substreams MCP" + "providers": "Providers", + "public-substreams": "Public Substreams", + "tooling": "Tooling" } diff --git a/website/src/pages/en/substreams/_meta.js b/website/src/pages/en/substreams/_meta.js index cd00f44a0316..a1e8ee4593df 100644 --- a/website/src/pages/en/substreams/_meta.js +++ b/website/src/pages/en/substreams/_meta.js @@ -1,10 +1,11 @@ import titles from './_meta-titles.json' export default { + overview: '', 'quick-start': '', - introduction: '', + providers: titles.providers ?? '', + 'public-substreams': titles['public-substreams'] ?? '', developing: titles.developing ?? '', publishing: '', - skills: '', - 'substreams-mcp': titles['substreams-mcp'] ?? '', + tooling: titles.tooling ?? '', } diff --git a/website/src/pages/en/substreams/introduction.mdx b/website/src/pages/en/substreams/overview.mdx similarity index 98% rename from website/src/pages/en/substreams/introduction.mdx rename to website/src/pages/en/substreams/overview.mdx index 0bd1ea21c9f6..7e57d0b5a491 100644 --- a/website/src/pages/en/substreams/introduction.mdx +++ b/website/src/pages/en/substreams/overview.mdx @@ -1,6 +1,6 @@ --- title: Introduction to Substreams -sidebarTitle: Introduction +sidebarTitle: Overview --- ![Substreams Logo](/img/substreams-logo.png) diff --git a/website/src/pages/en/substreams/providers/_meta.js b/website/src/pages/en/substreams/providers/_meta.js new file mode 100644 index 000000000000..3a23e9efc68f --- /dev/null +++ b/website/src/pages/en/substreams/providers/_meta.js @@ -0,0 +1,3 @@ +export default { + 'the-graph-market': '', +} diff --git a/website/src/pages/en/substreams/providers/the-graph-market.mdx b/website/src/pages/en/substreams/providers/the-graph-market.mdx new file mode 100644 index 000000000000..41f7b7bb2305 --- /dev/null +++ b/website/src/pages/en/substreams/providers/the-graph-market.mdx @@ -0,0 +1,103 @@ +--- +title: The Graph Market +sidebarTitle: The Graph Market +--- + +[The Graph Market](https://thegraph.market/) is a data services marketplace where you can provision an API key and stream on-chain data through Substreams and Firehose, along with the Token API, Hosted Sinks, and other services. + +## Overview + +The Graph Market lets you find a provider for the network you're building on, create an API key, and start consuming data — without providing personal information. From a single dashboard you can manage keys, monitor usage, and deploy Hosted Sinks. + +The platform serves several data services: + +- **Substreams & Firehose**: High-throughput, parallelized streaming of blockchain data. +- **Token API**: Live and historical token data (balances, transfers, holders, and DEX swaps) across multiple chains. +- **Hosted Sinks**: Managed sink deployments that write Substreams output to a destination for you. +- **Subgraphs, JSON-RPC, and Webhooks**: Additional data services available across supported networks. + +## Get Started + +### Create an Account + +Go to [thegraph.market](https://thegraph.market/) and sign in. Once you're in, you'll land on the **Dashboard**, which summarizes your usage for Substreams & Firehose and the Token API, your Hosted Sinks, and your API keys. + +### Create an API Key + +From the **Dashboard** or the **API keys** page, select **Create new key** and give it a name (for example, `my-substreams-key`). Each key exposes two credentials: + +- **API Key**: An identifier (for example, `server_1...`) used for services that authenticate with a key. +- **API Token (JWT)**: A JSON Web Token used to authenticate Substreams and Firehose requests. + +For security, the API token is hidden by default. Use the reveal (eye) icon to display it, then copy and store it securely. You can rotate or delete a key at any time from the **API keys** page. + +> Note: Treat your API token like a password. Don't commit it to source control or expose it in client-side code. + +## Use Your Key with Substreams + +### Authenticate the CLI + +Substreams authenticates with the JWT token from your API key. Export it as an environment variable so the CLI can pick it up automatically: + +```bash +export SUBSTREAMS_API_TOKEN="" +``` + +Replace `` with the API token you copied from The Graph Market. + +### Choose an Endpoint + +Substreams runs against a provider endpoint for your target network, passed to the CLI with the `-e` flag. Endpoints follow the pattern `{network}.{provider}.io:443`. A few examples: + +| Network | Endpoint | +| --- | --- | +| Ethereum Mainnet | `mainnet.eth.streamingfast.io:443` | +| Solana Mainnet | `mainnet.sol.streamingfast.io:443` | +| Base Mainnet | `base-mainnet.streamingfast.io:443` | +| Arbitrum One | `arb-one.streamingfast.io:443` | +| Polygon Mainnet | `polygon.streamingfast.io:443` | + +> Note: Select your network on The Graph Market to see the providers and endpoints available for it. For the full, up-to-date list, see [Chains & Endpoints](https://docs.substreams.dev/reference-material/chain-support/chains-and-endpoints) on the Substreams docs. + +### Run a Substreams + +With your token exported, run a package against the endpoint for your network: + +```bash +substreams gui \ + -e mainnet.eth.streamingfast.io:443 \ + ethereum-common@v0.3.1 \ + all_events \ + --start-block=15000000 +``` + +A successful run confirms your key is authenticated. To find ready-to-use packages, browse the [Substreams Registry](https://substreams.dev/). + +## Deploy a Hosted Sink + +If you'd rather have your data written to a destination automatically, use **Hosted Sinks**. From the **Sinks** page, select **New Sink**, then point it at a Substreams package and configure the destination. The Dashboard tracks each deployment's status (deployed, syncing, error, or stopped). To learn more about sink types, see [Sink your Substreams](/substreams/developing/sinks/). + +## Use the Token API + +The Token API uses the same API token for authentication. Send it as a bearer token against the Token API base URL: + +```bash +curl --request GET \ + --url "https://token-api.thegraph.com/v1/evm/balances?network=mainnet&address=0x2a0c0dbecc7e4d658f48e01e3fa353f44050c208" \ + --header 'Accept: application/json' \ + --header 'Authorization: Bearer ' +``` + +See the [Token API Quick Start](https://thegraph.com/docs/en/token-api/quick-start/) for the full list of endpoints. + +## Plans and Usage + +The Graph Market offers a **Free** plan for both Substreams & Firehose and the Token API, with monthly included usage (for example, egress bytes and processed blocks for Substreams & Firehose, and request counts for the Token API). The Dashboard shows your consumption against these limits. Review the [Pricing](https://thegraph.market/) page for current plan tiers and included quotas. + +## Additional Resources + +- [The Graph Market](https://thegraph.market/) — provision keys and manage data services. +- [Substreams Quick Start](/substreams/quick-start/) — start streaming on-chain data. +- [Sink your Substreams](/substreams/developing/sinks/) — send data to a destination. +- [Chains & Endpoints](https://docs.substreams.dev/reference-material/chain-support/chains-and-endpoints) — provider endpoints per network. +- [Token API Quick Start](https://thegraph.com/docs/en/token-api/quick-start/) — access token data. diff --git a/website/src/pages/en/substreams/public-substreams/_meta.js b/website/src/pages/en/substreams/public-substreams/_meta.js new file mode 100644 index 000000000000..cae490fe1acf --- /dev/null +++ b/website/src/pages/en/substreams/public-substreams/_meta.js @@ -0,0 +1,3 @@ +export default { + 'substreams-dev': '', +} diff --git a/website/src/pages/en/substreams/public-substreams/substreams-dev.mdx b/website/src/pages/en/substreams/public-substreams/substreams-dev.mdx new file mode 100644 index 000000000000..7fed14441ff2 --- /dev/null +++ b/website/src/pages/en/substreams/public-substreams/substreams-dev.mdx @@ -0,0 +1,146 @@ +--- +title: Using Substreams.dev to Find Substreams Packages +sidebarTitle: Using Substreams.dev +--- + +Use [Substreams.dev](https://substreams.dev/) and take full advantage of its core features to discover ready-to-use Substreams packages for the data you want. + +## Overview + +This guide explains how to use [Substreams.dev](https://substreams.dev/) (the Substreams Registry) to quickly discover, inspect, and consume Substreams packages. Where [Graph Explorer](/subgraphs/existing-subgraphs/explorer/) helps you find published Subgraphs, Substreams.dev is the storefront for the Substreams ecosystem: it lets you browse curated data collections, inspect individual packages and their modules, explore what's available per chain, and learn from real-world projects. + +> When you visit [Graph Explorer](https://thegraph.com/explorer), you can also access the link to [explore Substreams](https://substreams.dev/). + +The goal of this page is to help **data consumers** answer a single question: _"Is there already a Substreams package that produces the data I need, and how do I start streaming it?"_ If you're ready to build your own package instead, see the [Substreams Quick Start](/substreams/quick-start/). + +## Prerequisites + +- Basic familiarity with [Substreams](/substreams/overview/) and the idea that a package (`.spkg`) is a precompiled binary describing the data to extract from a chain. +- The [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) installed if you plan to inspect or run packages locally (`substreams gui`, `substreams run`, `substreams info`). +- An API key to stream on-chain data. Substreams is permissionless — you can [obtain a key here](https://thegraph.market/) without providing personal information. +- A GitHub account if you plan to log in, create an authentication token, or [publish your own package](/substreams/publishing/). + +## Navigating Substreams.dev + +Substreams.dev is organized into four primary areas, each answering a different discovery question. The sections below walk through each one in the order you'd typically use them. + +| Area | Discovery question it answers | +| --- | --- | +| **Datasets** | "What kind of data am I looking for?" (browse by use case) | +| **Packages** | "Which specific package produces it, and what does it output?" | +| **Chains** | "What's available on the network I care about?" | +| **Projects** | "How have others put this data to use?" | + +### Datasets + +> Datasets are curated collections of Substreams packages, grouped so you can start from the _kind_ of data you want rather than a package name. (Referred to here by their current site label, "Datasets.") + +The **[Datasets](https://substreams.dev/)** area is the best starting point when you know the type of on-chain activity you want but not the exact package. Instead of searching by keyword, you pick a data domain and move into a vetted set of packages that produce it. + +Datasets are organized by use case, including categories such as: + +- DEX / AMMs (e.g., swap feeds) +- Lending +- Liquid Staking +- Protocol Staking +- Perps / Derivatives (e.g., position monitoring) +- Prediction Markets +- Governance +- Oracles +- Bridges +- Stablecoins +- NFTs +- Core Data + +Each dataset card typically surfaces: + +- The category name and whether it is **Featured** +- The number of curated packages available in that category +- The blockchains covered (such as Ethereum, Solana, Polygon, Arbitrum, Optimism, and Base) +- Typical outputs or use cases (for example, "swap feeds" or "position monitoring") +- A status indicator (such as "In progress") when a collection is still being assembled + +**How to use it:** Select a data domain, review the curated package recommendations inside it, then choose how you want to consume the data — package-level CLI, JavaScript, local execution, or a deployment path through the [Substreams x The Graph Market](https://thegraph.market/) workflow. This is the fastest route from "I need DEX swaps" to a package that produces them. + +### Packages + +The **[Packages](https://substreams.dev/)** area is the core of the registry. A Substreams package is a precompiled `.spkg` binary that defines exactly what data is extracted and transformed from a chain — conceptually similar to the mapping logic in a traditional Subgraph. + +Package listings can be sorted and browsed by: + +- **Last uploaded** — the most recently published packages +- **Featured** — highlighted, recommended packages +- **Most downloaded** — the most widely used packages +- **Most used** and **Alphabetical** — additional ordering options when searching + +Each package entry generally shows its name, creator, target network, version, published date, and download count. This metadata helps you quickly gauge maturity and adoption before committing to a package. + +Click into any package to reach its dedicated page, where you can: + +- View package metadata — name, version, documentation, and target network +- Inspect the **module graph (DAG)**: every module, its kind (`map`, `store`, or `blockIndex`), output types, and update policies +- See how modules depend on one another (`dependsOn` / `dependedBy`) and the input chain for each module (source blocks, other maps, stores in get/deltas mode, and params) +- Review the **protobuf output types** and proto files the package produces, so you know the exact shape of the data +- Copy ready-to-run commands to stream or deploy the package + +**Inspecting a package from the CLI.** Once you have a package's `.spkg` URL, you can inspect and run it directly without downloading anything first: + +```bash +# See a package's modules, output types, and metadata +substreams info https://spkg.io/creator/package-v1.0.0.spkg + +# Explore results interactively in a terminal UI +substreams gui https://spkg.io/creator/package-v1.0.0.spkg + +# Stream output from a specific module +substreams run -e mainnet.eth.streamingfast.io:443 https://spkg.io/creator/package-v1.0.0.spkg -t +1000 +``` + +> Tip: You can also inspect packages, read their module DAGs, and generate sink commands programmatically with the [Substreams Search MCP](/substreams/tooling/substreams-mcp/search/), which lets AI agents search the registry and analyze packages for you. + +### Chains + +The **[Chains](https://substreams.dev/)** area lets you discover data by starting from a network rather than a use case. It's the right entry point when your question is "what Substreams data can I get on _this_ chain?" + +The Chains view organizes blockchain families and surfaces, for each network: + +- The available **endpoints** used to stream data (for example, "3 networks / 12 endpoints" for Ethereum) +- The **block model** for the chain (how blocks and their contents are represented) +- The packages available for that network + +Networks span several ecosystems, including Ethereum, Solana, BNB Chain, Arbitrum, Polygon, and Near, with additional chains supported across the broader Substreams ecosystem. Selecting a chain filters discovery down to what's available there, so you can move straight from a network choice to a compatible package and its streaming endpoint. + +### Projects + +The **[Projects](https://substreams.dev/)** area showcases real-world implementations — practical examples of how teams have used Substreams packages to power applications, pipelines, and data products. + +Use Projects to: + +- See end-to-end examples of packages in production, from discovery through to a live data sink +- Understand common patterns for wiring packages into applications and databases +- Get ideas for how to combine packages in a more composable way + +Projects are especially useful once you've found candidate packages in Datasets or Packages and want to see how similar data has been consumed and sinked in practice. + +## Consuming Package Data + +After you've found a package that fits your needs, you choose how to consume the data. Substreams supports multiple sinks: + +- **[Subgraph](/sps/introduction/)** — configure an API to meet your data needs and host it on The Graph Network. +- **[SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink)** — send the data to a Postgres or Clickhouse database. +- **[Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)** — stream data directly into your application. +- **[PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub)** — publish data to a PubSub topic. + +Many package pages will help you identify the right sink. If a package has an embedded sink configuration, it can produce ready-to-run `install`, `setup`, and `run` commands with the correct network endpoint; if not, you can still check whether its modules output sink-compatible types (such as `DatabaseChanges`) and wire up a sink yourself. + +## Publishing Your Own Package + +If you can't find a package that produces the data you need, you can build and publish one. Substreams packages are written in Rust, and once compiled to an `.spkg` you can share them with the community through the registry. See [Publishing a Substreams Package](/substreams/publishing/) for the full flow, and the [Substreams Quick Start](/substreams/quick-start/) to start building. + +## Additional Resources + +- [Substreams Overview](/substreams/overview/) — what Substreams is and how it works. +- [Substreams Quick Start](/substreams/quick-start/) — use ready-made packages or develop your own. +- [Substreams Registry](https://substreams.dev/) — browse the full, growing collection of packages. +- [StreamingFast Substreams Docs](https://docs.substreams.dev/) — reference material, tutorials, and how-to guides maintained by the core development team. +- [The Graph Market](https://thegraph.market/) — obtain a key and provision packages for production. diff --git a/website/src/pages/en/substreams/tooling/_meta-titles.json b/website/src/pages/en/substreams/tooling/_meta-titles.json new file mode 100644 index 000000000000..56b6256850da --- /dev/null +++ b/website/src/pages/en/substreams/tooling/_meta-titles.json @@ -0,0 +1,3 @@ +{ + "substreams-mcp": "MCPs" +} diff --git a/website/src/pages/en/substreams/tooling/_meta.js b/website/src/pages/en/substreams/tooling/_meta.js new file mode 100644 index 000000000000..1a724d9ab25a --- /dev/null +++ b/website/src/pages/en/substreams/tooling/_meta.js @@ -0,0 +1,6 @@ +import titles from './_meta-titles.json' + +export default { + 'substreams-mcp': titles['substreams-mcp'] ?? '', + skills: 'Skills', +} diff --git a/website/src/pages/en/substreams/skills.mdx b/website/src/pages/en/substreams/tooling/skills.mdx similarity index 100% rename from website/src/pages/en/substreams/skills.mdx rename to website/src/pages/en/substreams/tooling/skills.mdx diff --git a/website/src/pages/en/substreams/substreams-mcp/_meta.js b/website/src/pages/en/substreams/tooling/substreams-mcp/_meta.js similarity index 100% rename from website/src/pages/en/substreams/substreams-mcp/_meta.js rename to website/src/pages/en/substreams/tooling/substreams-mcp/_meta.js diff --git a/website/src/pages/en/substreams/substreams-mcp/search.mdx b/website/src/pages/en/substreams/tooling/substreams-mcp/search.mdx similarity index 100% rename from website/src/pages/en/substreams/substreams-mcp/search.mdx rename to website/src/pages/en/substreams/tooling/substreams-mcp/search.mdx diff --git a/website/src/supportedNetworks/NetworksTable.tsx b/website/src/supportedNetworks/NetworksTable.tsx index 86e28778ae5b..800f81d1052a 100644 --- a/website/src/supportedNetworks/NetworksTable.tsx +++ b/website/src/supportedNetworks/NetworksTable.tsx @@ -59,7 +59,7 @@ export function NetworksTable({ networks }: { networks: SupportedNetwork[] }) {

{t('index.supportedNetworks.infoText')}

- + {t('index.supportedNetworks.infoLink')}

@@ -85,7 +85,7 @@ export function NetworksTable({ networks }: { networks: SupportedNetwork[] }) {
- Substreams + Firehose/Substreams
{checkmark} {t('index.supportedNetworks.tableLegend.substreams.basic')} @@ -95,17 +95,6 @@ export function NetworksTable({ networks }: { networks: SupportedNetwork[] }) { {t('index.supportedNetworks.tableLegend.substreams.full')}
-
- Firehose -
- {checkmark} - {t('index.supportedNetworks.tableLegend.firehose.basic')} -
-
- {checkmarks} - {t('index.supportedNetworks.tableLegend.firehose.full')} -
-
diff --git a/website/src/supportedNetworks/ResourceCards.tsx b/website/src/supportedNetworks/ResourceCards.tsx index 908706d468fb..af973e6d7574 100644 --- a/website/src/supportedNetworks/ResourceCards.tsx +++ b/website/src/supportedNetworks/ResourceCards.tsx @@ -24,14 +24,14 @@ export const evmCards = [ icon: , }, { - href: 'https://thegraph.com/docs/en/subgraphs/billing/', + href: 'https://thegraph.com/docs/en/subgraphs/providers/subgraph-studio/introduction/', titleKey: 'index.networkGuides.evm.billing.title' as const, descriptionKey: 'index.networkGuides.evm.billing.description' as const, minutes: 5, icon: , // TODO: Is this really the right icon for this? }, { - href: 'https://thegraph.com/docs/en/subgraphs/explorer/', + href: 'https://thegraph.com/docs/en/subgraphs/existing-subgraphs/explorer/', titleKey: 'index.networkGuides.evm.graphExplorer.title' as const, descriptionKey: 'index.networkGuides.evm.graphExplorer.description' as const, minutes: 12, @@ -53,14 +53,14 @@ export const evmSubgraphsOnlyCards = [ icon: , }, { - href: 'https://thegraph.com/docs/en/subgraphs/explorer/', + href: 'https://thegraph.com/docs/en/subgraphs/existing-subgraphs/explorer/', titleKey: 'index.networkGuides.evm.graphExplorer.title' as const, descriptionKey: 'index.networkGuides.evm.graphExplorer.description' as const, minutes: 12, icon: , }, { - href: 'https://thegraph.com/docs/en/subgraphs/billing/', + href: 'https://thegraph.com/docs/en/subgraphs/providers/subgraph-studio/introduction/', titleKey: 'index.networkGuides.evm.billing.title' as const, descriptionKey: 'index.networkGuides.evm.billing.description' as const, minutes: 5, From ea80dbcc4766181fdb15fa7843e36cf25d9a38f5 Mon Sep 17 00:00:00 2001 From: Brandon Kramer Date: Fri, 10 Jul 2026 16:54:55 -0400 Subject: [PATCH 2/7] ran prettier --- .../existing-subgraphs/standard-subgraphs.mdx | 38 +++++++++---------- .../substreams/providers/the-graph-market.mdx | 14 +++---- .../public-substreams/substreams-dev.mdx | 10 ++--- 3 files changed, 31 insertions(+), 31 deletions(-) diff --git a/website/src/pages/en/subgraphs/existing-subgraphs/standard-subgraphs.mdx b/website/src/pages/en/subgraphs/existing-subgraphs/standard-subgraphs.mdx index ec804d9382b8..eff49463e004 100644 --- a/website/src/pages/en/subgraphs/existing-subgraphs/standard-subgraphs.mdx +++ b/website/src/pages/en/subgraphs/existing-subgraphs/standard-subgraphs.mdx @@ -4,7 +4,7 @@ title: Standardized Subgraphs ## Overview -**Standardized Subgraphs** are a family of open, reusable GraphQL schemas that normalize on-chain data across every protocol of the same type. Rather than each protocol exposing its own bespoke schema with its own terminology, every Subgraph built to a standard exposes the *same* entities, fields, and metrics, so a single set of queries works across all of them. +**Standardized Subgraphs** are a family of open, reusable GraphQL schemas that normalize on-chain data across every protocol of the same type. Rather than each protocol exposing its own bespoke schema with its own terminology, every Subgraph built to a standard exposes the _same_ entities, fields, and metrics, so a single set of queries works across all of them. The most widely adopted set of these schemas was created by [Messari](https://messari.io/), the core subgraph dev that builds and maintains standardized schemas for the major DeFi and web3 protocol categories on top of The Graph. Each schema extracts raw blockchain data and transforms it into meaningful, comparable metrics for products and analytics. @@ -20,35 +20,35 @@ The most widely adopted set of these schemas was created by [Messari](https://me **Predictable versioning.** Schemas follow [semantic versioning](https://semver.org/) strictly, and each Subgraph embeds three separate version fields on its `Protocol` entity so different stakeholders can track what they care about: -| Field | Who it's for | What it tracks | -| -------------------- | ------------------- | ------------------------------------------------------------------------------ | -| `schemaVersion` | Data consumers | Which version of the shared schema the Subgraph implements; signals breaking changes. | -| `subgraphVersion` | subgraph developers | The implementation version; refactors bump this with no impact on consumers. | -| `methodologyVersion` | Data consumers | How metrics are calculated, so consumers can diff against methodology changes. | +| Field | Who it's for | What it tracks | +| --- | --- | --- | +| `schemaVersion` | Data consumers | Which version of the shared schema the Subgraph implements; signals breaking changes. | +| `subgraphVersion` | subgraph developers | The implementation version; refactors bump this with no impact on consumers. | +| `methodologyVersion` | Data consumers | How metrics are calculated, so consumers can diff against methodology changes. | ## The Schemas The standardized schemas each cover one protocol category. Every schema shares a common backbone (`Token`, `Protocol`, pools or markets, daily and hourly snapshots for time-series data, and standardized revenue and usage metrics) while adding the entities specific to its domain. -| Schema | Version | What it covers | -| ------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------- | -| **Generic** | 3.0.0 | The base template that all schemas build on. Defines `Token`, `Protocol`, `Pool`, `Account`, and the standard usage and financial snapshots. A good fit for protocols that don't map cleanly onto a more specific category. | -| **DEX AMM** | 1.3.2 | Automated market maker exchanges. Models `LiquidityPool`, `Swap`, `Deposit`, and `Withdraw` events, pool fees, and reward tokens. | -| **DEX AMM (Extended)** | 4.0.1 | AMMs with concentrated liquidity (e.g. Uniswap v3). Adds `Tick`, `Position`, and `PositionSnapshot` entities on top of the DEX AMM model. | -| **DEX Aggregator** | 1.0.2 | Trade aggregators that route across venues. Models `VirtualPool`, per-token daily snapshots, and `Swap` activity. | -| **Lending / CDP** | 3.1.0 | Lending, borrowing, and collateralized debt position protocols. Models `Market`, `Position`, `InterestRate`, and the full set of lending events: `Deposit`, `Withdraw`, `Borrow`, `Repay`, `Liquidate`, `Transfer`, and `Flashloan`. | -| **Yield Aggregator** | 1.3.1 | Vaults and yield optimizers. Models `Vault`, `VaultFee`, `Deposit`, and `Withdraw`, with reward-token accounting. | -| **NFT Marketplace** | 2.1.0 | NFT trading venues. Models `Marketplace`, `Collection`, and `Trade`, with support for multiple NFT standards and sale strategies. | -| **Network** | 1.2.0 | Layer-1 and layer-2 chain-level metrics. Models `Block`, `Author`, and `Chunk` with network-wide daily and hourly stats. | -| **Bridge** | 1.2.0 | Cross-chain bridges. Models `Pool`, `PoolRoute`, `CrosschainToken`, `BridgeTransfer`, and `BridgeMessage` to track liquidity and value moving across chains. | +| Schema | Version | What it covers | +| --- | --- | --- | +| **Generic** | 3.0.0 | The base template that all schemas build on. Defines `Token`, `Protocol`, `Pool`, `Account`, and the standard usage and financial snapshots. A good fit for protocols that don't map cleanly onto a more specific category. | +| **DEX AMM** | 1.3.2 | Automated market maker exchanges. Models `LiquidityPool`, `Swap`, `Deposit`, and `Withdraw` events, pool fees, and reward tokens. | +| **DEX AMM (Extended)** | 4.0.1 | AMMs with concentrated liquidity (e.g. Uniswap v3). Adds `Tick`, `Position`, and `PositionSnapshot` entities on top of the DEX AMM model. | +| **DEX Aggregator** | 1.0.2 | Trade aggregators that route across venues. Models `VirtualPool`, per-token daily snapshots, and `Swap` activity. | +| **Lending / CDP** | 3.1.0 | Lending, borrowing, and collateralized debt position protocols. Models `Market`, `Position`, `InterestRate`, and the full set of lending events: `Deposit`, `Withdraw`, `Borrow`, `Repay`, `Liquidate`, `Transfer`, and `Flashloan`. | +| **Yield Aggregator** | 1.3.1 | Vaults and yield optimizers. Models `Vault`, `VaultFee`, `Deposit`, and `Withdraw`, with reward-token accounting. | +| **NFT Marketplace** | 2.1.0 | NFT trading venues. Models `Marketplace`, `Collection`, and `Trade`, with support for multiple NFT standards and sale strategies. | +| **Network** | 1.2.0 | Layer-1 and layer-2 chain-level metrics. Models `Block`, `Author`, and `Chunk` with network-wide daily and hourly stats. | +| **Bridge** | 1.2.0 | Cross-chain bridges. Models `Pool`, `PoolRoute`, `CrosschainToken`, `BridgeTransfer`, and `BridgeMessage` to track liquidity and value moving across chains. | | **Derivatives (Perpetual Futures)** | 1.3.4 | Perpetual futures venues. Models `LiquidityPool`, `Position`, `CollateralIn` and `CollateralOut`, `Borrow`, `Swap`, and `Liquidate`. | -| **Derivatives (Options)** | 1.3.2 | On-chain options protocols. Models `LiquidityPool`, `Position`, and `Option`, with call and put option typing. | +| **Derivatives (Options)** | 1.3.2 | On-chain options protocols. Models `LiquidityPool`, `Position`, and `Option`, with call and put option typing. | ## Shared Design Principles Because the schemas are meant to be consumed the same way regardless of protocol, they follow a consistent set of conventions. -**Three ways to read quantitative data.** You can query an entity directly for *real-time* values (e.g. `totalValueLockedUSD` on a `Pool`), use [time-travel queries](https://thegraph.com/docs/en/subgraphs/querying/graphql-api/#time-travel-queries) for *point-in-time* historical values, or query the snapshot entities for *time-series* data (e.g. `PoolDailySnapshot`). +**Three ways to read quantitative data.** You can query an entity directly for _real-time_ values (e.g. `totalValueLockedUSD` on a `Pool`), use [time-travel queries](https://thegraph.com/docs/en/subgraphs/querying/graphql-api/#time-travel-queries) for _point-in-time_ historical values, or query the snapshot entities for _time-series_ data (e.g. `PoolDailySnapshot`). **Standardized financial metrics.** Revenue is split consistently across every schema: diff --git a/website/src/pages/en/substreams/providers/the-graph-market.mdx b/website/src/pages/en/substreams/providers/the-graph-market.mdx index 41f7b7bb2305..c527544a3f21 100644 --- a/website/src/pages/en/substreams/providers/the-graph-market.mdx +++ b/website/src/pages/en/substreams/providers/the-graph-market.mdx @@ -49,13 +49,13 @@ Replace `` with the API token you copied from The Graph Market. Substreams runs against a provider endpoint for your target network, passed to the CLI with the `-e` flag. Endpoints follow the pattern `{network}.{provider}.io:443`. A few examples: -| Network | Endpoint | -| --- | --- | -| Ethereum Mainnet | `mainnet.eth.streamingfast.io:443` | -| Solana Mainnet | `mainnet.sol.streamingfast.io:443` | -| Base Mainnet | `base-mainnet.streamingfast.io:443` | -| Arbitrum One | `arb-one.streamingfast.io:443` | -| Polygon Mainnet | `polygon.streamingfast.io:443` | +| Network | Endpoint | +| ---------------- | ----------------------------------- | +| Ethereum Mainnet | `mainnet.eth.streamingfast.io:443` | +| Solana Mainnet | `mainnet.sol.streamingfast.io:443` | +| Base Mainnet | `base-mainnet.streamingfast.io:443` | +| Arbitrum One | `arb-one.streamingfast.io:443` | +| Polygon Mainnet | `polygon.streamingfast.io:443` | > Note: Select your network on The Graph Market to see the providers and endpoints available for it. For the full, up-to-date list, see [Chains & Endpoints](https://docs.substreams.dev/reference-material/chain-support/chains-and-endpoints) on the Substreams docs. diff --git a/website/src/pages/en/substreams/public-substreams/substreams-dev.mdx b/website/src/pages/en/substreams/public-substreams/substreams-dev.mdx index 7fed14441ff2..a28d132cb950 100644 --- a/website/src/pages/en/substreams/public-substreams/substreams-dev.mdx +++ b/website/src/pages/en/substreams/public-substreams/substreams-dev.mdx @@ -24,12 +24,12 @@ The goal of this page is to help **data consumers** answer a single question: _" Substreams.dev is organized into four primary areas, each answering a different discovery question. The sections below walk through each one in the order you'd typically use them. -| Area | Discovery question it answers | -| --- | --- | -| **Datasets** | "What kind of data am I looking for?" (browse by use case) | +| Area | Discovery question it answers | +| ------------ | -------------------------------------------------------------- | +| **Datasets** | "What kind of data am I looking for?" (browse by use case) | | **Packages** | "Which specific package produces it, and what does it output?" | -| **Chains** | "What's available on the network I care about?" | -| **Projects** | "How have others put this data to use?" | +| **Chains** | "What's available on the network I care about?" | +| **Projects** | "How have others put this data to use?" | ### Datasets From a0a34ef6f1cf3a2946831326e263ec15f6da22a9 Mon Sep 17 00:00:00 2001 From: Brandon Kramer Date: Fri, 10 Jul 2026 16:59:18 -0400 Subject: [PATCH 3/7] ran prettier on everything --- website/src/HomePage.tsx | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/website/src/HomePage.tsx b/website/src/HomePage.tsx index d2b1e47fdcdf..9bac8230797f 100644 --- a/website/src/HomePage.tsx +++ b/website/src/HomePage.tsx @@ -128,9 +128,7 @@ export default function HomePage({ supportedNetworks }: { supportedNetworks: Sup title={t('index.products.graphNode.title')} description={t('index.products.graphNode.description')} cta={ - - {t('index.products.graphNode.cta')} - + {t('index.products.graphNode.cta')} } icon={
@@ -141,11 +139,7 @@ export default function HomePage({ supportedNetworks }: { supportedNetworks: Sup - {t('index.products.firehose.cta')} - - } + cta={{t('index.products.firehose.cta')}} icon={
From ce4cbf9400cb163e15b3bfd01ae66b75cc767557 Mon Sep 17 00:00:00 2001 From: Brandon Kramer Date: Mon, 13 Jul 2026 12:50:18 -0400 Subject: [PATCH 4/7] reverted indexer docs back past structure --- _to_delete_claude/link-fix-wt/HEAD | 1 + _to_delete_claude/link-fix-wt/HEAD.lock | 0 _to_delete_claude/link-fix-wt/ORIG_HEAD | 1 + _to_delete_claude/link-fix-wt/commondir | 1 + _to_delete_claude/link-fix-wt/gitdir | 1 + _to_delete_claude/link-fix-wt/index | Bin 0 -> 46740 bytes _to_delete_claude/link-fix-wt/index.lock | 0 _to_delete_claude/link-fix-wt/locked | 1 + _to_delete_claude/link-fix-wt/logs/HEAD | 2 + _to_delete_claude/remove-broken-link | 1 + _to_delete_claude/remove-broken-link.lock | 0 drafts/indexer-software/README.md | 90 ++++++++++++ drafts/indexer-software/_meta-titles.json | 5 + drafts/indexer-software/_meta.js | 16 +++ .../allocations/_meta-titles.json | 1 + drafts/indexer-software/allocations/_meta.js | 7 + .../allocations/action-queue.mdx | 136 ++++++++++++++++++ .../allocations/direct-commands.mdx | 95 ++++++++++++ .../allocations/indexing-rules.mdx | 107 ++++++++++++++ .../allocations/operation-modes.mdx | 86 +++++++++++ .../indexer-software/allocations/overview.mdx | 59 ++++++++ drafts/indexer-software/auto-graft.mdx | 70 +++++++++ drafts/indexer-software/cost-models.mdx | 54 +++++++ .../deployment/_meta-titles.json | 1 + drafts/indexer-software/deployment/_meta.js | 5 + .../deployment/mainnet-docker.mdx | 131 +++++++++++++++++ .../indexer-software/deployment/overview.mdx | 47 ++++++ .../deployment/testnet-docker.mdx | 51 +++++++ .../indexer-software/dispute-monitoring.mdx | 44 ++++++ drafts/indexer-software/graphtally.mdx | 89 ++++++++++++ drafts/indexer-software/install-and-run.mdx | 118 +++++++++++++++ .../indexer-software/managing-provisions.mdx | 113 +++++++++++++++ drafts/indexer-software/overview.mdx | 79 ++++++++++ .../reference/_meta-titles.json | 1 + drafts/indexer-software/reference/_meta.js | 8 ++ .../reference/agent-configuration.mdx | 118 +++++++++++++++ .../reference/cli-reference.mdx | 99 +++++++++++++ .../reference/error-codes.mdx | 99 +++++++++++++ .../reference/feature-support-matrix.mdx | 71 +++++++++ .../reference/network-configuration.mdx | 59 ++++++++ .../reference/service-tap-configuration.mdx | 123 ++++++++++++++++ .../indexer-software/subgraph-freshness.mdx | 37 +++++ drafts/indexer-software/troubleshooting.mdx | 44 ++++++ nginx.conf | 5 - .../en/indexing/{ => tooling}/firehose.mdx | 0 .../en/indexing/{ => tooling}/graph-node.mdx | 0 .../en/indexing/{ => tooling}/graphcast.mdx | 0 47 files changed, 2071 insertions(+), 5 deletions(-) create mode 100644 _to_delete_claude/link-fix-wt/HEAD create mode 100644 _to_delete_claude/link-fix-wt/HEAD.lock create mode 100644 _to_delete_claude/link-fix-wt/ORIG_HEAD create mode 100644 _to_delete_claude/link-fix-wt/commondir create mode 100644 _to_delete_claude/link-fix-wt/gitdir create mode 100644 _to_delete_claude/link-fix-wt/index create mode 100644 _to_delete_claude/link-fix-wt/index.lock create mode 100644 _to_delete_claude/link-fix-wt/locked create mode 100644 _to_delete_claude/link-fix-wt/logs/HEAD create mode 100644 _to_delete_claude/remove-broken-link create mode 100644 _to_delete_claude/remove-broken-link.lock create mode 100644 drafts/indexer-software/README.md create mode 100644 drafts/indexer-software/_meta-titles.json create mode 100644 drafts/indexer-software/_meta.js create mode 100644 drafts/indexer-software/allocations/_meta-titles.json create mode 100644 drafts/indexer-software/allocations/_meta.js create mode 100644 drafts/indexer-software/allocations/action-queue.mdx create mode 100644 drafts/indexer-software/allocations/direct-commands.mdx create mode 100644 drafts/indexer-software/allocations/indexing-rules.mdx create mode 100644 drafts/indexer-software/allocations/operation-modes.mdx create mode 100644 drafts/indexer-software/allocations/overview.mdx create mode 100644 drafts/indexer-software/auto-graft.mdx create mode 100644 drafts/indexer-software/cost-models.mdx create mode 100644 drafts/indexer-software/deployment/_meta-titles.json create mode 100644 drafts/indexer-software/deployment/_meta.js create mode 100644 drafts/indexer-software/deployment/mainnet-docker.mdx create mode 100644 drafts/indexer-software/deployment/overview.mdx create mode 100644 drafts/indexer-software/deployment/testnet-docker.mdx create mode 100644 drafts/indexer-software/dispute-monitoring.mdx create mode 100644 drafts/indexer-software/graphtally.mdx create mode 100644 drafts/indexer-software/install-and-run.mdx create mode 100644 drafts/indexer-software/managing-provisions.mdx create mode 100644 drafts/indexer-software/overview.mdx create mode 100644 drafts/indexer-software/reference/_meta-titles.json create mode 100644 drafts/indexer-software/reference/_meta.js create mode 100644 drafts/indexer-software/reference/agent-configuration.mdx create mode 100644 drafts/indexer-software/reference/cli-reference.mdx create mode 100644 drafts/indexer-software/reference/error-codes.mdx create mode 100644 drafts/indexer-software/reference/feature-support-matrix.mdx create mode 100644 drafts/indexer-software/reference/network-configuration.mdx create mode 100644 drafts/indexer-software/reference/service-tap-configuration.mdx create mode 100644 drafts/indexer-software/subgraph-freshness.mdx create mode 100644 drafts/indexer-software/troubleshooting.mdx rename website/src/pages/en/indexing/{ => tooling}/firehose.mdx (100%) rename website/src/pages/en/indexing/{ => tooling}/graph-node.mdx (100%) rename website/src/pages/en/indexing/{ => tooling}/graphcast.mdx (100%) diff --git a/_to_delete_claude/link-fix-wt/HEAD b/_to_delete_claude/link-fix-wt/HEAD new file mode 100644 index 000000000000..ff3d214b89e9 --- /dev/null +++ b/_to_delete_claude/link-fix-wt/HEAD @@ -0,0 +1 @@ +ref: refs/heads/fix/remove-broken-link diff --git a/_to_delete_claude/link-fix-wt/HEAD.lock b/_to_delete_claude/link-fix-wt/HEAD.lock new file mode 100644 index 000000000000..e69de29bb2d1 diff --git a/_to_delete_claude/link-fix-wt/ORIG_HEAD b/_to_delete_claude/link-fix-wt/ORIG_HEAD new file mode 100644 index 000000000000..ed9885610fcf --- /dev/null +++ b/_to_delete_claude/link-fix-wt/ORIG_HEAD @@ -0,0 +1 @@ +7ac60b27ae9650559dbf483ca7cab0c61175692b diff --git a/_to_delete_claude/link-fix-wt/commondir b/_to_delete_claude/link-fix-wt/commondir new file mode 100644 index 000000000000..aab0408ceca6 --- /dev/null +++ b/_to_delete_claude/link-fix-wt/commondir @@ -0,0 +1 @@ +../.. diff --git a/_to_delete_claude/link-fix-wt/gitdir b/_to_delete_claude/link-fix-wt/gitdir new file mode 100644 index 000000000000..2938a76bf930 --- /dev/null +++ b/_to_delete_claude/link-fix-wt/gitdir @@ -0,0 +1 @@ +/sessions/rcw-01fzjwn1bbaygchutgdu2p81/link-fix-wt/.git diff --git a/_to_delete_claude/link-fix-wt/index b/_to_delete_claude/link-fix-wt/index new file mode 100644 index 0000000000000000000000000000000000000000..d3647a8d771205f819d3e53ff140a7657035489f GIT binary patch literal 46740 zcmch=2|UzY`}qH{?^_FPwx~oy_LNGN(n47(Eoh9vSZ0{TRw3GmMA9auv`dRhn~IQ> zQc+T*Xy5l;|MS^q=9rnf@B91vKfPYh>r%JpdY|jM&biKhKCY9!T@VD3Mi8kr;a(fP zW#1>YlM<1VK@eH3N(5O_41Vyy|A*}VsTf`>rTsEJdDMy-6-oK6`OK%g5jFE*7A=C# zW`r_XY&uYhAfz5r68frOeKNbPulph;ZA*%VeJ^pHSp0JKk#gV7h^jfA6Ukt5*);QT z4yI0$z8awKm7si5OD1#8KQBBqs_*(r%iyj@u5|{XKc*l<%tIO6FkX-ahsI_^b2%0f zydXM_8%c?yGPo2rof@2A&I$Wdxocq#axeRAlg=QORZHUE4lQk8fB)LpC6BivgGD(U zE-Q+WNT*Pvqa*nc$^NN>{e!HSdvbgD%DEOMH`=uWjD0hQP*+x^i`v7Cj>m0bF)e5; zW(XscbR6k_QW9~v)We<{%8jRsf?95xmn+5>^GuCOWLug}iP|H~Ve^=z((rSWNST zs7N$Gs2y@rm3pKk?70GSlqX(ce)rmTXN~#!54kHni+o&CCp~UQOeAu6k&&Pt#PH}G zE>0r#lak;xz#N79f5;p&~?Il*5XqGeg}L+E$>^E%RO*^ZN@H> zjYxm_YlZ^}#=#AjvEt`s0PE)&q8{8dYfpkqWbT^ z`lVUL_cwjob*ms|Q*z>sq`tR}D5ts%34aUe2W^K<=WzI5k*L2F){kuZkTzlBbtNm` z?s@YLHX9mp8?}x4g8bH_{F0(7k#nzy|HF5ewdYJ)9kB89$>j6D<(md%nH?U9^uahp z;}>#18COyNw87<<&M>=d@a6FS<7ZoctT(&o7pD5nd&&Z$o|AeZ=aBIvB@x$lSTDkw zd}+MGi7dy~Y2U2m`W{S*dHOVO2N73NuUMyGdM#F9;{`b&3H|qb=(h;9KIx$o(mgls zYNkcg+ww3)oBHL5yg4&EicLcs45nvXJ)X~jB=mIj&?95kylroW-4(?Hdsd}*jOm#4 zc;CDXR8Oq19)C}~9s^0}dC)^o{nDB>^K#DF#rRyE9xMOm$C#M*8(c)gJep1Cav4G+ z7_3~P`X0jiq`oWrDD0CD9u~m$nAd;M-1p(B3dSv9JjA9)QP~k-{1QbBU?k}4g7qP) zPYRD%${D(=6>RZI`Iffmy!PG=n~=WdTsoUg4PmjPEPA9$33?yFdZlkvR9rj9o|3b$ zHP1Jlt+#aak$}PgP%i~~z1=3bdbpWK1*1_R;v#DQV^}Xz^<`k#lWmmfKGW*M1DCeg zjX%8Yrxc`@7>;m5{;2m!54{`X9lwOSbVV>TY%SMa(R-2ldlk(Y=_OR&C@O<#PHL4{ z-e*1Zu2JG#N%FQgh)T|rzSw0xUghfYvY*I6VZC6)5lJUUQG9>|KR<`{OD_sGed(J? zU*g_eqZ_KM+P(Q4!?p;F*93l!!u1pRokFG2SUe_|Lz*Ii^8)4|X2|tS z4#EXm6k|5}q%p&KX`mFlPK|zu@(TX$PKiNA7Vk9djJf zaGCDu>pj_drtf6WNqCjR$|tJtHLOosFXid%I`cf=Q>U(UQL5+LPIr8DZXlxUicLR4 z7?JqogRH-z`rg3$Ovcli2MxYh;yC)jYp0?)H|vMa*wVNSQJ*&1#m&>ljWS`z1Q&NV z)Mg3gdkgE6ol#cCx{!GH)1(DKaT7XwH?s|&^|nD&NPQlYeF+Cj(Dx43C$l8L_g1Z< zQ)*)O4_oAGC9`=!S?C-@Nzhm&=y?z8QD1B0YL+wI#p%dhH)o{{3u2Wj&d5|E{i%_m ztVjlxLSs|oBI#^%!Q27UyYMESmw_bW`vKOwGF2`6&~{#tlev8V<`=hZPADy3Z|a9A zGr=e~9@9pci~CPh-$z)Ve6Ve6nRoF424(W$VMAJ`_w%*L8u1ZPji%BfsG)Q)sbMj3 zjad2W^a4mplWhDIt9d<3vwv1Dw-M`3vUvG_OIo)OaT? z^F|;4dZTIYy2^b>!vBxuj{`G#7LQAb3j@;-4gk?P!Uf05{cS2vsy z@(a;&qmn4^FSxv4=A3nkS!vbrVBpzTiFtbZi!S^5z25l0C~r7bOnHL`>S5&tk|=LC zT;AF!c?Tog-oZyl~i%Pt_y+BqG>Q@!Mr|euYJpQZqK(%_FXPXLA>WnFSm5#2gnurYh6E7Cce_ZomoJIPd zltdh4VUBdZ>9v)WL-!u=yOr3Sr@n^9RoAk7jOdASh=1YtxTIcE68hy~{ZeK6SAO*8 z9?|_$G{CQ_!`D=y?v3FmWT>cqawV3=icSDamz*fVWu$&m5*!7Xg9NXqWsgnIeLT-! zm;T7@w#M0zVN7R4Ukr!NMZxqy+1it)^YGyC`3=Mf2hOknpxcDW^QQWi3Gr z#pq|#EclV<#7l~|GOSNa*o@_Kymz zA946Aq|os@+CRbl-Kb;CDK8$Ya| z?-$>pibLl;|KQ`_>6R#|{5&or63j!eCPC^YC81vp)-S#Iz5J%;p^YoDy>nQeqN3|8+YjaOB%YVxd=YO;nlf!P*Lu9#0Nt9o! zhyG{!*D9w!f6idqmX4mr*i%)tVD`pu;`|fG215^YXb<)w&?QPtuitpA|5gN&(BB)@ zFC8++B?0H)+7SIfu(;(6|(OBpqF7jU$ojO<2SpG-^N7OyoY_uUjF!=lR?au$g7Kjaa=#!ptHoy8e=KMEvaXJ3e` zc--#zm{b$nO*MUIyO~gaEt|cu+`ZifQI7`eQ0m$NM=T34Pj-J_H#u zTP7@JS?CS@aK)R^dVbs5KliPtBfT+w=;j7CVC5?%%PFc?2i7a)blWLr+A7nvt4<#* zXgR<(KT`48CJ^W)maWJdM6NawaTe9v57sNaepZnAVDs^b3IpAlFSB0mv{UVEu^dtB z*{US!>ksRbN?+8LBb%*e*gdr1XL-W-CF4VXWoaYITpl}!B^(~S9*UN4Agm9`*#3LZ z6XviZ>`|sNc^NfjN)OZJ?GaUC7sA4v&Wr_4l;-d*aD<7CO z9=qR91?fxbW76Y6HD<<=y{bgJb$jTI9{uC%m9S|))1_wC+Lg$a)b2?SXh-xRz39G4 z6qqCu2@8*vgnFe1>(>bNf3Ri7sO$DCx4ib|I(l?p<@kTjM6`wVlX~$5M+tiMVZBOP zQ{QOKuxsJXt(V`uI^lWKY#X2TYmq*rUeSgnL9YR<7YR7=Y5()#2VT{i4lRg#xpm$5 zt1~m7AOrY%SsX46tm8wj5XA9@7oMMhB-)t~q+cq(_I=In-M@H_I`xfj@8&=JanwO8 zArl$Q*Ut-zWPpw{D%8R6pxTlJ7X?pBhVr-KAu_|d?NzA49V&gs` zIG8fY+n3@=kE6^$*Qf+>7sD}yII<4;-qsBXU*9b((KXnXY*u-*sO4A4Z^TrLpC&{z zC=v7o4h4*y>2xN#GS#y_tGuYi;(|)TE;ERy^>XK%>dNMW<5p~aOWS&ZG4}iUsVxS1 zV(Xd9w8<2=cxqHM7&!};wXk-hy8QvhK_$T%0de}x&pCLa$-MH2%YWAVu3L*NyYmWwd%|57#B!_YXNa})JAT)QAatjujKJH z$I4Ix`(xiiM{k}hwtl#R(O0NAPhx2mi2XwcFl8dxp5jGP1@TiK*M`}LN`hwz@l-2*cDQ*m-|x^r zxP_&+YfO~#8B63voY;0I#1oDn>OXZ)1I#W|5*#atBQ4dQdttGsQg!eR8 zA+s~cPzgNIZUc*#dYu(+7mx(U2I8pJ9H?>Fzi{;Gv6e|vecMc24;iMK9g9ZBi{mh8 zEYQM0Ru82IqKl}3Q3*K^$Z^W$p7<`cJQ7A=e-96Ek~uX!jDvlEpB#}4AC(`GEZ z6)M|2Yr%r9SqmcE%X&2_Aa&0X3o&-O#e)MMY_O{B1J=C3((6nn2m67DA!gUBG@J({ z!Lx^W@^=m%PTKI=xiX#WJ6%`j=gE52txDeO5hF3Y$>`)9;AT*n!if^)Xg%1CaZpKc zMnRn3HyiFfUE_E5+_+&bbH>lJEpxql{O0pvV*6u~)5C)(r`NPtEKaB-I1Ug;*<-JF zbMVO*eUcX4cPoGS%=T?{E@EtnjF4mxx*On12ipUYoF0Z@ygjl3q$GHwA)fTF!6VK* zxqeGk&MWJg&Z&1_O16Ds_f8R;w=la<9+5>{cq08;@BQJ0C=ZncZw$m!`PiyrFFo#R zm~Z;IMA@D6uMY#0&nOp&?Qf=8QMg1-2BSh&q@^HV^=X)i*@a4i;|Ot7J>pE;?|#&8 zFCS1o{H)`iqRAg`7X>~*Mv3ubkJLYr0V*Te*G)#ZoCI9$5tH>$`%p=6$3k4?mkWo) zv?(#4ug%ytuc<_8;i#2kgDW${wsVh!z+ir}X469%U=RmdJ)0E{PCN#NiEHQm&oyFv zR1*Ag5WgSWXI;yLBOhl5`0sT_mY=%w#5cS?+FNWr^`vvriEhu9j@mcCF9eGtDhbYb zh$9#DUhUhBbG$d-*Cb^2=h;sm6I{Kjs$Fb-9g1#SxVR#|h%- z#SIEtyV>dIV^`-TeTwaW&d!|u`+mZC37j~JGb0kLbc6~w1=JqBBU9Q*NpL1W9Qkp| zrSs3X%{o6nyzJdO`Iu{08|)+78DiVP3|3?UdS(PnR=|=|Gz+Y(5GL{Sq`vL|%zvmP zc+L<{#&-APKC)7!@9P>~I-DDs->(1ADfrhXvF%)l7ad7W2xWs~2*Cm(YL|ZX2h5MC zBzP_mPwv_2XfLYb%wvm9mfkMdm)3e?SZj_Jiw|kfru@9Hzee-gDgUl_XF6}b6wKqJ1@lTT9-W;qkxu4(3Hm2O`VqhK3Hy(R z_8m}BcG=7R-AUhRKYV;x-^I2gpD-$$j*h8#QRJ8ktq3T`_>m3fFH{nCOoBM-wB09S zpT=*f*!dx?dP$x8;9>K^p0_)R^_LGZUnTRsP&*nTa}tX`DhZA|#6jlX+)-J`3JjM1 zUUS{@f?3Aru_M@Lo5kBha(p6rLIWz)p5coI>yeV+Ooli{`ZA+GRL)=HFeCraF#qu_ z^mVnok8KkWOEGzuw1)#`FT_Y-8rbs&RROaM<(RcE!g#18cvB#ru5<4Jjm4L4=X}*H z=%-m+p`mLUmv-768U9BeG=V`mBTO%1{zE0fnF?{_#%!zdo^ycRlgg%rF=B=KjS&wX;`)Ik^iPBI>vVK)Kie|A&EDQ=i_{72kali!`gkdC zvGb$Z)W}GXdx&12p9oMpDCU$xQW6{wh@-gq?RA=F-tpSn&TRKl%eOwAoG{bBqQ6)> zs9+w89k9R=nBHkeuy{~_B=mbi`eoHk%k!sQk8!zP@VeMi`{0I&_Xk{mVvE>_i3h45 z%#$g!NCsGorf?X+bg)7V25D@v3h?tOW!^{3f2bt5(;=?(K8Ga}>lkbAwti8h9%rtd zcxwMQ=QZ2^$VCr!f#Kl48EkO0!i5C1#x8G?Tf!?Rausj{&K;@J{8K)GV_%&UU=L6tNN) zM;@2u7Eh<~xO8$3jgRQ3S@A0;kq;>!GjJ}D1lI@R%5Aw8vh&v{^@@+aU%vieMNMW$ zo!7lQNbGn%i0JFlYY0Lh)Gl+G2F#zRBskzWmvH|vx+dXu_G(+h{Q0kD`j2X!liBX| zaG{^rd`L_!DKs9aF9MJR&P<4d^q;=w!^;7AvmL{AY)vh4(k&wCv)ZWTIM!c&snl!=UoH`>`0)C zIQW7qxb?yykeFSfyx9;Bakt-bJM34q?#h&cHVr?wEhC?$mY8S$iAOZIV9*9wOePrO z3iD?43&6NQ688B)JUQCe=Vn&C&aJJx{MBpTUa~j%l^i>H45BNhK7xEg;gQzh{jfQ+ z0QVn|g#I~@e(Bs*dt3EY{fi=&?b**}()7K`2Y+&TE_Qwl^fT!caLkv*7DS2QEWVG| zJ0JAB`2%2PK z{;D^{{RSk#n+NffIU5t6EtJWt>$|~BDrb#TUpuWDr}xEw;7O_$*m%Z5n^%Z(QAzOT z!@QP>H+OwjvETChjfKPB=XB{=I;9yV)?&xe#A-5`GkjUoMDm3go;h}yyVQEJClZ@+>x`oFgsC6a2G&ay|ma|`xV#socAn> z8aXvkRwX$5rejlIgd&cMt_Ra8tT-lrD}}-(XLope5W}NFJmhTQB;}-)6MQefQq4O$ zaq;QX8$9jTb%@RPApde$Y>|eC*|qi+ZWoY*T|p2>!DAU>etg|nvkS*}Zn_!x^qv1* z&Sy=%oPv-ig% zlFP-8L%`@cvk_oIY^Nfy2vxJUg{o>^d-? zM@JV*p?qw)QVX{WNP+_{s|s;sMy76{SPzcM?Qd=+qY!aSo+6j0Tip0(|6!+!z$F2^ zR$z7lNYN-AF;B~-P~*a&pq)`U&PKU`SvjJ1tFsHVVov^ zJyH^!aEK$lfEL&5(a~4YQ}#Hf-Hu7Ia*2LyZ{hvtIEh=uAma4?0d5zN1TO;ODYTEt zIcey1_~Ve{U&=yOyoFI7!Z5g^D_DI*CE-VKl1-?7NcW|kKj;)XNoB3#0QZ~^u20u}S3N#D zSL}ESJ3K)NrgEv!3=H*~7!DWWAQoEtTaSjh{JhfJaHy|e_`S3S&jl zDM6v;oLF?b3%A2qy%6I7N!Y=I^hhy1a@l#t>qjJoxj3La!5(=z-cBSze$}e3C#_7@}^?Z+C86lmSlHv?vzYtdW+2$ zXd?m@j}`&1Wh~Cs*^pBT^Tp5!teCGPpY@%-4e6K?*C#- zyqqw!`HBp7$$An!2lpqC1TPWdDS4b2*!#xCQRc=w$E&=Xp{QgXW_bUqCSoh59uhns z!m1wIMx=Z3`k7pS+X*DWT?lbySFF>kJZM|5JMq8}YrACcvtg>=k6s=jwtj-Q4%i8l zARd>?0wZmaGbNZmzm?)VAPL?gh^Jh9TsvfpebrpEw0G~6WKMWx?zpJ)d8*ic8t0M0 z1FZqtF2(H=JIQV*n_-8JlWyr6YNuZ{pRl;p3|-VLeX~cE)I`gVtD{D6ca~m))L8xV&E$fsQ+y2$}#_; zlF*+F=|@iF{QBlzx#w_8-+(yzYqeae^@i_X>c!6g_*;3zcuGt=uyOkqfN_B&cqtH1 zD!W%ZW3smsV^}ur%t_;W3x9n`dbjnP*nX4GBSVIt48Ziy98*Y2g0lqTNLzf#tGiZO zd1>4Jwyo!j4j-j)M_s+MMr^((PY(yPup7PPNefJWnlx??kOU_c;>e#J{=mL;!~1rZ zXP572xm{>>n-no*W1-mkz(%i#aw*YZ%a=b-;kPb4|J&rc;&uT^@RmY6sX*&T?u@Yt zyauEFSzmi!xR<%FzA$!;*nSz?m$V=zDFP5?mna8J8in#c^14uAw(k3qNX3LVOOB3G zSuitQUY)HfHXq|0{v?GYVVt7n?W82^Sq^ce+<#XjzE~F&cUkwRmi%EA+UuW3W>#PP zBPW&~3EmjtuThcuNl9>4Kpf=z`qO2Pf9xrVzZ6)y`RMGafoJVAr|$cM--yWxX$=vd zYaV!ffFw98A&znd()7Mt8gXn)F-h*dZj|$Yn~n2j$B3Pe3sTe&I+4K!w}!}OhUHz`&@MgHUQ`m?RWMh=y1lsmOcK|J4p!#)!ylYm{0ip+ zNpQ0uuHt|t3d(-Skb$39j4+tJ?L~;$nS`{7bH$ENIdqmq5SDh|MGTX(CDpn-xVN=N1BYVs_bS zoM}h>iAsW(4e?Y~+K*_xI{)hEq*ISpFV9OK-MxF*aZPYfN=(1P;ZoULay64*J#mit zgaC{KB*9q&aipu;RF#nH^LpR%S@=`^;Kx%Q9=Ero%@=PMmlw=nQOMyBc&30F+0(AE zX@wXMNP?FG@no~|-R?gdY!f@b<#U4Rpvi;RzrdpiLNiX3XFr&Z z@lZ+d)>(KYdkr>SS3SPvaFa)(9Z}0X_ z&)P9QkOVgm;>xPZ4Vk;u{E=Z-uZhn(#+*&bI=nOWfved5n$L}7gwSaTG@*St`~4@e zxS^8Ztb;gedC%8pIOm-im>YC)wEiT8#QI8PfzoEN>qi0(=um^fGA&+7Fgxy~;C=*> z;N(Lb1;fac8p9zI_q%<48)tvHB&Mq$<6`6?vExM{PAErs#~4eOSp6S0iZ=3@76`8;3}SQQInMDvIL6yl5+nWr5_arIDp zQAuz&KwLvbslAJHxz)zIUIk61-m=fqNxGmhVB^2$3iS{eZ|OPAzYahW+>H=dZDFM9 z=o0CTepatj?d~kQvU@!8aP7xFh_kr7LY~JEV=ps=OTo_~fkid&2o=A#!0W9;WgT7) zAc=Bpg36(|CMPAxeomVU;^S!AeLAb%M8ClPDMReImhX2Co`CQMgKpttSsb&wV_G{Y z3EpOir&9T|R+IX%GyiRI(7p@u>xMsH?zqIZRD3=aEXxS5n4tPckJy046_o_10OBZx z)eZ0KAa{3sLBHWkH$?l?UDe>Mqy~xIzs7E8pc|l+7#>&zz|uIFpMyP0wovzk)nhT- zEf5!}__=ESXdl}8`qZr58}bd86(7$m-)$ees=G z+(rXQ*jET~dXI>0UOAG!{zUDB`_n)7Z5Ztxp;)?9MQpt#4^fhv@?;m)R;=Y;PWr9lYJkR{xM9SNBcB8g;S#Jjv~`v4?SL%nM0LaJE4lskG4^ zdtD|xvprn!+WE;1t-Z_T(*}(^E!L0VG#tM04^~yMNwOf%jqWVN>j{tqrwHOGZShTt zT)R`l`m4(C)ehBbPb%#(%Q&9O;663x9gvSd=!oD34 z4|(1F;r!6wp31o{P&f|vBC!wzrx`Evr^wE)E5-5RJ4D)L0 zc06{!^y9r+t45MvgPX(V)In3beEwixTo{!*nd3^_i2!H6$PppR8)MOp*@sHPzMT+H zspON!2vgTngEz}mtzs{VU0hzby3Oq~GEPh$MV}A_r}TV?bn45Rfu0fMgh^P)k-*;t z@sT6OW!#D!l6=JqW%Pbs&tJ1w}U2M&dTy;yYh8oxmw57t}pKbU^c)OJ!5e%uS| zSFWD#%>4d&zAV>xgo(%4&f0~H$K08Myo`^?I2Ivvuvm&EOEw)`mZ392rz5y8K1P(Y z59Y{^+qz-;3HfT*GNY{~?Yrh|>L*>&R3n&Q!W?jUnFY)OJC@|Fbi7{^!`TmW2G&2h z_x@Df>n`SMQ$xD{lPQhm8m*~f>|w-XV@$Ah4$e%`!1dR^*i!;?`dis6oK}DGK+CN^ zZI8-@z=Q60lk?9C&ZUs{M1dcI-SS8^jtQ; zrQcFf{lt}33XK6S?_z-`<4sB;?gwH0HkZe~QdvBFV2owJCfe-u@kiv_&Ur^8{mAx% zzG~nO7T{-~J3n0TY=We6AAJJ(#Dw@T_?$5h`vzVae z2}&=q{6}Gqs@ZqdDT6<{og6;y#hduIon19Ix?lYeoL?5TV!IVMscBcI;%w?A=UW@GrEbq-sX z+TENqLLvt||K@}5#{P{{4s(>8GrXJX^IMgFZcY9cKJRF*)SlF& zgYDX(ArkHI#k!+E*>M`yFa5pBO>emCiE9Z{-@Wi_W>OP754qnGj01bv;me4kPX^0M zd@Cfz;|$D^J+*ym#)$VXU*3J*TWWQhip7C(HB$X0`fCc(E^b-740du4j zBixU!QLsv?RVOq?jF_86%yMcw(1EGlJnJBSih`qR9W@=w^Iify>8p^U2XQc zmMN7{6OsPH`3m?4jG1ZZ6O+XIG-&=K%TMINbFg0N0+UYJbK|)+2HmubU8T3H7fUHq z@4WfmXbJT@Ab)_% zC?NM)Ov421Z&CeKuzs14=oyH=-LJ~7(}&)gDDQvLZpP3F6ztca^@q^!;p*oCJOlEr zz%QcuFTnbx^Ts|bT=hvkA-H~)#f-hC=IziF$Gcr(&exbU8hJe&dNU@?*QZ#N$$={za1uG5tUi`s-l*N>{Xdr;RZ#H9G4ucgp9V zo4Y-(J~>=2m=_57AH0Qu`G*6Z=nkRsBDoe+^vpaNaFRnxf_Dk#4P4jauu%5f>v+cz zFVyD#NYZUR)wV58unzb~9@;R-@Zr@!_iOAz-e6h5 zJmil&C}N~tq$KRS4D*y4wW@!w)C#XGTfnkEmUMK&x$RC*ivJ-Ge<2qgTuF{!1I$x? z?9pZOdj4ToE8Q@qbgUPV~CzimI zV>6lHajIx+tkYv2CfW|0V4j>qdDC%|@73C0$KNSxR!Tm!*s|)R(0Nf29=e)IjH+=K zSszJB)XQd=qjEIs%I52NQt4;Et-cu_d~s;U>6(Y<1?&D|IrvH#cnrZCn`eT-slYru z&#YS2j&Xq`xVK^Mux$&Z)^L_R{G!)-{?VAU1$kle<%@T~d72CtR6S7rK8VIdv>(PK zp}z&vukAOyF7&(n6$6F4&UXtr@inX8&dxEBf%{2PKejLh+Bg1u6Q);hCE5@8AV3oO z??U-lo3jMxL{Yz?2bMS%^T70g8cFxJm}hQoZZp!x zA3O(*W-L-aDGAO!m?KLIsB0an5Xrf-$jK{o9=E^J@ln^7!}Ek59Nb+vL^7ux=Ex<~ zcHQp$amRSaym`fW6RQS{$$sutDL6MT#vTqYI-12sSN4bl8^BgZFlnA7`|iVBtr4|q z@1Aqt#lD!cvhP6b02NL>L25~ zb6SI(Tqiu9!TlEqR!ex;XEbmK85dF#@p%aA@54^HFjaT6p2pg_mrI(?U)3CH>X=z8 zIFBbNKb>ho4MOL<$^&LfzEn68r=ImJb8ozbaNySlrzR-_uOIAA7N&xP&4?`Z~G z1V(|AwD_~jU`rZ*x|+0yl!V_N_u#Sa?Xbw`7qKAra`~Fe=`%Bb&M}^NQfQrt-+oZL zARe($L+U3b!Fk$)!(ghNbRF(MeWp(emteu%gn?v z{_U(!?9nG?46Lm-+Rztq5+2w5fg9Q5%?OU50GPdF)$~Y7*!=?LJH=G6m0z&0GVglH zEnVQxUYJCotqvFL%ZaZ)q`4NN{7@b`R_51YB43J@<0V{>h11i|oZ9^5;Z-Vv?^P(8w@7Q4tsIE(}^CQgF@Hsy8ZCI53n(Yf{@ve#54^xyi zrrSu!YcRJ*7a@W73FZyF>9k)@?Zj>)hcISix#_@Zq0iT(4}!;ug1Dg@VPFRi_ba+n zg`R<7g3*vrgO13w`*x#6`b3|PK4g8Cbe1!WU(fECZ z^&>{kAKUw7H_a-&ZEI4tYPC`L@Pxy^CHN8350*zI_j{teZ#{Tj{XJs)?X_*LJu$#A3iiG+R+<_Y(EqMYwAr`Jep>SmehG|FSWEAxyDrYOinull_maTMDh@Hrq# z3?}jAGrVf{s4Qf=2)~JsTYx0m;SZRv?Yb}4=kvqLaeJ%Zc9{E}DcE*>LurPDevr=x z4?m(c1ulbdKPbxm33K-ij~@17UErL(Hw=G!FPfEf;d7AelFNegH&FZMb49Hr`WsQ+ zFPNupvF<{RX};h3(v;;{%ofwSL+2guX-epK`8<)KGxljdaL)yMT^KhQYagQgZkX>Z z_1nqxGDEl5LPO7zac@nQ4^dKOUxU|q`R$U==YmIC$u0upBx>XRJCJxhdxJ;|pVvj) zRVwCre7Je=#IdnqU&1QQ_S0hMo$&gF7!Ej#%x^Ek^;eW91@q+C8XE1V4>krgZquJq zJMZb#lf7QiWCiC?#K#eR?h56RSBCgTlJ!=UD-ClOd@$Vk=3`;7!qDwe)H|bf!lt~e zzdKZLKIG3_Jkc`2rjURv!M`#vS7FNagn-SD;$j2Njo!{ovZ;ylUGP*zLVgv*k+2uz z(!gt`0xUkh5Vcnh<|5NRt=C((=kxyaeV(s2bu0G^2`mTi+wtE+gzN<;*;za`cxqH! z0+e8a}a^V94o=EDlpgiTj_xzeSUjw-2PA|vu#kWQgux6u`h_X*nUOeR}n6HRV*qf zG6CP`2d_1V9SebGi`U}~oA7ZTkVL#y;c{7AeDNy(zNU2CE{2><)SY%!*K^%U*2wIC zTQ006#YBQ=dE&}l#aOn z+j8L!qT{EssgblWdK6JUNVCKdeGs>h69TJ#^^N%HmWPP z@ZKZM$|co}!>$ODt_^RDW(OX9vvrKY*vE!<&pfgC zd#Hfy6m@q@br_=Pmksp!lAc7?Odjy!K;xE+H&0dS zC8yjdj}dy`4yso@ctZW8C}$wdLAHNCG+W<8HPq2idit`#)>7vThMd=z5I+GY2z(I( ze7hQKx`Vs2!o3KQuSL0oU~WG0z!E!neVU&y%JuQ_ERaO~(S`ZyTa)iA4oMqkePp0{{gcWO`<&bMHateg{yRSU z=2|R07`-Y3*C$cF9?Uo1bvjW0?%jSNmNL?jMJEjgZhbPuX5_!MAM{os=o^q=uFVZ$ z#Q({DeVDJ)W^OiY*X1L}t}U6Lb^h|0BN0ubySFCZG}RPLyX1^N<*+y#tkA z#nD>*JZ4VWC)Mb4=E|{^$e6#xJ(!N&ibQ)VaclnkahfQ92+WsK@j9UQ;M2D#!(LL8 zMrQonSkrv!+$IV0I)S}C`NUlE58Poe7a2yCFR{w1v>86X<%{p@lsnp%hP)`m^`F~~ zJx}!q2S})ICU7~VY=7(?XYV{M>g$6E-MTw+cmK%Vd`_#ZBZz!4a~mWt1dfF$zX zaF|b()v&JV^YyY<)gI>Wqx%OskLi`pJ|TE#SwcG#@;{$X4UVOPW6Z%sC6vH7h50%U z8j zKIWyz&UEgvAFH&}-Xm`Rp*+~sfr3u{!80PU{H7_P92B@5y?(a8uYRV)wt2B(hy$NyozxV}Q;o{d;q95scgpa?0B=U$ATn-rv`qR#) zJv){KhE1P%{DQ&r$Z>7bEB|lt0q4V`z|~doa3fEsBgNt)S{`e-Jbjy9pD=C6+)&?f zOha3?aOJ+~VUw=DLMHwPzku^Q;DT8s1>ERC-`FKxBcU8Na5-#?hIn_Z&MNFmU-8@I z+{3m$$%o?FXGxfk{ka{-pbvY1c|H{{fdsxS%vb8yPua#M`ta4S7qcps46SfA{~GIE z_@Cl}UFZWDl>$zyg12zUM`_5FF$v|dgUds$j{4fR;TB6iF;#W%i-XrJ4qV;e8Tg;_ z8d(Bxagzyd0F#TISUEnL;NyKDiTY{}m*ey~z4MMUXI|_ZP(4e=)zR*|e&25^{#!l) zLrn0wEx<>86T$|s_n@BxAgc-9jz!Dk0G9{xxSVvWa@CcFL(%K^#_Uwr&C;xz?flnq zr%*qPUnAuYNcaN*3H}%j^9?S{PtiV{nNzm!dY(eRT+J9i%An&jk;(tOy$JZ=n>bts z_=*z$91!LU3FR0Amt(+*7a>DGUdl|roT-2An)-(bPn{Uu?tfEX1?Avj55DrN34Y!7 zZ*g&i%QLvD%WJ}LHzUW0f=~75^-OGHN_DTj_&4J-B1GW%D4|6S(D6y|$5@yz7iMlb z?p3<+vM;=y9b?0GD(v3#RQ4t^`k%)Id{%+Y3Ic**?nFdy+sHtKxw^XF*0 zUT3eU{@7P1J?2zw*}t(Lv`#8G14&F2_|;O9{Z24nuK5u2V`kb;={Ys*i7^-7KcCR< z@HPyY^3Uz(^U>8Utc?o24@xF4$^MwoqdZfsmQR!mkWXB7|E@>k;;E5_itMzce=}a? zmxsL9i$2pX{AMXpCbWJ?^(rYOC6UKm;PN0=>u3(OM+-Z0&pRC0YdJXo(0AcxuT};hnD>1Dzww6irZ?)@wZ7(^EXEe8?683xe2n+suDuRkga!5(=Cc!*)ySlmwN0!Ca?w6+5 zZVhmqxZGrW%B;W6n?tA!HiZY?PK*W{qcq`dCagV*sc(~Eu9S2A-SEK9+zIkU(>8s( zG)E`3am~*=683!sc48-5MArqy@TS1Lq4#Go?fnCmXasJo_gni_}E(*wb zkqL?5;e#G=HGGYYqosf(_|ss%(V(p}OBHISmQ@yv8gx-@+8)EZ4bL`8IDaByFP+JY zA}73&i;-kYNi?vH+~GRzi{?Pen88|D}Sv=guUc?qmY?+Jrd=5!d#2r zMQ5xi32iM}I%}@H53Gqf+TFcM;h)wcCOB96B|!oM8wH3;xc9P~{M>`R#F*LuT=0Fzu&5_~V1KTv1L(Q`=E{pF8K%HAFJUmCAy zRB^^k!hV#9-Q+)jPi=s!y5MfK&=`W`l9J$i!+h{s;op>Z0kh|!w z>&T@4Nj^A50$$?8z$A~91lJelD!$&f+BC7{(tLA^9SH-Mno$l>NTN5wwpl zTFgq0?Qq^XXIJ^r!S#Rdr(iBNIL0`Zme~AN3P^%C7v|ZGd#5t{#YE#TRSRUUvF-*Q zxa~c6%dNl83-~;EqePI^h`c7sp9k}GelN3T%b&aX!<*@@|NfU1+cu&5bLd~|7oQJ4 zU&3WGz&kVGx(Fu$e6bJiw?z5#VZQDH2TJSF5B=1JWU5^csrLHS*KkUM+dt=Hui1fb z2!TanFc88Hb_myRQGNi-pS{XtOs^*9$JEswhQ*1?f;~RWx)wwIYy0Ngk1zV+pKO8` zL?y&O5auKLuV+r3a)ISMdzCN4B4o_WP4QQbCj51MOFUofLa2mtEa*{=`D3F$cV9ZX z)|Ev`c%jof(XE_n#QE#|;}7K^XNVH`RG6=3yiqCh_QG{mr!x{SmdBUUSYfYYPW*Kp zRy-fOSHcCK)Inb_i3$djLhwgIIfCGF$g&@Q8G6~po2C2KdtBCgt@x6h&ZF*sUB3}u zj!5*QXMf?-V7~bpHtnv-Tb%`T&BTW9g>^F16#ZY1{cFC3`Cx@nu=b1D?ZgQnC6R}K zSA@^IC|2CnG&|aKZ+XM`aD`Esbw{p@rp-Dd;hYUQoZwjSxuUBRB#)E?mkx8)YkEhX z)B8NTrpmkA<*>HXoZ6yYSv&uEy(4Gg{IL~31(IA+68sRDuRQIQnnK0|o@(N^3%5^n zd8=3(J0Pil9XIpsj!xi)iLS>;iTXPf=Bm3?XN)v78vR!3)zH>aW?B1Vr%pWk^RMft zd@dORupN)S+mA1nq1`O{SR*#VAnhh4VSgB0jzK0-diM&IhIx+Z`}>oBv{T7c(@8Hj z{B`_}y$lDQ2tpsg6duor+RcD@YTZ+PXZ79DVNmsXqiyoo=FjrJpYE)baF2&Hl4HS% z02|}@fSI(1l!RRoFbA2z@?Pla)3tqJ{KTe$NmmQT%$#)P{$J+_B#{zDi^lhr$TWuM z4^jIfVXpSC-;Vn{$0aY7vV7A)TXM`h!*_<3$6wFgKwSKTWPkB%6wFmkeUajN?paQd z>ssr3$G$JL+Z$KH)DgVfE@A(-2N%3=Mq(w|%Y?Zq?}KvcKOTyBu+y+um9wPjgWU29 znxFrrz1RnaNH7^!QWEiH!Cbi;%y1i*EWi6}D_*{DJFqdgb(1SNCoBFQ1ZgFxN905R zjjw3V;`bAxagK)h^2@U#S4@4`>s8_H=ID-#tGY5<=j43-Yu?~Rg8>8BNXAZjL(2-d zzXQJD^H3lOyV)=ondGZ`xud=NrKfVQ$9)uqcPugX6f;{MpY%1y*WvxDCA{ zyp(^o! zSJ78eE|)suU&6C$nX@-hZVvr6Z`*#!c~Xqu!R`$BL=1m{OhUa%gt>^5`h@VJo96EPD#&RHh9mu&5Zf9H;Wc+OM8{aW$$j)VIF zo9m+oH^I?%K{O=#V=-I~#ZfBPpBrBK-1WZey+P3)^YoRE^>vR)J_k$sLo|m-fYAIqPjq%?1y8RxT4IdE7zr1X~NFjS_gtFi%DP(g)2GlZpmbXl>UX zo1ppR+(ZL9NAh|s$rByuNZ_TwJk`=O*Vuh||D@->#=H4th$>;w_p3p!C z?To-53A|L8hZxFS`{lpZj(HciZVfqP zQzJE0;yz8!7cI!jBiX;pU>@?l(s5A0nv)gA9h@z;Rw#p17kqOY?MH)F|n*LbK`<1d*eXy&B0b#2m>tT6R)fi`ASrO zHmo0M`I3{3j5!mnvr6ZS)1kBMu!ip8Z;`&_c>pf@Rb*5#|0M!nZ#S?0v&Bj-3fsZzRH_N?Xv|1C~u zuy5NT)&?V$O&!cb*vh`G?Zuj*+B*zasvA6P2UA(}a0B+=50_lrJoBXIv&f-N^Ssn; zzHAB~&H*3wBFztmsIDTn4(kKK|Fm6{{NQBYfYHjEmJ>vdoEq}s;qhCjsT^$W6bDy3i>89 zg~ddy0Hbl)z>jr%_HDlQYp=$k?7P-$UCmdZCz8;w%W)7}@EbD4lcM#k15G-2_ulfL zJ^O(Dq0n~1frz!01L}vQOWR9UG;60`aaJqwrwohF-m3$K?1<$kTLXLLkA0hEGsC*1 zy(VtFIeo***2YaLwb&*sVrgRotTDOl<^sR;4d-`6#_47c_A;b15ld?a13TrN z8b8xx2U3^Kq-{UL>Z4I<v8#X#}50m=7){czffuWbYFF?5Zs=^YJ>cgB~d<=E+PJ{&u(>8dL=!V zd$yv-wMGtBnEbtuIJfIUzRfwImyfKL&k4A6`VBeX)lZ$5J^j%Ji0z?}}L+ zblRh9$K8GnDql83cnun>7wckMcDirY@RA?WD>t#*_j;#!qorV?f`FP~qij)NJ*gpZ zd*s#w1GOhDov<$RP2g(ss4-$`2T-HEH_yDim>x5wOU|}4E3UY+e|R~L0*S;9ly*t} zMM}}R-DPuV3| z{HSE}xK>@{TKZW(8=YBxR@Qn8*s}ZV;UaHrg)H^_hrtz4?Wfy6q zPE390p7ZMM!|JDptOiImZH2c+K$RS+TwXl?@mGs4Q&+k#N{=_bFz&csxq)C%jaQhc zQ&X23I+xbVbL*KKC-2@e&|Ceqkn_-*-F?NLw=wO~=LL?{4Ovq>KW|XqQ;mHEu3ewgP-_Z zQ|G^yh~>4XZ(VjjhPIGb}r-d?0`R&6>Y9jUu$ z-eSS?(r8i`sXXk)?aD3klu&L`+0m%e`U|Vf(%4|&NIcPpMPU3W_A%LkrvnGMH;&$Q zYf#_N_Wpi?Q4{8iL$~XrKdBn@D$)7YbZ*ASJ~2sWI{0oQ2R>MtGkbBfeS%+=y;~`> z{p#+o+%GEvJg_DViVk-1YWq1?EAeex`YqTk+(CW`nS2D>CNj z49kCiplptc_MTG>%s^SP6G7Ae@{BddC*96pb>IB0N7d1DTCrV~yQ0B&G|}hj5Gyo+ z*PAHmoq9X??e(9W;)h#XII~IJLi^awY-yGa{X6zlE+_2o50DJi>T2b?~ z1IXf`amuW{uhOZe?s2P5@kQ*-#MX|=^TC0E=mA?!U?85~$M*Kj_MOsFG&5XhU;5Hs z6}G8a8v_FwQNV&g4wD+q0r%g~Uv>cMmdv(FoW5(+O>?R3sX2RghZS+R8H1RD=MgFB zu0D8a1I#TLG%f`k55)GHu}1c$+&RJ9W}V73>sRdBlZ#lJf7iR1gChXof*pA05bLLM zW%bM7pI)q@)n7xe|9kb;)Xo$y@DV9qBpuV>>rs06I?H+3>iE(@D@vn$w~hNg*U|s* XPLFl{>K`c6^aFb}xTr68>-_%!Z4+*I literal 0 HcmV?d00001 diff --git a/_to_delete_claude/link-fix-wt/index.lock b/_to_delete_claude/link-fix-wt/index.lock new file mode 100644 index 000000000000..e69de29bb2d1 diff --git a/_to_delete_claude/link-fix-wt/locked b/_to_delete_claude/link-fix-wt/locked new file mode 100644 index 000000000000..6109a85e9ea4 --- /dev/null +++ b/_to_delete_claude/link-fix-wt/locked @@ -0,0 +1 @@ +initializing diff --git a/_to_delete_claude/link-fix-wt/logs/HEAD b/_to_delete_claude/link-fix-wt/logs/HEAD new file mode 100644 index 000000000000..a61ab6429d9e --- /dev/null +++ b/_to_delete_claude/link-fix-wt/logs/HEAD @@ -0,0 +1,2 @@ +0000000000000000000000000000000000000000 7ac60b27ae9650559dbf483ca7cab0c61175692b rcw-01fzjwn1bbaygchutgdu2p81 1783732562 +0000 +7ac60b27ae9650559dbf483ca7cab0c61175692b 7ac60b27ae9650559dbf483ca7cab0c61175692b rcw-01fzjwn1bbaygchutgdu2p81 1783732563 +0000 reset: moving to HEAD diff --git a/_to_delete_claude/remove-broken-link b/_to_delete_claude/remove-broken-link new file mode 100644 index 000000000000..ed9885610fcf --- /dev/null +++ b/_to_delete_claude/remove-broken-link @@ -0,0 +1 @@ +7ac60b27ae9650559dbf483ca7cab0c61175692b diff --git a/_to_delete_claude/remove-broken-link.lock b/_to_delete_claude/remove-broken-link.lock new file mode 100644 index 000000000000..e69de29bb2d1 diff --git a/drafts/indexer-software/README.md b/drafts/indexer-software/README.md new file mode 100644 index 000000000000..733efcebbdc6 --- /dev/null +++ b/drafts/indexer-software/README.md @@ -0,0 +1,90 @@ +# Indexer Software — docs draft + +Draft of the **Indexer Software** documentation section, structured to slot into the docs site under `indexing/`. Every page is grounded in the source repos now consolidated under `graph-gtm-kit/context/indexer-software/` (`indexer`, `indexer-rs`, `graph-node`, `graphprotocol-mainnet-docker`, `graphprotocol-testnet-docker`). + +This folder mirrors the site's Nextra conventions (`_meta.js` for ordering, `_meta-titles.json` for folder titles, MDX pages with `title` / `sidebarTitle` frontmatter), so it can be moved into `website/src/pages/en/indexing/indexer-software/` as-is. + +## Structure + +``` +indexer-software/ "Indexer Software" +├── overview 3-part stack (agent + service-rs + tap-agent), architecture, Horizon +├── install-and-run Install/run all components, shared DB, multi-network, testnet +├── deployment/ "Deploy the Stack" +│ ├── overview What the Docker stack includes + flow +│ ├── mainnet-docker Full mainnet (Arbitrum One) Docker deployment +│ └── testnet-docker Testnet (Arbitrum Sepolia) Docker deployment +├── allocations/ "Managing Allocations" +│ ├── overview Three methods + automatic rule updates +│ ├── operation-modes AUTO / OVERSIGHT / MANUAL + reconciliation loop +│ ├── indexing-rules decisionBasis, thresholds, examples +│ ├── action-queue Queue, statuses, GraphQL API, integrations +│ └── direct-commands Immediate allocation ops +├── managing-provisions Horizon provisions (renamed from "Managing Your Provision") +├── graphtally GraphTally & Query Fees — receipt→RAV flow, redemption, addresses +├── cost-models Agora cost models +├── dispute-monitoring POI dispute monitoring +├── auto-graft Grafted-subgraph dependency automation +├── subgraph-freshness Freshness checker + tuning +├── reference/ "Reference" +│ ├── agent-configuration Full agent flag tables (TS indexer-agent) +│ ├── service-tap-configuration indexer-service-rs / indexer-tap-agent TOML + routes +│ ├── cli-reference Full CLI command listing +│ ├── network-configuration Mainnet/testnet networks + onboarding +│ ├── feature-support-matrix GIP-0008 matrix +│ └── error-codes IE001–IE071 +└── troubleshooting Common issues → fixes +``` + +## Source mapping + +| Draft page | Source (under `context/`) | +| --- | --- | +| overview | `indexer/README.md`, `indexer/CLAUDE.md` | +| install-and-run | `indexer/README.md`, `indexer/docs/testnet-setup.md` | +| deployment/* | `indexer-software/graphprotocol-mainnet-docker/*`, `.../graphprotocol-testnet-docker/*` | +| allocations/overview | `indexer/docs/allocation-management/README.md` | +| allocations/operation-modes | `indexer/docs/operation-modes.md` | +| allocations/indexing-rules | `indexer/docs/allocation-management/rules.md` | +| allocations/action-queue | `indexer/docs/allocation-management/action-queue.md` | +| allocations/direct-commands | `indexer/docs/allocation-management/direct.md` | +| managing-provisions | `indexer/docs/provision-management.md` | +| graphtally | `indexer-software/graph-tally/graph-tally-docs.md`, `.../graph-tally-indexer-micropayments.md`, `indexer-rs/README.md` | +| cost-models | `indexer/packages/indexer-cli/README.md` (cost commands) | +| dispute-monitoring | `indexer/packages/indexer-cli/README.md` (disputes), agent disputes flags | +| auto-graft | `indexer/docs/auto-graft.md` | +| subgraph-freshness | `indexer/docs/subgraph-freshness.md` | +| reference/agent-configuration | `indexer/packages/indexer-agent/README.md` | +| reference/service-tap-configuration | `indexer-rs/README.md`, `indexer-rs/docs/Routes.md`, `graph-tally/graph-tally-docs.md` | +| reference/cli-reference | `indexer/packages/indexer-cli/README.md` | +| reference/network-configuration | `indexer/docs/networks.md`, `.../testnet-setup.md` | +| reference/feature-support-matrix | `indexer/docs/feature-support-matrix.md` | +| reference/error-codes | `indexer/docs/errors.md` | + +## Slotting into the live docs + +Move this folder to `website/src/pages/en/indexing/indexer-software/`, then register it in `indexing/_meta.js` and `indexing/_meta-titles.json`: + +```js +// indexing/_meta.js — add the entry where it should appear in the sidebar +'indexer-software': titles['indexer-software'] ?? '', +``` + +```json +// indexing/_meta-titles.json +{ + "tooling": "Indexer Tooling", + "indexer-software": "Indexer Software" +} +``` + +## Open items / editorial notes + +- **Overlap with the live `/indexing/tap/` page:** the new `graphtally.mdx` is the operational query-fee guide for this section and draws on the same source as the live "GraphTally for Indexers" page. Decide whether this section's page consolidates/replaces `/indexing/tap/` or links to it (current draft links to it as the protocol-level guide). +- **Three-part stack:** Overview, Install and Run, and GraphTally now reflect `indexer-agent` (TS) + `indexer-service-rs` + `indexer-tap-agent` (Rust) sharing one database. The `deployment/*` pages still describe the community Compose stacks, which may package the legacy TS `indexer-service` — reconcile the service layer when finalizing. +- **v2.0.0 / Horizon:** service-rs and tap-agent v2.0.0+ require Horizon and drop V1 receipts; re-verify version gating and contract addresses against the live blockchain-addresses table at publish time. +- **Community Docker stacks:** the `deployment/*` pages document the StakeSquid mainnet/testnet Compose repos. Confirm whether these should be presented as first-party docs, framed as community-maintained (current framing), or linked out only. +- **Chain support:** `reference/feature-support-matrix` and `network-configuration` defer to the canonical Supported Networks source rather than asserting counts — verify links against the live site before publishing. +- **`present-poi` / `resize` / provisions** are marked Horizon-only throughout; re-check against the protocol status at publish time. +- **Error codes** IE037–IE040 are undocumented in source (marked reserved); fill in if descriptions exist upstream. +- Cross-links use `/indexing/indexer-software/...` paths assuming the folder lands under `indexing/`. Update if the final home differs. diff --git a/drafts/indexer-software/_meta-titles.json b/drafts/indexer-software/_meta-titles.json new file mode 100644 index 000000000000..8a1ea65ec567 --- /dev/null +++ b/drafts/indexer-software/_meta-titles.json @@ -0,0 +1,5 @@ +{ + "deployment": "Deploy the Stack", + "allocations": "Managing Allocations", + "reference": "Reference" +} diff --git a/drafts/indexer-software/_meta.js b/drafts/indexer-software/_meta.js new file mode 100644 index 000000000000..0e1db3a4c054 --- /dev/null +++ b/drafts/indexer-software/_meta.js @@ -0,0 +1,16 @@ +import titles from './_meta-titles.json' + +export default { + overview: '', + 'install-and-run': '', + deployment: titles.deployment ?? '', + allocations: titles.allocations ?? '', + 'managing-provisions': '', + graphtally: 'GraphTally & Query Fees', + 'cost-models': '', + 'dispute-monitoring': '', + 'auto-graft': '', + 'subgraph-freshness': '', + reference: titles.reference ?? '', + troubleshooting: '', +} diff --git a/drafts/indexer-software/allocations/_meta-titles.json b/drafts/indexer-software/allocations/_meta-titles.json new file mode 100644 index 000000000000..0967ef424bce --- /dev/null +++ b/drafts/indexer-software/allocations/_meta-titles.json @@ -0,0 +1 @@ +{} diff --git a/drafts/indexer-software/allocations/_meta.js b/drafts/indexer-software/allocations/_meta.js new file mode 100644 index 000000000000..4d646deecce1 --- /dev/null +++ b/drafts/indexer-software/allocations/_meta.js @@ -0,0 +1,7 @@ +export default { + overview: '', + 'operation-modes': '', + 'indexing-rules': '', + 'action-queue': '', + 'direct-commands': '', +} diff --git a/drafts/indexer-software/allocations/action-queue.mdx b/drafts/indexer-software/allocations/action-queue.mdx new file mode 100644 index 000000000000..f30db4565092 --- /dev/null +++ b/drafts/indexer-software/allocations/action-queue.mdx @@ -0,0 +1,136 @@ +--- +title: Action Queue +sidebarTitle: Action Queue +--- + +The action queue is a staged approach to allocation management. Actions are queued, reviewed, approved, and then executed by a background worker. This enables oversight, batching, and integration with third-party tools. It works in all [operation modes](/indexing/indexer-software/allocations/operation-modes/). + +## How it works + +1. Actions are added to the queue — by the agent, the CLI, or the GraphQL API. +2. Actions sit in `queued` status until approved. +3. Approved actions are picked up by the execution worker (polls roughly every 30 seconds). +4. The worker executes them on-chain and updates their status. + +## CLI commands + +```bash +# View actions +graph indexer actions get all +graph indexer actions get --status queued +graph indexer actions get --status approved +graph indexer actions get --orderBy createdAt --orderDirection desc + +# Queue actions +graph indexer actions queue allocate +graph indexer actions queue unallocate +graph indexer actions queue reallocate +graph indexer actions queue present-poi # Horizon only +graph indexer actions queue resize # Horizon only + +# Approve actions +graph indexer actions approve [ ...] +graph indexer actions approve queued # Approve all queued actions + +# Cancel / delete +graph indexer actions cancel [ ...] +graph indexer actions delete [ ...] + +# Update action parameters +graph indexer actions update --status queued --type reallocate force true poi 0x... + +# Force immediate execution of approved actions +graph indexer actions execute approved +``` + +## Action types + +| Type | Description | Required parameters | +| --- | --- | --- | +| `allocate` | Allocate stake to a deployment. | `deploymentID`, `amount` | +| `unallocate` | Close an existing allocation. | `deploymentID`, `allocationID` (optional `poi`, `force`) | +| `reallocate` | Atomically close an allocation and open a new one for the same deployment. | `deploymentID`, `allocationID`, `amount` (optional `poi`, `force`) | +| `present-poi` *(Horizon)* | Collect indexing rewards by presenting a POI without closing. | `deploymentID`, `allocationID` (optional `poi`, `blockNumber`, `publicPOI`, `force`) | +| `resize` *(Horizon)* | Change the allocated stake without closing. | `deploymentID`, `allocationID`, `amount` | + +## Action statuses + +| Status | Description | +| --- | --- | +| `queued` | Waiting for approval. | +| `approved` | Ready for execution. | +| `pending` | Being executed. | +| `success` | Executed successfully. | +| `failed` | Execution failed. | +| `canceled` | Canceled before execution. | + +## Behavior by operation mode + +| Mode | Agent behavior | Your actions | +| --- | --- | --- | +| **AUTO** | Queues actions as `approved`. | You can still queue your own. | +| **OVERSIGHT** | Queues actions as `queued`. | You must approve before execution. | +| **MANUAL** | Queues nothing. | You queue and approve everything. | + +## GraphQL API + +The indexer management server exposes a GraphQL endpoint (default port `18000`) for programmatic access — the basis for third-party optimizer integrations. + +### Queries and mutations + +```graphql +type Query { + action(actionID: String!): Action + actions(filter: ActionFilter, orderBy: ActionParams, orderDirection: OrderDirection, first: Int): [Action]! +} + +type Mutation { + queueActions(actions: [ActionInput!]!): [Action]! + approveActions(actionIDs: [String!]!): [Action]! + cancelActions(actionIDs: [String!]!): [Action]! + deleteActions(actionIDs: [String!]!): Int! + updateAction(action: ActionInput!): Action! + updateActions(filter: ActionFilter!, action: ActionUpdateInput!): [Action]! + executeApprovedActions: [ActionResult!]! +} +``` + +### Example — queue an action + +```graphql +mutation queueActions($actions: [ActionInput!]!) { + queueActions(actions: $actions) { + id + type + deploymentID + amount + status + } +} +``` + +```json +{ + "actions": [ + { + "status": "queued", + "type": "allocate", + "deploymentID": "QmXYZ...", + "amount": "10000", + "source": "my-optimizer", + "reason": "High signal deployment", + "priority": 0 + } + ] +} +``` + +## Third-party integration + +The action queue lets external optimizers drive allocations while keeping a human in the loop: + +1. The optimizer analyzes network state and identifies optimal allocations. +2. It queues actions via the GraphQL API with `status: queued`. +3. You review the queued actions. +4. You approve them via CLI or API. +5. The execution worker processes the approved actions. diff --git a/drafts/indexer-software/allocations/direct-commands.mdx b/drafts/indexer-software/allocations/direct-commands.mdx new file mode 100644 index 000000000000..bc0eee314d3a --- /dev/null +++ b/drafts/indexer-software/allocations/direct-commands.mdx @@ -0,0 +1,95 @@ +--- +title: Direct Commands +sidebarTitle: Direct Commands +--- + +Direct commands execute allocation operations immediately on-chain, bypassing the [action queue](/indexing/indexer-software/allocations/action-queue/) and the reconciliation loop. Use them when you need instant execution without waiting for a queue cycle. They work in all [operation modes](/indexing/indexer-software/allocations/operation-modes/). + +All commands require `-n, --network` (for example `mainnet`, `arbitrum-one`, `sepolia`, `arbitrum-sepolia`) and accept `-o, --output` for `table` (default), `json`, or `yaml`. + +## Get allocations + +```bash +graph indexer allocations get --network +graph indexer allocations get --status active --network +graph indexer allocations get --status closed --network +graph indexer allocations get --allocation --network +``` + +- `--status` — filter by `active` or `closed`. +- `--allocation` — get a specific allocation by ID. + +## Create an allocation + +```bash +graph indexer allocations create [index-node] --network +``` + +- `deployment-id` — bytes32 or IPFS hash. +- `amount` — GRT to allocate. +- `index-node` — (optional) a specific index node to use. + +```bash +graph indexer allocations create QmXa1b2c3d4e5f... 10000 --network arbitrum-one +``` + +## Close an allocation + +```bash +graph indexer allocations close [poi] [block-number] [public-poi] --network +``` + +- `poi` — (optional) proof of indexing. +- `block-number`, `public-poi` — (optional, Horizon only) block the POI was computed at, and the matching public POI. +- `-f, --force` — bypass POI accuracy checks. + +```bash +graph indexer allocations close 0x1234...abcd --network arbitrum-one +graph indexer allocations close 0x1234...abcd 0xpoi... --force --network arbitrum-one +``` + +## Reallocate + +Atomically close an allocation and open a new one for the same deployment. + +```bash +graph indexer allocations reallocate [poi] [block-number] [public-poi] --network +``` + +```bash +graph indexer allocations reallocate 0x1234...abcd 15000 --network arbitrum-one +``` + +## Present POI — Horizon only + +Collect indexing rewards by presenting a POI **without closing** the allocation. + +```bash +graph indexer allocations present-poi [poi] [block-number] [public-poi] --network +``` + +```bash +graph indexer allocations present-poi 0x1234...abcd --network arbitrum-one +``` + +## Resize — Horizon only + +Change the allocated stake without closing the allocation. + +```bash +graph indexer allocations resize --network +``` + +```bash +graph indexer allocations resize 0x1234...abcd 20000 --network arbitrum-one +``` + +## Collect query fees + +Trigger [GraphTally](/indexing/indexer-software/graphtally/) receipt collection for an allocation. This is a separate operation from allocation management — it collects query-fee receipts, not an allocation action. + +> Unlike the other commands here, `collect` **cannot** be queued via the action queue; it always executes immediately. + +```bash +graph indexer allocations collect --network +``` diff --git a/drafts/indexer-software/allocations/indexing-rules.mdx b/drafts/indexer-software/allocations/indexing-rules.mdx new file mode 100644 index 000000000000..12546ca95c85 --- /dev/null +++ b/drafts/indexer-software/allocations/indexing-rules.mdx @@ -0,0 +1,107 @@ +--- +title: Indexing Rules +sidebarTitle: Indexing Rules +--- + +Indexing rules tell the agent which subgraph deployments to allocate to and how much stake to use. The [reconciliation loop](/indexing/indexer-software/allocations/operation-modes/) evaluates these rules and queues allocation actions through the [action queue](/indexing/indexer-software/allocations/action-queue/). + +> Rules drive automatic allocation decisions only in **AUTO** and **OVERSIGHT** modes. In **MANUAL** mode the reconciliation loop is skipped entirely and rules have no effect. + +## CLI commands + +```bash +# Set a rule for a specific deployment +graph indexer rules set [ ...] + +# Set the global (default) rule +graph indexer rules set global [ ...] + +# Get rules +graph indexer rules get all +graph indexer rules get +graph indexer rules get global + +# Delete a rule / clear all rules (keeps global) +graph indexer rules delete +graph indexer rules clear + +# Shorthand commands +graph indexer rules start # decisionBasis = always +graph indexer rules stop # decisionBasis = never +graph indexer rules maybe # decisionBasis = rules +graph indexer rules prepare # decisionBasis = offchain +``` + +## Rule parameters + +### Decision basis + +The `decisionBasis` field determines whether the agent allocates to a deployment: + +| Value | Behavior | +| --- | --- | +| `always` | Always allocate to this deployment. | +| `never` | Never allocate to this deployment. | +| `offchain` | Index the deployment but don't allocate (no on-chain stake). | +| `rules` | Evaluate against the threshold parameters below. | + +### Threshold parameters + +Applied when `decisionBasis` is `rules`: + +| Parameter | Description | +| --- | --- | +| `minStake` | Minimum total stake on the deployment. | +| `minSignal` | Minimum curation signal on the deployment. | +| `minAverageQueryFees` | Minimum average query fees. | +| `maxSignal` | Maximum signal (avoid over-allocated deployments). | +| `maxAllocationPercentage` | Maximum percentage of the Indexer's stake to allocate. | + +### Allocation parameters + +| Parameter | Description | +| --- | --- | +| `allocationAmount` | Amount of GRT to allocate. | +| `allocationLifetime` | Number of epochs before reallocating. | +| `parallelAllocations` | Number of parallel allocations to maintain. | + +### Safety parameters + +| Parameter | Description | +| --- | --- | +| `safety` | Enable safety checks (won't allocate to failed deployments). | +| `requireSupported` | Only allocate if the deployment is on a supported network. | +| `autoRenewal` | Automatically reallocate when an allocation expires. | + +## Global vs. deployment-specific rules + +The **global** rule supplies default values for all deployments. A **deployment-specific** rule overrides the global values for that deployment. The agent merges the two, with deployment-specific values taking precedence. + +## Examples + +```bash +# Global defaults +graph indexer rules set global \ + decisionBasis rules \ + minSignal 100 \ + minStake 1000 \ + allocationAmount 10000 \ + safety true + +# Always allocate to a specific high-value deployment +graph indexer rules set QmXYZ... decisionBasis always allocationAmount 50000 + +# Index but don't allocate (offchain indexing) +graph indexer rules set QmABC... decisionBasis offchain + +# Stop allocating to a deployment +graph indexer rules stop QmDEF... +``` + +## How rules drive the reconciliation loop + +1. The agent fetches all deployments from the Network Subgraph. +2. For each, it finds the applicable rule (deployment-specific or global). +3. It evaluates the `decisionBasis`: `always` → allocate; `never` / `offchain` → don't allocate (offchain still indexes locally); `rules` → evaluate thresholds. +4. It compares desired state against current allocations. +5. It queues actions to reconcile: `allocate` (missing), `unallocate` (shouldn't hold), or `reallocate` (expiring). diff --git a/drafts/indexer-software/allocations/operation-modes.mdx b/drafts/indexer-software/allocations/operation-modes.mdx new file mode 100644 index 000000000000..723144168e4b --- /dev/null +++ b/drafts/indexer-software/allocations/operation-modes.mdx @@ -0,0 +1,86 @@ +--- +title: Operation Modes +sidebarTitle: Operation Modes +--- + +The Indexer Agent can manage your allocations automatically through a **reconciliation loop** — a background process that continuously monitors the network and adjusts allocations based on your [indexing rules](/indexing/indexer-software/allocations/indexing-rules/). The **operation mode** controls whether and how that loop runs. + +Set the mode with `--allocation-management` or `INDEXER_AGENT_ALLOCATION_MANAGEMENT`: + +| Mode | Reconciliation loop | Behavior | Best for | +| --- | --- | --- | --- | +| **AUTO** (default) | Runs | Agent decides, auto-approves, and executes. | Hands-off operation. | +| **OVERSIGHT** | Runs | Agent decides and queues actions for your approval. | Review before execution. | +| **MANUAL** | Skipped | You manage allocations yourself via the CLI. | Full manual control, third-party tools. | + +## What is the reconciliation loop? + +The reconciliation loop is the agent's core automation mechanism. On each cycle it: + +1. **Evaluates** which deployments you *should* be allocated to, based on your indexing rules. +2. **Compares** that desired state against your actual on-chain allocations. +3. **Queues actions** to reconcile the difference (allocate, unallocate, reallocate). + +``` +┌─────────────────────┐ ┌──────────────────────────┐ ┌─────────────┐ +│ Deployment │ --> │ Allocation │ --> │ Action │ +│ Evaluation │ │ Reconciliation │ │ Executor │ +│ "What SHOULD we │ │ "What do we need to DO │ │ Execute │ +│ allocate to?" │ │ to match desired state?"│ │ on-chain │ +└─────────────────────┘ └──────────────────────────┘ └─────────────┘ +``` + +In **AUTO** mode, queued actions are auto-approved and execute immediately. In **OVERSIGHT** mode, they wait for your approval. In **MANUAL** mode the loop doesn't run — you queue actions yourself. + +## Reconciliation loop details + +### Polling intervals + +The loop runs on two intervals: a **small interval** (`pollingInterval`) for frequently changing data, and a **large interval** (`pollingInterval * 5`) for stable data. + +| Data | Interval | +| --- | --- | +| Current epoch number | Large | +| Max allocation duration | Large | +| Indexing rules | Small | +| Active deployments on Graph Node | Large (AUTO mode only) | +| Network deployments | Small | +| Active allocations | Small | +| Recently closed allocations | Small | + +### Phase 1 — Deployment evaluation + +Determines which deployments you should be allocated to: + +- Fetches all deployments from the Network Subgraph. +- Matches each against your indexing rules (deployment-specific or global). +- Outputs `toAllocate: true/false` for each deployment. + +Decision basis options: `always`, `never`, `offchain` (index locally, don't allocate on-chain), or `rules` (evaluate against thresholds such as `minStake`, `minSignal`, `minAverageQueryFees`). See [Indexing Rules](/indexing/indexer-software/allocations/indexing-rules/). + +### Phase 2 — Allocation reconciliation + +Compares desired state against actual allocations and queues actions: + +| Condition | Action queued | +| --- | --- | +| Should allocate + no active allocation | ALLOCATE | +| Shouldn't allocate + has active allocation | UNALLOCATE | +| Should allocate + allocation expiring | REALLOCATE | + +An allocation is considered expiring when `currentEpoch >= createdAtEpoch + allocationLifetime`. + +## Safety mechanisms + +The agent includes safeguards against problematic allocations: + +1. **Health check** — won't allocate to deployments with a "failed" health status (when `safety=true` in the rule). +2. **Zero-POI safety** — won't reallocate if the previous allocation closed with a zero POI. +3. **Approved-actions check** — skips reconciliation while pending approved actions exist, preventing conflicts. +4. **Network Subgraph protection** — never auto-allocates to the Network Subgraph unless explicitly enabled via `--allocate-on-network-subgraph`. + +## Related + +- [Indexing Rules](/indexing/indexer-software/allocations/indexing-rules/) — configure what the agent should allocate to. +- [Action Queue](/indexing/indexer-software/allocations/action-queue/) — queue, approve, and execute actions. +- [Direct Commands](/indexing/indexer-software/allocations/direct-commands/) — execute operations immediately. diff --git a/drafts/indexer-software/allocations/overview.mdx b/drafts/indexer-software/allocations/overview.mdx new file mode 100644 index 000000000000..187e096ca83b --- /dev/null +++ b/drafts/indexer-software/allocations/overview.mdx @@ -0,0 +1,59 @@ +--- +title: Managing Allocations +sidebarTitle: Overview +--- + +An **allocation** is stake an Indexer commits to a specific subgraph deployment in order to index it and earn indexing rewards and query fees. Managing allocations is the core day-to-day job of the Indexer Software. There are three ways to do it, ranging from fully automated to fully manual. + +| Method | How it works | When to use | +| --- | --- | --- | +| **[Indexing Rules](/indexing/indexer-software/allocations/indexing-rules/)** | Set rules; the agent decides and acts. | Automated or semi-automated management in AUTO/OVERSIGHT mode. | +| **[Action Queue](/indexing/indexer-software/allocations/action-queue/)** | Queue actions, approve, execute. | Batching, oversight, third-party optimizers. | +| **[Direct Commands](/indexing/indexer-software/allocations/direct-commands/)** | Execute immediately on-chain. | One-off operations, debugging, immediate control. | + +Which of these are active depends on the [operation mode](/indexing/indexer-software/allocations/operation-modes/) the agent runs in. Start there if you haven't set a mode yet. + +## Indexing Rules + +You define rules that specify which deployments to allocate to and how much stake to use. The agent's [reconciliation loop](/indexing/indexer-software/allocations/operation-modes/) evaluates these rules and queues the necessary actions automatically through the action queue. + +```bash +graph indexer rules set QmXYZ... decisionBasis always allocationAmount 10000 +``` + +**Best for:** hands-off operation, where the agent manages allocations based on signal, stake thresholds, or explicit deployment lists. + +**Requires:** AUTO or OVERSIGHT mode. In MANUAL mode the reconciliation loop is skipped and rules have no effect. + +## Action Queue + +Actions are queued, reviewed, approved, and then executed by a background worker — giving you oversight and control over what lands on-chain. + +```bash +graph indexer actions queue allocate QmXYZ... 10000 +graph indexer actions approve 1 +``` + +**Best for:** reviewing actions before execution, batching operations, integrating third-party allocation optimizers, and keeping a history of every action. **Works in all modes.** + +## Direct Commands + +Execute allocation operations immediately, bypassing the action queue entirely. + +```bash +graph indexer allocations create QmXYZ... 10000 --network arbitrum-one +``` + +**Best for:** one-off operations, debugging, or immediate execution without waiting for a queue cycle. **Works in all modes** and always executes immediately. + +## Automatic rule updates + +When allocation actions execute — whether you queued them manually or ran a direct command — the agent updates the corresponding indexing rule so it stays in sync and doesn't fight your manual changes in AUTO/OVERSIGHT mode: + +| Action | Rule update | +| --- | --- | +| `allocate` | Sets `decisionBasis: ALWAYS` | +| `unallocate` | Sets `decisionBasis: OFFCHAIN` | +| `reallocate` | Sets `decisionBasis: ALWAYS` | +| `resize` | Sets `decisionBasis: ALWAYS` | +| `present-poi` | No change | diff --git a/drafts/indexer-software/auto-graft.mdx b/drafts/indexer-software/auto-graft.mdx new file mode 100644 index 000000000000..440f0dcf7fb5 --- /dev/null +++ b/drafts/indexer-software/auto-graft.mdx @@ -0,0 +1,70 @@ +--- +title: Auto-Graft +sidebarTitle: Auto-Graft +--- + +Auto-graft lets the Indexer Agent automatically deploy and sync the dependencies of a grafted subgraph. Without it, deploying a grafted subgraph means manually identifying every dependency in the graft chain, deploying each in the right order, syncing each to its required block, and pausing it. Auto-graft does all of that for you, so a grafted subgraph deploys like any other. + +Grafting itself lets a new subgraph build on an existing one at a chosen block height, reusing already-indexed data instead of re-indexing from genesis. See the [subgraph grafting docs](/subgraphs/cookbook/grafting/) for authoring details. + +## Enabling auto-graft + +Auto-graft is **disabled by default** (as of agent v0.24.3) and requires an IPFS endpoint to fetch dependency manifests. + +```sh +graph-indexer-agent start \ + --enable-auto-graft \ + --ipfs-endpoint https://ipfs.network.thegraph.com \ + ... +``` + +| Setting | Flag / Env | Default | +| --- | --- | --- | +| Enable auto-graft | `--enable-auto-graft` / `INDEXER_AGENT_ENABLE_AUTO_GRAFT` | `false` | +| IPFS endpoint | `--ipfs-endpoint` / `INDEXER_AGENT_IPFS_ENDPOINT` | `https://ipfs.network.thegraph.com` | + +> Prior to v0.24.3, auto-graft was enabled automatically whenever an IPFS endpoint was configured. It must now be enabled explicitly. + +## How it works + +When you deploy a subgraph that declares a graft, the agent: + +1. **Detects** the graft configuration in the subgraph manifest. +2. **Resolves** the full dependency chain, recursively fetching manifests from IPFS. +3. **Orders** dependencies from deepest to root so they deploy in the correct sequence. +4. **Deploys** any missing dependencies. +5. **Syncs** each dependency to its required block height. +6. **Pauses** each dependency once it reaches its target block, to save resources. + +For a chain where your subgraph grafts from A at block 15M, A grafts from B at 10M, and B grafts from C at 5M, auto-graft deploys and syncs C → B → A in order, then begins indexing your subgraph from block 15M. + +## Monitoring progress + +Track auto-graft through the agent logs. Key messages include: + +- `Auto graft deploy subgraph dependencies` — process started +- `graft dep chain found` — dependencies identified +- `Begin syncing subgraph deployment to block` — a dependency is syncing +- `Graft dependency has reached target block height. Continuing to index past graft point.` — dependency ready + +Check dependency status with the CLI: + +```sh +graph indexer status +graph indexer status +``` + +## Troubleshooting + +| Problem | Likely cause and fix | +| --- | --- | +| `IPFS request failed` | Verify `INDEXER_AGENT_IPFS_ENDPOINT` is reachable and the manifest hash is valid. | +| `Sync to block X deadline reached` | The dependency is syncing slowly — check Graph Node performance and that the chain is fully synced. | +| `Subgraph not found in indexing status` | Confirm the dependency hash is correct and that the dependency was created successfully; check Graph Node logs. | +| Circular dependency | Ensure the graft chain is linear; fix circular references in the manifests. | + +## Requirements + +- Graph Node running with grafting support (supported on all networks). +- The Indexer must be able to reach an IPFS endpoint (`/api/v0` HTTP API). +- Auto-graft explicitly enabled. diff --git a/drafts/indexer-software/cost-models.mdx b/drafts/indexer-software/cost-models.mdx new file mode 100644 index 000000000000..7e3e4654acab --- /dev/null +++ b/drafts/indexer-software/cost-models.mdx @@ -0,0 +1,54 @@ +--- +title: Cost Models +sidebarTitle: Cost Models +--- + +Cost models let an Indexer price the queries it serves. Each model is written in **Agora**, a small declarative language for mapping GraphQL query shapes to a price. Gateways use the advertised prices when routing, and `indexer-service-rs` exposes them on its `/cost` endpoint. + +Cost models are managed with the Indexer CLI and stored in the shared database, so they take effect without restarting the agent. + +## CLI commands + +```sh +$ graph indexer cost --help +Manage costing for subgraphs + + indexer cost set model Update a cost model + indexer cost get Get cost models for one or all subgraphs + indexer cost delete Remove one or many cost models +``` + +### Set a cost model + +Set a model for a specific deployment, or set the `global` model that applies to any deployment without its own: + +```sh +# Apply an Agora model file to a deployment +graph indexer cost set model my-model.agora + +# Set the global default model +graph indexer cost set model global my-model.agora +``` + +### Get cost models + +```sh +graph indexer cost get all +graph indexer cost get +graph indexer cost get global +``` + +### Delete cost models + +```sh +graph indexer cost delete +``` + +## Global vs. deployment-specific models + +As with [indexing rules](/indexing/indexer-software/allocations/indexing-rules/), a `global` cost model provides defaults and deployment-specific models override it. A deployment without its own model falls back to `global`. + +## Related + +- [Indexing Rules](/indexing/indexer-software/allocations/indexing-rules/) — deciding *what* to index and allocate to. +- [GraphTally & Query Fees](/indexing/indexer-software/graphtally/) — how the query fees priced here are collected. diff --git a/drafts/indexer-software/deployment/_meta-titles.json b/drafts/indexer-software/deployment/_meta-titles.json new file mode 100644 index 000000000000..0967ef424bce --- /dev/null +++ b/drafts/indexer-software/deployment/_meta-titles.json @@ -0,0 +1 @@ +{} diff --git a/drafts/indexer-software/deployment/_meta.js b/drafts/indexer-software/deployment/_meta.js new file mode 100644 index 000000000000..c154dfd6ab2a --- /dev/null +++ b/drafts/indexer-software/deployment/_meta.js @@ -0,0 +1,5 @@ +export default { + overview: '', + 'mainnet-docker': '', + 'testnet-docker': '', +} diff --git a/drafts/indexer-software/deployment/mainnet-docker.mdx b/drafts/indexer-software/deployment/mainnet-docker.mdx new file mode 100644 index 000000000000..93cb4b6f6f28 --- /dev/null +++ b/drafts/indexer-software/deployment/mainnet-docker.mdx @@ -0,0 +1,131 @@ +--- +title: Mainnet Docker Deployment +sidebarTitle: Mainnet Docker +--- + +The **mainnet Docker Compose** stack spins up a complete Indexer on a single machine for The Graph Network mainnet (Arbitrum One): Graph Node, the Indexer Agent/Service/CLI, PostgreSQL, and a full monitoring stack. It is community-maintained at [github.com/StakeSquid/graphprotocol-mainnet-docker](https://github.com/StakeSquid/graphprotocol-mainnet-docker). + +> Read the stack's full documentation before running in production. You must supply your own Ethereum archive node (EIP-1898); it is not part of this setup. + +## Prerequisites + +### Stake and operator + +Stake a minimum of **100,000 GRT** through [Graph Explorer](https://thegraph.com/explorer) (Profile → Indexing → Stake), then register a separate **operator wallet** (Settings → Operators) that the stack uses to send transactions while your staked GRT stays on a different wallet. See [Network Configuration](/indexing/indexer-software/reference/network-configuration/). + +### Hardware (guidance) + +Requirements scale with your stake and the subgraphs you serve. As a rough guide from the stack maintainers: + +| | Minimum | Recommended | +| --- | --- | --- | +| Graph infra CPU | 16 vcore | 64 vcore | +| Graph infra RAM | 32 GB | 128 GB | +| Graph infra storage | 300 GB SSD | 2 TB NVMe | +| Archive node storage (Erigon) | 3 TB SSD | 5 TB NVMe | + +### Software + +```bash +apt update -y && apt upgrade -y && apt autoremove -y +apt install docker.io docker-compose httpie curl wget git jq nano apparmor -y +# install envsubst +curl -L https://github.com/a8m/envsubst/releases/download/v1.2.0/envsubst-`uname -s`-`uname -m` \ + -o envsubst && chmod +x envsubst && sudo mv envsubst /usr/bin/envsubst +``` + +## Install + +```bash +git clone git@github.com:StakeSquid/graphprotocol-mainnet-docker.git +cd graphprotocol-mainnet-docker +git submodule init +git submodule update +``` + +## Configure DNS + +Point two subdomains at your server's IP: + +``` +index.sld.tld +grafana.sld.tld +``` + +## Configure environment + +Edit `.env` and set at least the required variables: + +```bash +EMAIL=email@sld.tld # for SSL certificate issuance +INDEX_HOST=index.sld.tld # public indexer endpoint (gateway queries this) +GRAFANA_HOST=grafana.sld.tld # monitoring dashboard +ADMIN_USER=your_user # Grafana/Prometheus/Alertmanager +ADMIN_PASSWORD=your_password +DB_USER=your_db_user # Postgres init +DB_PASS=your_db_password +GRAPH_NODE_DB_NAME=your_graphnode_db_name +AGENT_DB_NAME=your_agent_db_name +CHAIN_0_NAME="network-name" # chain to index +CHAIN_0_RPC="http://ip:port" # your archive RPC +TXN_RPC="http://ip:port" # RPC used by agent/service for transactions +OPERATOR_SEED_PHRASE="12 or 15 word mnemonic" +STAKING_WALLET_ADDRESS=0xAddress +GEO_COORDINATES='69.420 69.420' +``` + +Optional stacks (Agent GUI, POIfier, Graphcast Subgraph Radio) have their own commented variables in `.env`. + +### Supporting multiple chains + +To index more than one chain, add a `[chains.${CHAIN_N_NAME}]` provider block to `graph-node-configs/config.tmpl` and add the matching `CHAIN_N_NAME` / `CHAIN_N_RPC` variables: + +``` +CHAIN_0_NAME="gnosis" +CHAIN_0_RPC="http://ip:port" +CHAIN_1_NAME="matic" +CHAIN_1_RPC="http://ip:port" +``` + +## Start + +```bash +bash start-essential # graph-node + indexer + monitoring — everything to get on the network +``` + +Other start scripts: `start-optional`, `start-autoagora`, and `start-all`. To rebuild a component, append `--force-recreate `; omit the container name to rebuild the whole stack. + +Initial startup takes several minutes (the CLI container is slow to build). Verify with: + +```bash +docker ps +``` + +Look for containers stuck `restarting` — inspect their logs to debug. + +## Default ports + +| Service | Port | Purpose | +| --- | --- | --- | +| Graph Node | 8000 | GraphQL HTTP (subgraph queries) | +| Graph Node | 8020 | JSON-RPC (manage deployments) | +| Graph Node | 8030 | Indexing status API | +| Graph Node | 8040 | Prometheus metrics | +| Indexer Service | 7600 | GraphQL HTTP (paid queries) | +| Indexer Service | 7300 | Prometheus metrics | +| Indexer Agent | 8000 | Indexer management API (`graph indexer`) | + +## Updating + +```bash +cd graphprotocol-mainnet-docker +git fetch && git pull +bash start-essential --force-recreate +git submodule update # update Agora / Qlog helper modules +``` + +## Next steps + +- [Set up allocations](/indexing/indexer-software/allocations/overview/) +- [Configure cost models](/indexing/indexer-software/cost-models/) +- [Troubleshooting](/indexing/indexer-software/troubleshooting/) diff --git a/drafts/indexer-software/deployment/overview.mdx b/drafts/indexer-software/deployment/overview.mdx new file mode 100644 index 000000000000..7614b7d6ee03 --- /dev/null +++ b/drafts/indexer-software/deployment/overview.mdx @@ -0,0 +1,47 @@ +--- +title: Deploy the Indexer Stack +sidebarTitle: Overview +--- + +Running an Indexer means operating several coordinated services: [Graph Node](/indexing/tooling/graph-node/) (index and query nodes), the [Indexer Agent and Service](/indexing/indexer-software/overview/), PostgreSQL databases, and a monitoring stack. The community-maintained Docker Compose stacks bundle all of these on a single machine, which is the fastest way to stand up a full Indexer. + +Two variants exist, differing mainly in the protocol network they target: + +| Stack | Network | Use it for | +| --- | --- | --- | +| [Mainnet Docker](/indexing/indexer-software/deployment/mainnet-docker/) | The Graph Network mainnet (Arbitrum One) | Production indexing on mainnet. | +| [Testnet Docker](/indexing/indexer-software/deployment/testnet-docker/) | The Graph Network testnet (Arbitrum Sepolia) | Practicing and qualifying before mainnet. | + +> These Docker stacks are community-maintained by [StakeSquid](https://github.com/StakeSquid) and are not the only way to run an Indexer. Bare-metal and Kubernetes deployments are also supported. Read the full stack documentation before running in production. + +## What the stack includes + +A full deployment spins up several groups of containers: + +- **Graph Node stack** — index node, query node, and a Postgres database. +- **Indexer stack** — Indexer Agent, Indexer Service, Indexer CLI, an Nginx/SSL proxy, and a Postgres database. +- **Monitoring stack** — Prometheus, Grafana, Alertmanager, Node Exporter, cAdvisor, and Pushgateway. +- **Optional stacks** — AutoAgora (automated cost models), POIfier, and the Indexer Agent GUI. + +You bring your own **Ethereum archive node** — an archive RPC supporting EIP-1898 is required and is *not* part of the Docker setup. + +## What you need before starting + +- A server sized for the workload (production indexing needs substantial CPU, RAM, and NVMe storage — plan to scale with your stake). +- Docker Engine, Docker Compose, and supporting tools (`git`, `jq`, `curl`, `wget`, `httpie`, `envsubst`). +- An archive RPC endpoint (EIP-1898) for each chain you index. +- A domain name (for SSL on your public indexer and Grafana endpoints). +- An **operator wallet** mnemonic and your **staking wallet** address (kept on separate mnemonics). + +## Deployment flow + +Both stacks follow the same shape: + +1. [Stake and set an operator](/indexing/indexer-software/reference/network-configuration/) on the target network. +2. Clone the repository and initialize its submodules. +3. Point DNS subdomains at your server. +4. Fill in the `.env` file with your hosts, database credentials, RPCs, and operator seed phrase. +5. Start the essential stack (`bash start-essential`), then verify with `docker ps`. +6. Configure [indexing rules](/indexing/indexer-software/allocations/indexing-rules/) and [cost models](/indexing/indexer-software/cost-models/). + +Pick your network to continue: [Mainnet Docker](/indexing/indexer-software/deployment/mainnet-docker/) or [Testnet Docker](/indexing/indexer-software/deployment/testnet-docker/). diff --git a/drafts/indexer-software/deployment/testnet-docker.mdx b/drafts/indexer-software/deployment/testnet-docker.mdx new file mode 100644 index 000000000000..a20335b271e9 --- /dev/null +++ b/drafts/indexer-software/deployment/testnet-docker.mdx @@ -0,0 +1,51 @@ +--- +title: Testnet Docker Deployment +sidebarTitle: Testnet Docker +--- + +The **testnet Docker Compose** stack is the counterpart of the [mainnet stack](/indexing/indexer-software/deployment/mainnet-docker/), targeting The Graph Network testnet on **Arbitrum Sepolia**. It's the recommended way to practice running an Indexer — and to qualify through the testnet — before deploying on mainnet. It is community-maintained at [github.com/StakeSquid/graphprotocol-testnet-docker](https://github.com/StakeSquid/graphprotocol-testnet-docker). + +The container layout, `.env` structure, start scripts, and ports are the same as the mainnet stack. This page covers only what differs for testnet. + +## Get testnet funds + +Participation requires Sepolia ETH and testnet GRT (minimum stake **100k testnet GRT**): + +1. Join [The Graph Discord](https://thegraph.com/discord/). +2. Get the `@testnetindexer` role in the `#roles` channel. +3. Request testnet GRT in the `#arbi-sepolia-faucet` channel. + +## Stake and set an operator + +Use the [testnet explorer](https://testnet.thegraph.com/) (Metamask → Arbitrum Sepolia) to stake and register an operator, or the Contracts CLI. See [Network Configuration](/indexing/indexer-software/reference/network-configuration/#testnet-arbitrum-sepolia) for the exact commands. + +## Install and configure + +```bash +git clone git@github.com:StakeSquid/graphprotocol-testnet-docker.git +cd graphprotocol-testnet-docker +git submodule init +git submodule update +``` + +Configure DNS subdomains and the `.env` file exactly as in the [mainnet guide](/indexing/indexer-software/deployment/mainnet-docker/#configure-environment), with two differences: + +- Point `CHAIN_0_RPC` / `TXN_RPC` at **Arbitrum Sepolia** archive/transaction RPCs. +- Fund the operator wallet with **Sepolia ETH**, not mainnet ETH. + +## Start and verify + +```bash +bash start-essential +docker ps +``` + +## Next steps + +Once the stack is healthy, exercise the full workflow on testnet before going to mainnet: + +- [Set up allocations](/indexing/indexer-software/allocations/overview/) +- [Configure cost models](/indexing/indexer-software/cost-models/) +- [Troubleshooting](/indexing/indexer-software/troubleshooting/) + +When you're ready for production, follow the [Mainnet Docker Deployment](/indexing/indexer-software/deployment/mainnet-docker/). diff --git a/drafts/indexer-software/dispute-monitoring.mdx b/drafts/indexer-software/dispute-monitoring.mdx new file mode 100644 index 000000000000..e63d9de2e0a8 --- /dev/null +++ b/drafts/indexer-software/dispute-monitoring.mdx @@ -0,0 +1,44 @@ +--- +title: POI Dispute Monitoring +sidebarTitle: Dispute Monitoring +--- + +Indexers submit **Proofs of Indexing (POIs)** when they close allocations. A POI attests that the Indexer holds correct data for a deployment at a given block. The Indexer Agent can monitor the network for POIs that disagree with your own, surfacing potential disputes before they become a problem. + +## Enabling dispute monitoring + +POI dispute monitoring is off by default. Enable it on the agent: + +```sh +graph-indexer-agent start \ + --poi-dispute-monitoring \ + --poi-disputable-epochs 1 \ + ... +``` + +| Flag | Description | Default | +| --- | --- | --- | +| `--poi-dispute-monitoring` | Monitor the network for potential POI disputes. | `false` | +| `--poi-disputable-epochs` | How many past epochs to look back for potential disputes. | `1` | + +## Reviewing potential disputes + +Use the CLI to cross-check POIs submitted across the network against your own: + +```sh +$ graph indexer disputes --help +Configure allocation POI monitoring + + indexer disputes get Cross-check POIs submitted in the network +``` + +```sh +graph indexer disputes get +``` + +This lists allocations where a submitted POI is potentially disputable, so you can investigate before an on-chain dispute is raised. + +## Related + +- [Direct Commands](/indexing/indexer-software/allocations/direct-commands/) — where POIs are supplied when closing allocations. +- [Indexing Overview](/indexing/overview/) — arbitration and slashing context. diff --git a/drafts/indexer-software/graphtally.mdx b/drafts/indexer-software/graphtally.mdx new file mode 100644 index 000000000000..e1efc623cecf --- /dev/null +++ b/drafts/indexer-software/graphtally.mdx @@ -0,0 +1,89 @@ +--- +title: GraphTally & Query Fees +sidebarTitle: GraphTally & Query Fees +--- + +**GraphTally** (formerly the Timeline Aggregation Protocol, TAP) is The Graph's payment system for query fees — a fast, trust-minimized micropayment protocol integrated into the core protocol through [Graph Horizon](/graph-horizon/overview/). This page covers how query fees flow through your Indexer stack and how to operate the components that collect them. For the full TOML settings, see [Service & TAP Agent Configuration](/indexing/indexer-software/reference/service-tap-configuration/). + +## Why GraphTally + +Active Indexers serve hundreds of thousands of queries per day. Settling each one with an on-chain transaction would cost far more than the query is worth. GraphTally instead uses a **one-way payment channel**: the gateway (Sender) signs a small **Receipt** for each query, the Indexer (Receiver) verifies and tallies receipts off-chain, and only periodically settles the accumulated total on-chain. Because payment flows in one direction, no dispute window is needed — the Indexer is incentivized to submit the latest total. + +## How it works + +GraphTally aggregates many signed **Receipts** into a single **Receipt Aggregate Voucher (RAV)** that can be redeemed on-chain. In your stack: + +1. The gateway sends a signed receipt with each query. +2. `indexer-service-rs` validates the receipt and stores it in the shared database. +3. `indexer-tap-agent` periodically aggregates receipts into a RAV, keeping unaggregated value below your `max_amount_willing_to_lose_grt` threshold. +4. RAVs accumulate value as new receipts arrive. +5. After an allocation closes, a final RAV is created and the **Indexer Agent** redeems it on-chain. + +The three components — service, TAP agent, and agent — all share the same PostgreSQL database. Run **exactly one** `indexer-tap-agent`; `indexer-service-rs` can be scaled horizontally. + +## RAV redemption lifecycle + +Redemption is fully automated when `indexer-tap-agent` and `indexer-agent` are both running: + +1. The Indexer closes an allocation. +2. After the `recently-closed-allocation-buffer` period, `indexer-tap-agent` aggregates the remaining receipts into a final RAV marked `last`. +3. `indexer-agent` submits the redeem transaction on-chain. +4. During the `finality-time` period, `indexer-agent` watches for chain reorganizations — reverted transactions are resubmitted, confirmed ones are marked `final`. + +The TAP agent reconciles redemptions against the Network Subgraph (querying `paymentsEscrowTransactions`) roughly every 5 minutes by default (`tap.allocation_reconciliation_interval_secs`). + +## Receipt validation + +`indexer-service-rs` validates every incoming receipt before storing it, checking that: the receipt targets a valid, active allocation; the `payer` matches a known sender; the `data_service` matches your configured `subgraph_service_address`; the `service_provider` matches your Indexer address; the sender has sufficient escrow balance; the value doesn't exceed `max_receipt_value_grt`; and the timestamp is within bounds. + +## Blockchain addresses + +Configure your services with the correct contract and gateway addresses for the network. These are the canonical values from the GraphTally guide; verify against the [live blockchain addresses table](/indexing/tap/#blockchain-addresses) before use. + +### Contracts + +| Contract | Arbitrum Mainnet (42161) | Arbitrum Sepolia (421614) | +| --- | --- | --- | +| TAP Verifier | `0x8f69F5C07477Ac46FBc491B1E6D91E2be0111A9e` | `0x382863e7B662027117449bd2c49285582bbBd21B` | +| Subgraph Service | `0xb2Bb92d0DE618878E438b55D5846cfecD9301105` | `0xc24A3dAC5d06d771f657A48B20cE1a671B78f26b` | +| TAP Escrow | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` | + +### Gateway + +| Component | Arbitrum Mainnet | Arbitrum Sepolia (Testnet) | +| --- | --- | --- | +| Sender | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467` | `0xC3dDf37906724732FfD748057FEBe23379b0710D` | +| Aggregator | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` | + +## Software requirements + +- **indexer-agent** — [latest version](https://github.com/graphprotocol/indexer/releases) +- **indexer-service-rs** v2.0.0+ — [latest release](https://github.com/graphprotocol/indexer-rs/releases?q=indexer-service-rs) +- **indexer-tap-agent** v2.0.0+ — [latest release](https://github.com/graphprotocol/indexer-rs/releases?q=indexer-tap-agent) + +> **Horizon required from v2.0.0.** Starting with v2.0.0, `indexer-service-rs` and `indexer-tap-agent` require Graph Horizon and legacy V1 receipt support is removed. Set `[horizon].enabled = true` and configure `receipts_verifier_address_v2` and `subgraph_service_address` before upgrading. See the migration steps in [Service & TAP Agent Configuration](/indexing/indexer-software/reference/service-tap-configuration/#upgrading-to-v200). + +## Monitoring + +Both Rust services expose Prometheus metrics on port `7300` (`/metrics`). Key things to watch: + +- **Unaggregated fees** — keep below `max_amount_willing_to_lose_grt`; if it climbs, the TAP agent isn't aggregating fast enough (or at all). +- **RAV request success/failure** — repeated failures usually mean an aggregator endpoint or sender-config problem. +- **Sender balances** — track escrow balances and outstanding obligations. + +Import the [official Grafana dashboard](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) to visualize receipt flow, RAV lifecycle, and error rates. + +## Troubleshooting + +| Symptom | Things to check | +| --- | --- | +| RAV requests failing | Aggregator endpoint connectivity; `tap.sender_aggregator_endpoints` config; debug logs (`RUST_LOG=...=debug`). | +| Receipts not aggregating | Exactly one `indexer-tap-agent` running; database connectivity; `max_amount_willing_to_lose_grt` not set too high. | +| High unaggregated fees | Lower `max_amount_willing_to_lose_grt` to aggregate more often; check whether a specific sender is failing. | +| Service won't start (missing config) | `horizon.enabled = true`; both `receipts_verifier_address_v2` and `subgraph_service_address` set; Network Subgraph reachable. | + +## Related + +- [Service & TAP Agent Configuration](/indexing/indexer-software/reference/service-tap-configuration/) — full TOML reference. +- [Direct Commands](/indexing/indexer-software/allocations/direct-commands/#collect-query-fees) — manually triggering receipt collection. +- [GraphTally for Indexers](/indexing/tap/) — the protocol-level guide. diff --git a/drafts/indexer-software/install-and-run.mdx b/drafts/indexer-software/install-and-run.mdx new file mode 100644 index 000000000000..f2288504b943 --- /dev/null +++ b/drafts/indexer-software/install-and-run.mdx @@ -0,0 +1,118 @@ +--- +title: Install and Run the Indexer Software +sidebarTitle: Install and Run +--- + +This page covers installing and starting the Indexer stack: the TypeScript **Indexer Agent** and **CLI**, plus the Rust **Indexer Service** (`indexer-service-rs`) and **TAP Agent** (`indexer-tap-agent`). For the complete flag/config references, see [Agent Configuration](/indexing/indexer-software/reference/agent-configuration/) and [Service & TAP Agent Configuration](/indexing/indexer-software/reference/service-tap-configuration/). + +> The agent, service, and TAP agent all share **one PostgreSQL database**. Run the agent's migrations against it (see below); the Rust services use the same schema but must not run their own migrations. Run exactly **one** `indexer-tap-agent` instance; `indexer-service-rs` can be scaled horizontally. + +## Prerequisites + +- **Node.js** >= 18 +- **PostgreSQL** — a database the agent can connect to +- A running **[Graph Node](/indexing/tooling/graph-node/)** with query, status, and admin endpoints reachable +- An **Ethereum/Arbitrum RPC** endpoint +- An **operator wallet** mnemonic and your **Indexer address** +- Access to the **Network Subgraph** and **Epoch Subgraph** endpoints (or a gateway that serves them) + +## Installation + +The Indexer CLI is an extension for [`graph-cli`](https://github.com/graphprotocol/graph-cli), so install them together. + +```sh +# Indexer Agent +npm install -g @graphprotocol/indexer-agent + +# CLI (plus graph-cli, which it extends) +npm install -g @graphprotocol/graph-cli +npm install -g @graphprotocol/indexer-cli +``` + +### Indexer Service and TAP Agent (Rust) + +The Rust services are distributed as prebuilt Docker images (tags track their own release versions on [`indexer-rs`](https://github.com/graphprotocol/indexer-rs/releases)): + +```sh +docker pull ghcr.io/graphprotocol/indexer-service-rs:latest +docker pull ghcr.io/graphprotocol/indexer-tap-agent:latest +``` + +They can also be built from source with Rust: + +```sh +git clone https://github.com/graphprotocol/indexer-rs.git && cd indexer-rs +cargo build --release -p indexer-service-rs +cargo build --release -p indexer-tap-agent +``` + +Both take a single shared TOML config via `--config`. See [Service & TAP Agent Configuration](/indexing/indexer-software/reference/service-tap-configuration/) and [GraphTally & Query Fees](/indexing/indexer-software/graphtally/). + +### Docker (Agent) + +Prebuilt agent images are published to GitHub Container Registry. + +```sh +docker pull ghcr.io/graphprotocol/indexer-agent:latest +docker run -p 8000:8000 ghcr.io/graphprotocol/indexer-agent:latest start ... +``` + +## Running the agent + +```sh +graph-indexer-agent start \ + --network-provider \ + --graph-node-query-endpoint /subgraphs \ + --graph-node-status-endpoint /graphql \ + --graph-node-admin-endpoint /deploy \ + --mnemonic \ + --indexer-address \ + --postgres-host \ + --postgres-database \ + --network-subgraph-endpoint \ + --epoch-subgraph-endpoint \ + --gateway-endpoint \ + --public-indexer-url +``` + +Every flag can also be set with an `INDEXER_AGENT_`-prefixed environment variable (for example `--network-provider` ↔ `INDEXER_AGENT_ETHEREUM`). See the [Agent Configuration reference](/indexing/indexer-software/reference/agent-configuration/) for the full list. + +## Connecting the CLI + +The CLI talks to the agent's indexer management API (default port `8000`). + +```sh +graph indexer connect http://url.of.indexer-agent:8000/ +``` + +Once connected you can drive the agent: + +```sh +# Set a global rule to allocate to everything at 1000 GRT +graph indexer rules set global decisionBasis always allocationAmount 1000 + +# List your allocations on a network +graph indexer allocations get --network arbitrum-one + +# Inspect the action queue +graph indexer actions get all +``` + +## Database migrations + +The agent, service, and TAP agent share one PostgreSQL database, and **only the Indexer Agent runs migrations** against it. Point `indexer-service-rs` and `indexer-tap-agent` at the same `postgres_url` but never run migrations from the `indexer-rs` stack — doing so risks schema conflicts. The agent manages schema changes with Umzug. From the `indexer-agent` package: + +```sh +yarn migrator:pending # View pending migrations +yarn migrator:executed # View applied migrations +yarn migrator:up # Apply pending migrations +yarn migrator:down # Roll back the last migration +``` + +## Multi-network mode + +To run the agent across multiple protocol networks at once, set `INDEXER_AGENT_MULTINETWORK_MODE=true` and provide a directory of network specification files via `--network-specifications-directory`. See the [Agent Configuration reference](/indexing/indexer-software/reference/agent-configuration/) for the multi-network flag set. + +## Testnet + +The Graph Network testnet runs on **Arbitrum Sepolia**. To participate you need Sepolia ETH and testnet GRT (minimum stake 100k testnet GRT), which you can request through The Graph Discord. You can approve, stake, and set an operator either through [Graph Explorer](https://testnet.thegraph.com/) or the Contracts CLI. See the [Network Configuration reference](/indexing/indexer-software/reference/network-configuration/) for testnet setup details. diff --git a/drafts/indexer-software/managing-provisions.mdx b/drafts/indexer-software/managing-provisions.mdx new file mode 100644 index 000000000000..367cdde69661 --- /dev/null +++ b/drafts/indexer-software/managing-provisions.mdx @@ -0,0 +1,113 @@ +--- +title: Managing Provisions +sidebarTitle: Managing Provisions +--- + +In [Graph Horizon](/graph-horizon/overview/), stake is assigned to **provisions** rather than held as a single pool. A provision commits a portion of your stake to a specific data service — currently the `SubgraphService`, which powers subgraph indexing and query serving. This page explains how provisions work and how to manage them with the Indexer CLI. + +## Stake terminology + +| Term | Meaning | +| --- | --- | +| **Indexer stake** | All tokens the Indexer has staked. | +| **Idle stake** | Stake not assigned to a provision and not part of legacy allocations. | +| **Provisioned stake** | Stake assigned to a provision. | +| **Delegated stake** | Stake delegated to a specific (Indexer, provision). Pre-Horizon delegation is automatically credited to the `SubgraphService` provision. | +| **Available stake** | Stake usable within the provision (for example, for allocations). Includes provisioned tokens plus delegated stake. | + +## Creating the SubgraphService provision + +The **Indexer Agent** performs the initial provision creation. It is attempted only when the agent starts, and only if the Indexer's idle stake exceeds 100k GRT: + +``` +idle stake > 100k GRT +(indexer stake − legacy allocated stake) > 100k GRT +``` + +The agent must be configured with a maximum initial provision size: + +```sh +# Environment variable +INDEXER_AGENT_MAX_PROVISION_INITIAL_SIZE=100000 +``` + +```yaml +# Config file +indexerOptions: + maxProvisionInitialSize: 100000 +``` + +## Provision operations + +There are three basic operations on a provision: + +- **`provision()` / `addToProvision()`** — add idle stake to a provision. +- **`thaw()`** — begin thawing available stake out of a provision (subject to a thawing period). +- **`deprovision()`** — move thawed stake back into the idle stake pool. + +Getting stake into and out of the protocol still requires `stake()` and `unstake()` separately. + +These operations can be run through the Indexer CLI or Graph Explorer. The CLI is recommended because it is more flexible. + +### Graph Explorer + +- Staking through Graph Explorer automatically provisions the added stake to the `SubgraphService` (if the provision exists). +- Unstaking/withdrawing automatically thaws and deprovisions stake from the provision. + +### Indexer CLI + +```sh +$ graph indexer provision --help +Manage indexer's provision + + indexer provision get List indexer provision details + indexer provision add Add stake to the indexer's provision + indexer provision thaw Thaw stake from the indexer's provision + indexer provision list-thaw List thaw requests for the indexer's provision + indexer provision remove Remove thawed stake from the indexer's provision +``` + +> **Note:** The provision must first be created by the Indexer Agent (see above) before these CLI commands can manage it. + +**Get provision details** + +```sh +$ graph indexer --network arbitrum-one provision get +``` + +Shows `tokensProvisioned`, `tokensAllocated`, `tokensThawing`, `maxVerifierCut`, and `thawingPeriod` for each data service, plus your current idle stake. + +**Add stake to the provision** + +```sh +$ graph indexer --network arbitrum-one provision add 100000 +``` + +**Thaw stake from the provision** + +Multiple thaw requests can be in flight simultaneously. Each is subject to the provision's thawing period. + +```sh +$ graph indexer --network arbitrum-one provision thaw 50000 +``` + +**List ongoing thaw requests** + +Also shows thaw requests initiated through Graph Explorer. + +```sh +$ graph indexer --network arbitrum-one provision list-thaw +``` + +**Remove thawed stake** + +Moves thawed stake back into the Indexer's idle stake pool. + +```sh +$ graph indexer --network arbitrum-one provision remove +``` + +## Related + +- [Managing Allocations](/indexing/indexer-software/allocations/overview/) — how provisioned stake is put to work. +- [Graph Horizon Overview](/graph-horizon/overview/) — the architecture behind provisions. diff --git a/drafts/indexer-software/overview.mdx b/drafts/indexer-software/overview.mdx new file mode 100644 index 000000000000..80bc9c984e19 --- /dev/null +++ b/drafts/indexer-software/overview.mdx @@ -0,0 +1,79 @@ +--- +title: Indexer Software Overview +sidebarTitle: Overview +--- + +Indexer Software is the set of components an Indexer runs to participate in The Graph Network: an agent that manages allocations and redeems payments, a Rust service that answers paid queries, a Rust agent that turns query receipts into redeemable vouchers, and a CLI to operate it all. This section covers how to install, configure, and operate that software. For the economics and responsibilities of being an Indexer, see the [Indexing Overview](/indexing/overview/). + +## Components + +The modern Indexer stack spans two repositories — the TypeScript [`indexer`](https://github.com/graphprotocol/indexer) (agent + CLI) and the Rust [`indexer-rs`](https://github.com/graphprotocol/indexer-rs) (service + TAP agent): + +| Component | Language | What it does | +| --- | --- | --- | +| **Indexer Agent** | TypeScript | Monitors the network, manages allocations from your indexing rules, submits POIs, runs provision creation, and redeems RAVs on-chain. Owns database migrations. | +| **Indexer Service** (`indexer-service-rs`) | Rust | Answers paid queries: validates [GraphTally](/indexing/indexer-software/graphtally/) receipts, routes queries to Graph Node, and returns attestations. Stateless and horizontally scalable. | +| **Indexer TAP Agent** (`indexer-tap-agent`) | Rust | Aggregates query-fee receipts into Receipt Aggregate Vouchers (RAVs) and prepares them for redemption. Run **exactly one** instance. | +| **Indexer CLI** | TypeScript | Command-line plugin for `graph-cli` to manage rules, allocations, provisions, cost models, and the action queue: `graph indexer ...` | +| **Indexer Common** | TypeScript | Shared library used by the agent and CLI. Not run directly. | + +> `indexer-service-rs` and `indexer-tap-agent` supersede the legacy TypeScript `indexer-service`. From v2.0.0 they require [Graph Horizon](/graph-horizon/overview/) and no longer process legacy V1 receipts. + +All three runtime components — agent, service, and TAP agent — **share the same PostgreSQL database**. Only the Indexer Agent runs migrations against it; the Rust services read and write the same schema but must not run their own migrations. + +## How the pieces fit together + +``` + ┌────────────────────┐ + │ Indexer CLI │ graph indexer ... + │ (graph-cli plugin)│ + └─────────┬──────────┘ + │ management API (:8000) + query + receipt ▼ + ┌──────────┐ ┌─────────────────────┐ ┌────────────────────┐ ┌──────────────────┐ + │ Gateway │──►│ indexer-service-rs │──►│ Graph Node │ │ Network contracts│ + │ (Sender) │ │ validate + route │ │ (index/query) │ │ + subgraphs │ + └──────────┘ └─────────┬───────────┘ └────────────────────┘ └────────┬─────────┘ + │ receipts ▲ + ▼ │ + ┌────────────────────┐ ┌────────────────────┐ │ + │ PostgreSQL (shared)│◄──────►│ indexer-tap-agent │ │ + └─────────┬───────────┘ RAVs │ receipts → RAVs │ │ + │ └────────────────────┘ │ + ▼ │ + ┌────────────────────┐ allocations, POIs, RAV redemption │ + │ Indexer Agent │─────────────────────────────────────┘ + │ reconciliation loop│ + └────────────────────┘ +``` + +## Architecture at a glance + +The **Indexer Agent** runs a **reconciliation loop**: it continuously compares the deployments you *should* be allocated to (per your [indexing rules](/indexing/indexer-software/allocations/indexing-rules/)) against your actual on-chain allocations, and queues the actions needed to close the gap. How much of this runs automatically is controlled by the [operation mode](/indexing/indexer-software/allocations/operation-modes/). + +The **query-fee path** is handled by the Rust services: `indexer-service-rs` validates each incoming GraphTally receipt and serves the query, and `indexer-tap-agent` aggregates those receipts into RAVs. When an allocation closes, the agent redeems the final RAV on-chain. See [GraphTally & Query Fees](/indexing/indexer-software/graphtally/). + +Underneath, the software relies on: + +- **PostgreSQL** — shared by the agent, service, and TAP agent. Stores indexing rules, the action queue, cost models, POI dispute data, and TAP receipts/RAVs. Migrations are owned by the agent (Umzug). +- **Ethereum / Arbitrum** — on-chain transactions for allocations, provisions, and RAV redemption, submitted through the operator wallet. +- **Network Subgraph** — the source of truth for protocol state (deployments, signal, allocations, and Horizon escrow accounts). +- **GraphTally** — The Graph's trust-minimized micropayment system for query fees (formerly TAP). See [GraphTally & Query Fees](/indexing/indexer-software/graphtally/). + +## Graph Horizon support + +The Indexer Software supports [Graph Horizon](/graph-horizon/overview/), the protocol's data-services architecture. Key differences you'll encounter throughout this section: + +- **Provisions** replace the legacy single-stake model. Stake is provisioned to the `SubgraphService` data service. See [Managing Provisions](/indexing/indexer-software/managing-provisions/). +- **New allocation operations** are available: `present-poi` (collect rewards without closing) and `resize` (change allocation size without closing). +- **GraphTally (TAP v2)** uses collection-based aggregation with RAV v2; from `indexer-service-rs`/`indexer-tap-agent` v2.0.0, Horizon is required and V1 receipts are removed. +- The agent runs a **dual-contract system**, supporting legacy and Horizon contracts simultaneously, and detects Horizon-enabled networks automatically. + +Horizon-only commands and options are marked as such throughout these pages. + +## Where to go next + +- [Install and Run](/indexing/indexer-software/install-and-run/) — get the agent, service, and TAP agent running. +- [Managing Allocations](/indexing/indexer-software/allocations/overview/) — the core day-to-day workflow. +- [GraphTally & Query Fees](/indexing/indexer-software/graphtally/) — how you get paid for queries. +- [Reference](/indexing/indexer-software/reference/agent-configuration/) — full agent flags, service/TAP config, and CLI commands. diff --git a/drafts/indexer-software/reference/_meta-titles.json b/drafts/indexer-software/reference/_meta-titles.json new file mode 100644 index 000000000000..0967ef424bce --- /dev/null +++ b/drafts/indexer-software/reference/_meta-titles.json @@ -0,0 +1 @@ +{} diff --git a/drafts/indexer-software/reference/_meta.js b/drafts/indexer-software/reference/_meta.js new file mode 100644 index 000000000000..e937e782dd30 --- /dev/null +++ b/drafts/indexer-software/reference/_meta.js @@ -0,0 +1,8 @@ +export default { + 'agent-configuration': '', + 'service-tap-configuration': 'Service & TAP Agent Config', + 'cli-reference': 'CLI Command Reference', + 'network-configuration': '', + 'feature-support-matrix': '', + 'error-codes': '', +} diff --git a/drafts/indexer-software/reference/agent-configuration.mdx b/drafts/indexer-software/reference/agent-configuration.mdx new file mode 100644 index 000000000000..5a43861858bb --- /dev/null +++ b/drafts/indexer-software/reference/agent-configuration.mdx @@ -0,0 +1,118 @@ +--- +title: Agent Configuration +sidebarTitle: Agent Configuration +--- + +Full configuration reference for `graph-indexer-agent start`. Every flag has a matching `INDEXER_AGENT_`-prefixed environment variable. For a task-oriented walkthrough, see [Install and Run](/indexing/indexer-software/install-and-run/). + +> This reference reflects the agent's `--help` output. Run `graph-indexer-agent start --help` against your installed version for the authoritative list, as defaults and options change between releases. + +## Indexer infrastructure + +| Flag | Description | Default | +| --- | --- | --- | +| `--indexer-management-port` | Port for the indexer management API. | `8000` | +| `--metrics-port` | Port for Prometheus metrics. | `7300` | +| `--syncing-port` | Port serving the Network Subgraph and other syncing data for the indexer service. | `8002` | +| `--log-level` | Log level. | `debug` | +| `--polling-interval` | Polling interval for data collection (ms). | `120000` | +| `--ipfs-endpoint` | IPFS endpoint for querying manifests. | `https://ipfs.network.thegraph.com` | +| `--enable-auto-graft` | Automatically deploy and sync graft dependencies. See [Auto-Graft](/indexing/indexer-software/auto-graft/). | `false` | +| `--graph-node-query-endpoint` | Graph Node endpoint for querying subgraphs. | *required* | +| `--graph-node-status-endpoint` | Graph Node endpoint for indexing statuses. | *required* | +| `--graph-node-admin-endpoint` | Graph Node endpoint for applying/updating deployments. | *required* | +| `--deployment-management` | Subgraph deployment management mode (`auto` \| `manual`). | `auto` | +| `--public-indexer-url` | Indexer endpoint for receiving requests from the network. | *required* | +| `--indexer-geo-coordinates` | Indexer location (latitude, longitude). | — | +| `--restake-rewards` | Restake claimed rewards; if `false`, rewards go to the wallet. | `true` | +| `--allocation-management` | Allocation automation mode (`auto` \| `manual` \| `oversight`). See [Operation Modes](/indexing/indexer-software/allocations/operation-modes/). | `auto` | +| `--auto-allocation-min-batch-size` | Minimum allocation transactions per batch. | `1` | +| `--auto-allocation-max-batch-size` | Maximum allocation transactions per batch (prevents multicall failures). | — | +| `--enable-auto-migration-support` | Auto-migrate allocations from L1 to L2 (multi-network mode only). | `false` | + +## Postgres + +| Flag | Description | Default | +| --- | --- | --- | +| `--postgres-host` | Postgres host. | *required* | +| `--postgres-port` | Postgres port. | `5432` | +| `--postgres-username` | Postgres username. | `postgres` | +| `--postgres-password` | Postgres password. | `""` | +| `--postgres-database` | Postgres database name. | *required* | +| `--postgres-sslenabled` | Enable Postgres SSL. | `false` | +| `--postgres-pool-size` | Maximum connection pool size. | `50` | + +## Ethereum + +| Flag | Description | Default | +| --- | --- | --- | +| `--network-provider`, `--ethereum` | Ethereum node or provider URL. | *required* | +| `--ethereum-polling-interval` | Provider polling interval (ms). | `4000` | +| `--gas-increase-timeout` | Seconds after which transactions are resubmitted with higher gas. | `240` | +| `--gas-increase-factor` | Factor by which gas is increased on resubmission. | `1.2` | +| `--base-fee-per-gas-max` | Max base fee per gas (gwei). | — | +| `--transaction-attempts` | Max transaction attempts (`0` = unlimited). | `0` | +| `--confirmation-blocks` | Blocks to wait for confirmation. | `3` | +| `--mnemonic` | Operator wallet mnemonic. | *required* | +| `--indexer-address` | Ethereum address of the Indexer. | *required* | +| `--payments-destination` | Address to send payments to; if unset, payments are restaked. | — | + +## Network Subgraph + +| Flag | Description | Default | +| --- | --- | --- | +| `--network-subgraph-deployment` | Network Subgraph deployment. | — | +| `--network-subgraph-endpoint` | Endpoint to query the Network Subgraph. | — | +| `--allocate-on-network-subgraph` | Whether to allocate to the Network Subgraph. | `false` | +| `--epoch-subgraph-deployment` | Epoch Subgraph deployment (for local hosting). | — | + +## TAP Subgraph + +| Flag | Description | +| --- | --- | +| `--tap-subgraph-deployment` | TAP (GraphTally) subgraph deployment. | +| `--tap-subgraph-endpoint` | Endpoint to query the TAP subgraph. | + +## Protocol + +| Flag | Description | Default | +| --- | --- | --- | +| `--epoch-subgraph-endpoint` | Endpoint for the epoch block oracle subgraph. | *required* | +| `--subgraph-max-block-distance` | Blocks a subgraph may lag behind the chain head. See [Subgraph Freshness](/indexing/indexer-software/subgraph-freshness/). | `1000` | +| `--subgraph-freshness-sleep-milliseconds` | Wait before retrying a stale subgraph query. | `5000` | +| `--default-allocation-amount` | Default GRT to allocate to a deployment. | `0.01` | +| `--register` | Whether to register the Indexer on chain. | `true` | +| `--max-provision-initial-size` | Initial SubgraphService provision size (Horizon). See [Managing Provisions](/indexing/indexer-software/managing-provisions/). | `0` | + +## Query fees + +| Flag | Description | Default | +| --- | --- | --- | +| `--rebate-claim-threshold` | Min rebate value (GRT) for a single allocation to be batched. | `1` | +| `--rebate-claim-batch-threshold` | Min total rebate value (GRT) before a batch is claimed. | `5` | +| `--rebate-claim-max-batch-size` | Max rebates per batch. | `100` | +| `--voucher-redemption-threshold` | Min rebate value (GRT) for a single allocation to be redeemed. | `1` | +| `--voucher-redemption-batch-threshold` | Min total value (GRT) before a batch is redeemed. | `5` | +| `--voucher-redemption-max-batch-size` | Max vouchers per batch. | `100` | +| `--gateway-endpoint`, `--collect-receipts-endpoint` | Gateway endpoint base URL. | *required* | + +## Disputes + +| Flag | Description | Default | +| --- | --- | --- | +| `--poi-disputable-epochs` | Past epochs to scan for potential POI disputes. | `1` | +| `--poi-dispute-monitoring` | Monitor the network for potential POI disputes. See [Dispute Monitoring](/indexing/indexer-software/dispute-monitoring/). | `false` | + +## Horizon and other options + +| Flag | Description | +| --- | --- | +| `--offchain-subgraphs` | Subgraphs to index that are not on chain (comma-separated). | +| `--horizon-address-book` | Graph Horizon contracts address book path. | +| `--subgraph-service-address-book` | SubgraphService contracts address book path. | +| `--tap-address-book` | TAP contracts address book path. | +| `--chain-finalize-time` | Seconds the chain takes to finalize blocks. Default `3600`. | + +## Multi-network mode + +Set `INDEXER_AGENT_MULTINETWORK_MODE=true` and provide `--network-specifications-directory` (`--dir`) pointing at a directory of network specification files. In multi-network mode, per-network Ethereum/protocol settings come from those spec files rather than individual flags. diff --git a/drafts/indexer-software/reference/cli-reference.mdx b/drafts/indexer-software/reference/cli-reference.mdx new file mode 100644 index 000000000000..8d159828ace4 --- /dev/null +++ b/drafts/indexer-software/reference/cli-reference.mdx @@ -0,0 +1,99 @@ +--- +title: CLI Command Reference +sidebarTitle: CLI Command Reference +--- + +Complete command listing for the Indexer CLI (`graph indexer ...`), a plugin for [`graph-cli`](https://github.com/graphprotocol/graph-cli). This page is the canonical command reference; the task pages linked below explain when and how to use each group. + +> Run `graph indexer --help` (or `graph indexer --help`) against your installed version for the authoritative list. + +## Connecting + +```sh +graph indexer connect http://url.of.indexer-agent:8000/ +``` + +Connects the CLI to the agent's [indexer management API](/indexing/indexer-software/install-and-run/#connecting-the-cli). + +## Status + +| Command | Description | +| --- | --- | +| `indexer status` | Check the status of an Indexer. | + +## Rules + +See [Indexing Rules](/indexing/indexer-software/allocations/indexing-rules/). + +| Command | Description | +| --- | --- | +| `indexer rules get` | Get one or more indexing rules. | +| `indexer rules set` | Set one or more indexing rules. | +| `indexer rules start` (`always`) | Always index a deployment (start indexing if needed). | +| `indexer rules stop` (`never`) | Never index a deployment (stop indexing if needed). | +| `indexer rules maybe` | Index a deployment based on `rules` thresholds. | +| `indexer rules prepare` (`offchain`) | Offchain-index a deployment. | +| `indexer rules clear` (`reset`) | Clear one or more indexing rules. | +| `indexer rules delete` | Remove one or many indexing rules. | + +## Allocations + +See [Direct Commands](/indexing/indexer-software/allocations/direct-commands/). + +| Command | Description | +| --- | --- | +| `indexer allocations get` | List one or more allocations. | +| `indexer allocations create` | Create an allocation. | +| `indexer allocations close` | Close an allocation. | +| `indexer allocations reallocate` | Reallocate to a subgraph deployment. | +| `indexer allocations collect` | Collect receipts for an allocation. | +| `indexer allocations present-poi` | Present POI and collect rewards without closing *(Horizon)*. | +| `indexer allocations resize` | Resize allocation stake without closing *(Horizon)*. | + +## Actions + +See [Action Queue](/indexing/indexer-software/allocations/action-queue/). + +| Command | Description | +| --- | --- | +| `indexer actions get` | List one or more actions. | +| `indexer actions queue` | Queue an action (allocate, unallocate, reallocate, present-poi, resize). | +| `indexer actions approve` | Approve an action item. | +| `indexer actions execute` | Execute approved items in the queue. | +| `indexer actions update` | Update one or more actions. | +| `indexer actions cancel` | Cancel an item in the queue. | +| `indexer actions delete` | Delete one or many actions. | + +## Provision *(Horizon)* + +See [Managing Provisions](/indexing/indexer-software/managing-provisions/). + +| Command | Description | +| --- | --- | +| `indexer provision get` | List provision details. | +| `indexer provision add` | Add stake to the provision. | +| `indexer provision thaw` | Thaw stake from the provision. | +| `indexer provision list-thaw` | List thaw requests. | +| `indexer provision remove` | Remove thawed stake from the provision. | + +## Cost + +See [Cost Models](/indexing/indexer-software/cost-models/). + +| Command | Description | +| --- | --- | +| `indexer cost get` | Get cost models for one or all subgraphs. | +| `indexer cost set model` | Update a cost model. | +| `indexer cost delete` | Remove one or many cost models. | + +## Disputes + +See [Dispute Monitoring](/indexing/indexer-software/dispute-monitoring/). + +| Command | Description | +| --- | --- | +| `indexer disputes get` | Cross-check POIs submitted in the network. | + +## Output format + +Most read commands accept `-o, --output` with `table` (default), `json`, or `yaml`, and allocation commands require `-n, --network`. diff --git a/drafts/indexer-software/reference/error-codes.mdx b/drafts/indexer-software/reference/error-codes.mdx new file mode 100644 index 000000000000..e5526b698dc3 --- /dev/null +++ b/drafts/indexer-software/reference/error-codes.mdx @@ -0,0 +1,99 @@ +--- +title: Error Codes +sidebarTitle: Error Codes +--- + +The Indexer Agent and Service tag errors with `IE0xx` codes. This page lists every code and its meaning. To isolate a code in your logs: + +```bash +grep | grep IE004 +``` + +If a code points at an unhealthy dependency you can't explain, collect the matching logs and file an issue at [github.com/graphprotocol/indexer](https://github.com/graphprotocol/indexer/issues). + +## Frequently seen codes + +A few codes have detailed guidance worth calling out: + +- **IE004 — Failed to synchronize with network.** The agent can't fetch data from the contracts, the Network Subgraph, the Graph Node status API, or its own database. Isolate which dependency is failing: an unhealthy or rate-limiting Ethereum provider, an unreachable/outdated Network Subgraph endpoint, a Graph Node connectivity problem, or a database issue. Switching provider, fixing connectivity, or upgrading the provider subscription typically resolves it. +- **IE005 — Failed to reconcile indexer and network.** The agent couldn't start/stop deployments, open/close allocations, or claim rebates. Common causes: can't reach Graph Node, allocation transactions failing from lack of ETH, or no free stake to allocate. See also IE013 and IE020. +- **IE013 — Insufficient free stake.** All stake is locked in existing allocations. Reduce allocation amounts and wait for allocations to close and release GRT; it resolves automatically. +- **IE034 — Not authorized as an operator.** The operator address isn't registered for the Indexer. Add the operator address (included in the error message) to your Indexer in Graph Explorer. +- **IE067 — POI not available at current epoch start block.** The deployment is too far behind chain head to resolve a valid POI. Wait for it to sync, or forfeit rewards by force-closing with a zero POI: `graph indexer actions queue unallocate 0 true`. +- **IE068 — Provided POI doesn't match graph-node reference.** Check the subgraph's sync and health; provide a valid POI or use `--force` to bypass POI checks. + +## Full code list + +| Code | Summary | +| --- | --- | +| IE001 | Unable to run database migrations. | +| IE002 | The URL used to connect to Ethereum is invalid. | +| IE003 | Failed to index Network Subgraph. | +| IE004 | Failed to synchronize with network. | +| IE005 | Failed to reconcile indexer and network. | +| IE006 | Failed to cross-check allocation state with contracts. | +| IE007 | Failed to check for network pause. | +| IE008 | Failed to check operator status for indexer. | +| IE009 | Failed to query subgraph deployments worth indexing. | +| IE010 | Failed to query indexer allocations. | +| IE011 | Failed to query claimable indexer allocations. | +| IE012 | Failed to register indexer. | +| IE013 | Failed to allocate: insufficient free stake. | +| IE014 | Failed to allocate: allocation not created on chain. | +| IE015 | Failed to close allocation. | +| IE016 | Failed to claim allocation. | +| IE017 | Failed to ensure default global indexing rule. | +| IE018 | Failed to query indexing status API. | +| IE019 | Failed to query proof of indexing. | +| IE020 | Failed to ensure subgraph deployment is indexing. | +| IE021 | Failed to migrate cost model. | +| IE022 | Failed to identify attestation signer for allocation. | +| IE023 | Failed to handle state channel message. | +| IE024 | Failed to connect to indexing status API. | +| IE025 | Failed to query indexer management API. | +| IE026 | Failed to deploy subgraph deployment (sub-error of IE020). | +| IE027 | Failed to remove subgraph deployment. | +| IE028 | Failed to reassign subgraph deployment. | +| IE029 | Invalid Scalar-Receipt header provided. | +| IE030 | No Scalar-Receipt header provided. | +| IE031 | Invalid Scalar-Receipt value provided. | +| IE032 | Failed to process paid query. | +| IE033 | Failed to process free query. | +| IE034 | Not authorized as an operator for the indexer. | +| IE035 | Unhandled promise rejection (often internal to ethers.js). | +| IE036 | Unhandled error somewhere in the system. | +| IE037 | *(Reserved / undocumented.)* | +| IE038 | *(Reserved / undocumented.)* | +| IE039 | *(Reserved / undocumented.)* | +| IE040 | *(Reserved / undocumented.)* | +| IE041 | Problem looking up Vector transfers for closed allocations (DB). | +| IE042 | A Vector transfer cannot be stored in the database. | +| IE043 | A Vector transfer cannot be marked as resolved in the database. | +| IE044 | Failed to collect query fees on chain. | +| IE045 | Failed to queue transfers for resolving. | +| IE046 | Failed to resolve transfer. | +| IE047 | Failed to mark transfer as failed. | +| IE048 | Failed to withdraw query fees for allocation. | +| IE049 | Failed to clean up transfers for allocation. | +| IE050 | Transaction reverted due to gas limit being hit. | +| IE051 | Transaction reverted for unknown reason. | +| IE052 | Transaction aborted: maximum configured gas price reached. | +| IE053 | Failed to queue receipts for collecting. | +| IE054 | Failed to collect receipts in exchange for query fee voucher. | +| IE055 | Failed to redeem query fee voucher. | +| IE056 | Failed to remember allocation for collecting receipts later. | +| IE057 | Transaction reverted due to failing assertion in contract. | +| IE058 | Transaction failed because nonce has already been used. | +| IE059 | Failed to check latest operator ETH balance. | +| IE060 | Failed to allocate: subgraph is already allocated to. | +| IE061 | Failed to allocate: invalid allocation amount provided. | +| IE062 | Action not executed: contracts paused or operator not authorized. | +| IE063 | Failed to unallocate: no active allocation with provided id. | +| IE064 | Failed to unallocate: allocation created in the current epoch. | +| IE065 | Failed to unallocate: allocation already closed. | +| IE066 | Allocation not created: allocation ID already exists. | +| IE067 | Failed to resolve POI: POI not available at current epoch start block. | +| IE068 | Failed to resolve POI: provided POI doesn't match graph-node reference. | +| IE069 | Failed to query Epoch Block Oracle Subgraph. | +| IE070 | Failed to query BlockHashFromNumber from graph-node. | +| IE071 | Epoch subgraph required for networks whose RPC isn't provided (sub-error of IE069). | diff --git a/drafts/indexer-software/reference/feature-support-matrix.mdx b/drafts/indexer-software/reference/feature-support-matrix.mdx new file mode 100644 index 000000000000..6c7caaace7b9 --- /dev/null +++ b/drafts/indexer-software/reference/feature-support-matrix.mdx @@ -0,0 +1,71 @@ +--- +title: Feature Support Matrix +sidebarTitle: Feature Support Matrix +--- + +As described in [GIP-0008](https://snapshot.org/#/council.graphprotocol.eth/proposal/0xbdd884654a393620a7e8665b4289201b7542c3ee62becfad133e951b0c408444), the **Feature Support Matrix** defines which indexing and querying features are experimental or not fully supported for indexing/query rewards and arbitration. The matrix below reflects the canonical Council-ratified version; ratification is required for each update. + +> This page mirrors the matrix maintained in the indexer repository. Treat the source matrix and the accepted `graph-node` version range as authoritative for arbitration purposes. + +## Core features + +| Subgraph feature | Implemented | Experimental | Query arbitration | Indexing arbitration | Indexing rewards | +| --- | --- | --- | --- | --- | --- | +| Full-text Search | Yes | No | No | Yes | Yes | +| Non-Fatal Errors | Yes | Yes | Yes | Yes | Yes | +| Grafting | Yes | Yes | Yes | Yes | Yes | + +## Data source types + +| Network (alias) | Implemented | Experimental | Query arbitration | Indexing arbitration | Indexing rewards | +| --- | --- | --- | --- | --- | --- | +| `eip155:*` (\*) | Yes | No | No | No | No | +| `eip155:1` (mainnet) | Yes | No | Yes | Yes | Yes | +| `eip155:100` (gnosis) | Yes | Yes | Yes | Yes | Yes | +| `near:*` (\*) | Yes | Yes | No | No | No | +| `eip155:42161` (arbitrum-one) | Yes | Yes | Yes | Yes | Yes | +| `eip155:42220` (celo) | Yes | Yes | Yes | Yes | Yes | +| `eip155:43114` (avalanche) | Yes | Yes | Yes | Yes | Yes | +| `eip155:250` (fantom) | Yes | Yes | Yes | Yes | Yes | +| `eip155:137` (polygon) | Yes | Yes | Yes | Yes | Yes | +| `eip155:10` (optimism) | Yes | Yes | Yes | Yes | Yes | +| `eip155:8453` (base) | Yes | Yes | Yes | Yes | Yes | +| `eip155:534352` (scroll) | Yes | Yes | Yes | Yes | Yes | +| `eip155:59144` (linea) | Yes | Yes | Yes | Yes | Yes | +| `eip155:56` (bsc) | Yes | Yes | Yes | Yes | Yes | +| `eip155:7777777` (zora) | Yes | Yes | Yes | Yes | Yes | +| `eip155:1284` (moonbeam) | Yes | Yes | Yes | Yes | Yes | +| `eip155:30` (rootstock) | Yes | Yes | Yes | Yes | Yes | +| `eip155:11155111` (sepolia) | Yes | Yes | Yes | Yes | Yes | +| `eip155:97` (chapel) | Yes | Yes | Yes | Yes | Yes | +| `eip155:130` (unichain) | Yes | Yes | Yes | Yes | Yes | + +`arweave:*` was deprecated in graph-node v0.39.0. + +## Data source features + +| Feature | Implemented | Experimental | Query arbitration | Indexing arbitration | Indexing rewards | +| --- | --- | --- | --- | --- | --- | +| `ipfs.cat` in mappings | Yes | Yes | No | No | No | +| ENS | Yes | Yes | Yes | Yes | Yes | +| File data sources: Arweave | Yes | Yes | No | Yes | Yes | +| File data sources: IPFS | Yes | Yes | No | Yes | Yes | +| Substreams: mainnet | Yes | Yes | Yes | Yes | Yes | +| Substreams: optimism | Yes | Yes | Yes | Yes | Yes | + +## Accepted graph-node version range + +The matrix always specifies an accepted `graph-node` range comprising the latest version and the one immediately preceding it: + +``` +graph-node: >=0.38.0 <=0.44.0 +``` + +## Notes + +- A single matrix currently reflects protocol behaviour for both Ethereum mainnet and Arbitrum One. +- Aliases can be used in subgraph manifests to refer to specific networks. +- Experimental features are generally not fully supported for indexing rewards and arbitration; their use is considered during any arbitration. +- Query fees apply to all queries regardless of the features a subgraph uses. +- Features not named in the matrix are assumed to be fully supported for rewards and arbitration. +- Under [GGP-0057](https://snapshot.box/#/s:council.graphprotocol.eth/proposal/0x4eff14202f6204c0927860a9adff865fce33c32b6cbe7054227457631ee261b9), authority to approve new chain integrations and deprecate chains is delegated to The Graph Foundation, contingent on Technical Advisory Board (TAB) approval; the Council retains override authority. diff --git a/drafts/indexer-software/reference/network-configuration.mdx b/drafts/indexer-software/reference/network-configuration.mdx new file mode 100644 index 000000000000..43a694359e5d --- /dev/null +++ b/drafts/indexer-software/reference/network-configuration.mdx @@ -0,0 +1,59 @@ +--- +title: Network Configuration +sidebarTitle: Network Configuration +--- + +The Indexer Software runs on The Graph Network's mainnet (Arbitrum One) and testnet (Arbitrum Sepolia). This page covers network-specific configuration and testnet onboarding. + +> For the canonical, up-to-date list of which chains are supported for indexing and querying, refer to The Graph's [Supported Networks](/supported-networks/) page and the [Feature Support Matrix](/indexing/indexer-software/reference/feature-support-matrix/). Do not infer chain support from configuration examples alone. + +## Protocol networks + +The `--network` / protocol-network values used across the CLI and agent include `mainnet`, `arbitrum-one`, `sepolia`, and `arbitrum-sepolia`. The Graph Network protocol itself runs on **Arbitrum One** (mainnet) and **Arbitrum Sepolia** (testnet). + +## Mainnet + +Configure the agent with mainnet endpoints and an Arbitrum One protocol network. See the [Agent Configuration reference](/indexing/indexer-software/reference/agent-configuration/) for every flag, and [Deploy the Stack](/indexing/indexer-software/deployment/overview/) for a full Docker-based mainnet deployment. + +## Testnet (Arbitrum Sepolia) + +The Graph Network testnet runs on **Arbitrum Sepolia**. Network information is available at the [testnet explorer](https://testnet.thegraph.com/explorer/network). + +### Registration and funding + +To participate you need Sepolia ETH and testnet GRT: + +1. Join [The Graph Discord](https://thegraph.com/discord/). +2. Get the `@testnetindexer` role in the `#roles` channel. +3. Request testnet GRT in the `#arbi-sepolia-faucet` channel. + +### Staking + +The testnet is open to everyone; the only requirement is a minimum stake of **100k testnet GRT**. You can approve and stake either through [Graph Explorer](https://testnet.thegraph.com/) (Metamask → Arbitrum Sepolia → your profile → Indexing → Stake) or the Contracts CLI: + +```bash +git clone https://github.com/graphprotocol/contracts +cd contracts +npm install && npm run compile + +# Approve GRT to be spent by the staking contract +./cli/cli.ts -m -p \ + contracts graphToken approve --account --amount + +# Stake +./cli/cli.ts -m -p \ + contracts staking stake --amount +``` + +### Setting an operator + +Use a separate operator wallet to send transactions on behalf of your staking wallet. Set it via Graph Explorer (Settings → Operators) or the Contracts CLI: + +```bash +./cli/cli.ts -m -p \ + contracts staking setOperator --operator --allowed true +``` + +## Subgraph freshness per network + +Block-distance defaults were tuned for Arbitrum One. On other networks, adjust `maxBlockDistance` and `freshnessSleepMilliseconds` to the chain's block rate — see [Subgraph Freshness](/indexing/indexer-software/subgraph-freshness/). diff --git a/drafts/indexer-software/reference/service-tap-configuration.mdx b/drafts/indexer-software/reference/service-tap-configuration.mdx new file mode 100644 index 000000000000..6fcbae2b96cd --- /dev/null +++ b/drafts/indexer-software/reference/service-tap-configuration.mdx @@ -0,0 +1,123 @@ +--- +title: Service & TAP Agent Configuration +sidebarTitle: Service & TAP Agent Config +--- + +Configuration reference for the Rust `indexer-service-rs` and `indexer-tap-agent` (the [`indexer-rs`](https://github.com/graphprotocol/indexer-rs) stack). Both binaries take a single shared TOML file via `--config`. For how these components fit into query-fee collection, see [GraphTally & Query Fees](/indexing/indexer-software/graphtally/); for the TypeScript agent's flags, see [Agent Configuration](/indexing/indexer-software/reference/agent-configuration/). + +> Authoritative templates live in the repo: the [minimal config](https://github.com/graphprotocol/indexer-rs/blob/main/crates/config/minimal-config-example.toml) (recommended), the [maximal config](https://github.com/graphprotocol/indexer-rs/blob/main/crates/config/maximal-config-example.toml), and [default values](https://github.com/graphprotocol/indexer-rs/blob/main/crates/config/default_values.toml). + +## Running + +```sh +indexer-service-rs --config /path/to/config.toml +indexer-tap-agent --config /path/to/config.toml +``` + +Both read the same file. `postgres_url` must point at the **same database as `indexer-agent`**, and you must not run migrations from the `indexer-rs` stack — the agent owns migrations. + +## Example configuration + +```toml +[indexer] +indexer_address = "0x1111111111111111111111111111111111111111" +operator_mnemonic = "your twelve word mnemonic phrase here ..." +# For key rotation, specify multiple mnemonics; all are tried when creating +# attestation signers. The first is the primary identity on /info. +# operator_mnemonics = ["previous mnemonic phrase here if you rotated keys"] + +[database] +postgres_url = "postgresql://user:password@localhost:5432/indexer_db" + +[graph_node] +query_url = "http://graph-node:8000" +status_url = "http://graph-node:8000/graphql" + +[subgraphs.network] +# Network Subgraph (includes Horizon escrow data). Prefer local indexing via deployment_id. +query_url = "https://api.thegraph.com/subgraphs/name/graphprotocol/graph-network-arbitrum" +# deployment_id = "Qm..." + +[blockchain] +chain_id = 42161 +receipts_verifier_address_v2 = "0x8f69F5C07477Ac46FBc491B1E6D91E2be0111A9e" +subgraph_service_address = "0xb2Bb92d0DE618878E438b55D5846cfecD9301105" + +[tap] +max_amount_willing_to_lose_grt = "0.1" + +[tap.sender_aggregator_endpoints] +"0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467" = "https://tap-aggregator.network.thegraph.com" + +[horizon] +enabled = true +``` + +Swap the `[blockchain]` and aggregator values for testnet (`chain_id = 421614`, the Arbitrum Sepolia addresses). See the full address tables in [GraphTally & Query Fees](/indexing/indexer-software/graphtally/#blockchain-addresses). + +## Required fields + +| Field | Section | Description | +| --- | --- | --- | +| `indexer_address` | `[indexer]` | Your Indexer's Ethereum address. | +| `operator_mnemonic` | `[indexer]` | BIP-39 mnemonic for the operator wallet. | +| `postgres_url` | `[database]` | PostgreSQL connection URL (same DB as the agent). | +| `query_url` | `[graph_node]` | Graph Node query endpoint. | +| `status_url` | `[graph_node]` | Graph Node status endpoint. | +| `query_url` or `deployment_id` | `[subgraphs.network]` | Network Subgraph endpoint. | +| `chain_id` | `[blockchain]` | Network chain ID (`42161` Arbitrum One, `421614` Arbitrum Sepolia). | +| `receipts_verifier_address_v2` | `[blockchain]` | TAP Verifier contract address. | +| `subgraph_service_address` | `[blockchain]` | SubgraphService contract address. | +| `enabled = true` | `[horizon]` | Horizon mode — required from v2.0.0. | + +## Environment variable overrides + +Any value can be overridden with environment variables, prefixed per binary and using `__` for nested fields: + +```bash +# Pattern: [PREFIX]__[SECTION]__[KEY] (PREFIX: INDEXER_SERVICE or TAP_AGENT) +export INDEXER_SERVICE__DATABASE__POSTGRES_URL="postgresql://..." +export TAP_AGENT__TAP__MAX_AMOUNT_WILLING_TO_LOSE_GRT="0.5" +``` + +## Routes (indexer-service-rs) + +| Route | Description | +| --- | --- | +| `/` | Greeting message. | +| `/info` | Operator's public address. | +| `/healthz` | Dependency health (database + Graph Node); HTTP 200 healthy, 503 otherwise. | +| `/version` | Service version and dependencies. | +| `/subgraphs/id/{id}` | Paid query endpoint; requires a receipt or valid token. | +| `/subgraph/health/{id}` | Subgraph health state. | +| `/status` | Routes to the Graph Node status API. | +| `/cost` | Cost Model GraphQL API. See [Cost Models](/indexing/indexer-software/cost-models/). | +| `/dips` | DIPs (Direct Indexing Payments) GraphQL API. | +| `/escrow` | Escrow subgraph proxy (token-protected). | +| `/network` | Network Subgraph proxy (token-protected). | + +## Logging + +```bash +# Production +export RUST_LOG=indexer_service=info,indexer_tap_agent=info +# Debugging the receipt/RAV lifecycle +export RUST_LOG=indexer_service=debug,indexer_tap_agent=debug +``` + +## Upgrading to v2.0.0 + +v2.0.0 removes legacy V1 receipts; all processing uses Graph Horizon (GraphTally) exclusively. + +- **Horizon is required** — `[horizon].enabled = true`; configs with `enabled = false` are rejected at startup. +- **`receipts_verifier_address_v2` and `subgraph_service_address` are required** under `[blockchain]`. +- **`receipts_verifier_address` (V1) is deprecated** and can be removed. +- **Escrow data comes from the Network Subgraph**, not a separate escrow subgraph; the `[subgraphs.escrow]` section can be removed unless you proxy the escrow subgraph via `serve_escrow_subgraph = true`. +- **Redeem all V1 RAVs before upgrading** — the new version cannot process V1 receipts. + +After updating config and pulling the latest images, restart both services. + +## Deployment + +- **Docker Compose** — run `indexer-service-rs` (ports `7600` query, `7300` metrics) and `indexer-tap-agent` (metrics `7300`, commonly remapped to `7301`) with the config mounted and `RUST_LOG` set. See [Deploy the Stack](/indexing/indexer-software/deployment/overview/). +- **Kubernetes** — the [Graph Launchpad charts](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer) include Helm charts, ConfigMap templates, and Prometheus ServiceMonitors for both services. diff --git a/drafts/indexer-software/subgraph-freshness.mdx b/drafts/indexer-software/subgraph-freshness.mdx new file mode 100644 index 000000000000..5acc8b4e1685 --- /dev/null +++ b/drafts/indexer-software/subgraph-freshness.mdx @@ -0,0 +1,37 @@ +--- +title: Subgraph Freshness +sidebarTitle: Subgraph Freshness +--- + +The **Subgraph Freshness Checker** improves the reliability of query responses when a subgraph might lag behind the chain head. It compares the subgraph's latest indexed block against the most recent block on the network and, if the gap is too large, retries the query and emits a warning rather than serving stale data. + +## How it works + +If a subgraph is further behind the chain head than an allowed distance, the checker retries the query after a short sleep, logging the current block distance from the chain head. This continues until the subgraph is fresh enough to serve. + +## Configuration + +Two settings control the behavior. They can be set via CLI flags/environment variables or in a network specification file. + +| Option | Description | Default | +| --- | --- | --- | +| `maxBlockDistance` | Acceptable distance, in blocks, between the subgraph's latest indexed block and the chain head. Beyond this, the subgraph is considered stale. | `1000` | +| `freshnessSleepMilliseconds` | How long to wait before retrying a query deemed stale. | `10000` (10s) | + +The corresponding agent flags are `--subgraph-max-block-distance` and `--subgraph-freshness-sleep-milliseconds`. + +### Network specification example + +```yaml +subgraphs: + maxBlockDistance: 5000 + freshnessSleepMilliseconds: 10000 +``` + +## Choosing values per network + +The defaults were established from **Arbitrum One** observations. High-throughput chains produce blocks quickly, so a value tuned for one network may be wrong for another. If the agent or service uses default (Ethereum-oriented) settings on a fast network like Arbitrum, queries may be considered non-fresh indefinitely — the software will warn you when it detects this risk. Adjust `maxBlockDistance` and `freshnessSleepMilliseconds` to match each network's block rate. + +## Disabling the check + +Setting a very high `maxBlockDistance` effectively disables the freshness check, because the distance condition will always pass. diff --git a/drafts/indexer-software/troubleshooting.mdx b/drafts/indexer-software/troubleshooting.mdx new file mode 100644 index 000000000000..92087ce482b1 --- /dev/null +++ b/drafts/indexer-software/troubleshooting.mdx @@ -0,0 +1,44 @@ +--- +title: Troubleshooting +sidebarTitle: Troubleshooting +--- + +Common issues when running the Indexer Software and where to look. For coded agent errors (`IE001`, `IE004`, …), see the [Error Codes reference](/indexing/indexer-software/reference/error-codes/). + +## The agent starts but nothing allocates + +- Confirm the [operation mode](/indexing/indexer-software/allocations/operation-modes/). In **MANUAL** mode the reconciliation loop is skipped and [indexing rules](/indexing/indexer-software/allocations/indexing-rules/) have no effect. +- Check your rules: a `global` rule of `never`, or missing thresholds under `decisionBasis: rules`, can mean nothing qualifies. +- In **OVERSIGHT** mode, actions wait in the [action queue](/indexing/indexer-software/allocations/action-queue/) until you approve them. + +## The agent can't sync with the network (`IE004`) + +Usually one of: an unhealthy or rate-limiting Ethereum provider, an unreachable or outdated Network Subgraph endpoint, an unreachable Graph Node status API, or a database connection problem. Isolate which dependency is failing from the error logs. See [Error Codes](/indexing/indexer-software/reference/error-codes/) for the full breakdown. + +## Database migration failures (`IE001`) + +The agent logs the underlying error that caused the migration to fail. Check database connectivity and permissions, and review the logged cause. Migration commands are listed in [Install and Run](/indexing/indexer-software/install-and-run/#database-migrations). + +## Grafted subgraphs won't deploy their dependencies + +Confirm auto-graft is enabled and the IPFS endpoint is reachable. See the [Auto-Graft troubleshooting table](/indexing/indexer-software/auto-graft/#troubleshooting). + +## Query fees aren't being collected or redeemed + +If receipts aren't aggregating into RAVs or RAVs aren't redeeming, confirm exactly one `indexer-tap-agent` is running, that it and `indexer-service-rs` share the agent's database, and that `[horizon].enabled = true` with the v2 verifier and SubgraphService addresses set. See the [GraphTally troubleshooting table](/indexing/indexer-software/graphtally/#troubleshooting). + +## Queries are always considered stale + +On fast chains, the default `maxBlockDistance` may be too small. Tune the [Subgraph Freshness](/indexing/indexer-software/subgraph-freshness/) settings for the network. + +## Filtering logs + +The agent tags errors with codes. To isolate a specific error: + +```bash +grep | grep IE004 +``` + +## Getting help + +If a Network Subgraph endpoint appears reachable but is misbehaving, collect the relevant error logs and file an issue at [github.com/graphprotocol/indexer](https://github.com/graphprotocol/indexer), or ask in [The Graph Discord](https://thegraph.com/discord/). diff --git a/nginx.conf b/nginx.conf index 657d1b0e3ac4..e7cc008f9575 100644 --- a/nginx.conf +++ b/nginx.conf @@ -266,13 +266,8 @@ http { rewrite ^/docs/en/substreams/skills/$ $scheme://$http_host/docs/en/substreams/tooling/skills/ permanent; rewrite ^/docs/en/substreams/substreams-mcp/(.*)$ $scheme://$http_host/docs/en/substreams/tooling/substreams-mcp/$1 permanent; rewrite ^/docs/en/resources/migration-guides/migrate-from-alchemy/$ $scheme://$http_host/docs/en/subgraphs/guides/transfer-to-the-graph/ permanent; - # --- round5 reorg --- rewrite ^/docs/en/subgraphs/querying/managing-api-keys/$ $scheme://$http_host/docs/en/subgraphs/providers/subgraph-studio/managing-api-keys/ permanent; - # --- round6 reorg --- rewrite ^/docs/en/subgraphs/developing/creating/unit-testing-framework/$ $scheme://$http_host/docs/en/subgraphs/tooling/unit-testing-framework/ permanent; - rewrite ^/docs/en/indexing/tooling/firehose/$ $scheme://$http_host/docs/en/indexing/firehose/ permanent; - rewrite ^/docs/en/indexing/tooling/graph-node/$ $scheme://$http_host/docs/en/indexing/graph-node/ permanent; - rewrite ^/docs/en/indexing/tooling/graphcast/$ $scheme://$http_host/docs/en/indexing/graphcast/ permanent; # --- round8 migration-guide redirects --- rewrite ^/docs/en/resources/migration-guides/assemblyscript-migration-guide/$ $scheme://$http_host/docs/en/subgraphs/developing/creating/graph-ts/README/ permanent; rewrite ^/docs/en/resources/migration-guides/graphql-validations-migration-guide/$ $scheme://$http_host/docs/en/subgraphs/querying/graphql-api/ permanent; diff --git a/website/src/pages/en/indexing/firehose.mdx b/website/src/pages/en/indexing/tooling/firehose.mdx similarity index 100% rename from website/src/pages/en/indexing/firehose.mdx rename to website/src/pages/en/indexing/tooling/firehose.mdx diff --git a/website/src/pages/en/indexing/graph-node.mdx b/website/src/pages/en/indexing/tooling/graph-node.mdx similarity index 100% rename from website/src/pages/en/indexing/graph-node.mdx rename to website/src/pages/en/indexing/tooling/graph-node.mdx diff --git a/website/src/pages/en/indexing/graphcast.mdx b/website/src/pages/en/indexing/tooling/graphcast.mdx similarity index 100% rename from website/src/pages/en/indexing/graphcast.mdx rename to website/src/pages/en/indexing/tooling/graphcast.mdx From f2ab5dea845a979a70a14a03312714e93df2f36e Mon Sep 17 00:00:00 2001 From: Brandon Kramer Date: Mon, 13 Jul 2026 12:55:07 -0400 Subject: [PATCH 5/7] removed drafts folder, reverted indexer docs to baseline --- _to_delete_claude/link-fix-wt/HEAD | 1 - _to_delete_claude/link-fix-wt/HEAD.lock | 0 _to_delete_claude/link-fix-wt/ORIG_HEAD | 1 - _to_delete_claude/link-fix-wt/commondir | 1 - _to_delete_claude/link-fix-wt/gitdir | 1 - _to_delete_claude/link-fix-wt/index | Bin 46740 -> 0 bytes _to_delete_claude/link-fix-wt/index.lock | 0 _to_delete_claude/link-fix-wt/locked | 1 - _to_delete_claude/link-fix-wt/logs/HEAD | 2 - _to_delete_claude/remove-broken-link | 1 - _to_delete_claude/remove-broken-link.lock | 0 drafts/indexer-software/README.md | 90 ------------ drafts/indexer-software/_meta-titles.json | 5 - drafts/indexer-software/_meta.js | 16 --- .../allocations/_meta-titles.json | 1 - drafts/indexer-software/allocations/_meta.js | 7 - .../allocations/action-queue.mdx | 136 ------------------ .../allocations/direct-commands.mdx | 95 ------------ .../allocations/indexing-rules.mdx | 107 -------------- .../allocations/operation-modes.mdx | 86 ----------- .../indexer-software/allocations/overview.mdx | 59 -------- drafts/indexer-software/auto-graft.mdx | 70 --------- drafts/indexer-software/cost-models.mdx | 54 ------- .../deployment/_meta-titles.json | 1 - drafts/indexer-software/deployment/_meta.js | 5 - .../deployment/mainnet-docker.mdx | 131 ----------------- .../indexer-software/deployment/overview.mdx | 47 ------ .../deployment/testnet-docker.mdx | 51 ------- .../indexer-software/dispute-monitoring.mdx | 44 ------ drafts/indexer-software/graphtally.mdx | 89 ------------ drafts/indexer-software/install-and-run.mdx | 118 --------------- .../indexer-software/managing-provisions.mdx | 113 --------------- drafts/indexer-software/overview.mdx | 79 ---------- .../reference/_meta-titles.json | 1 - drafts/indexer-software/reference/_meta.js | 8 -- .../reference/agent-configuration.mdx | 118 --------------- .../reference/cli-reference.mdx | 99 ------------- .../reference/error-codes.mdx | 99 ------------- .../reference/feature-support-matrix.mdx | 71 --------- .../reference/network-configuration.mdx | 59 -------- .../reference/service-tap-configuration.mdx | 123 ---------------- .../indexer-software/subgraph-freshness.mdx | 37 ----- drafts/indexer-software/troubleshooting.mdx | 44 ------ 43 files changed, 2071 deletions(-) delete mode 100644 _to_delete_claude/link-fix-wt/HEAD delete mode 100644 _to_delete_claude/link-fix-wt/HEAD.lock delete mode 100644 _to_delete_claude/link-fix-wt/ORIG_HEAD delete mode 100644 _to_delete_claude/link-fix-wt/commondir delete mode 100644 _to_delete_claude/link-fix-wt/gitdir delete mode 100644 _to_delete_claude/link-fix-wt/index delete mode 100644 _to_delete_claude/link-fix-wt/index.lock delete mode 100644 _to_delete_claude/link-fix-wt/locked delete mode 100644 _to_delete_claude/link-fix-wt/logs/HEAD delete mode 100644 _to_delete_claude/remove-broken-link delete mode 100644 _to_delete_claude/remove-broken-link.lock delete mode 100644 drafts/indexer-software/README.md delete mode 100644 drafts/indexer-software/_meta-titles.json delete mode 100644 drafts/indexer-software/_meta.js delete mode 100644 drafts/indexer-software/allocations/_meta-titles.json delete mode 100644 drafts/indexer-software/allocations/_meta.js delete mode 100644 drafts/indexer-software/allocations/action-queue.mdx delete mode 100644 drafts/indexer-software/allocations/direct-commands.mdx delete mode 100644 drafts/indexer-software/allocations/indexing-rules.mdx delete mode 100644 drafts/indexer-software/allocations/operation-modes.mdx delete mode 100644 drafts/indexer-software/allocations/overview.mdx delete mode 100644 drafts/indexer-software/auto-graft.mdx delete mode 100644 drafts/indexer-software/cost-models.mdx delete mode 100644 drafts/indexer-software/deployment/_meta-titles.json delete mode 100644 drafts/indexer-software/deployment/_meta.js delete mode 100644 drafts/indexer-software/deployment/mainnet-docker.mdx delete mode 100644 drafts/indexer-software/deployment/overview.mdx delete mode 100644 drafts/indexer-software/deployment/testnet-docker.mdx delete mode 100644 drafts/indexer-software/dispute-monitoring.mdx delete mode 100644 drafts/indexer-software/graphtally.mdx delete mode 100644 drafts/indexer-software/install-and-run.mdx delete mode 100644 drafts/indexer-software/managing-provisions.mdx delete mode 100644 drafts/indexer-software/overview.mdx delete mode 100644 drafts/indexer-software/reference/_meta-titles.json delete mode 100644 drafts/indexer-software/reference/_meta.js delete mode 100644 drafts/indexer-software/reference/agent-configuration.mdx delete mode 100644 drafts/indexer-software/reference/cli-reference.mdx delete mode 100644 drafts/indexer-software/reference/error-codes.mdx delete mode 100644 drafts/indexer-software/reference/feature-support-matrix.mdx delete mode 100644 drafts/indexer-software/reference/network-configuration.mdx delete mode 100644 drafts/indexer-software/reference/service-tap-configuration.mdx delete mode 100644 drafts/indexer-software/subgraph-freshness.mdx delete mode 100644 drafts/indexer-software/troubleshooting.mdx diff --git a/_to_delete_claude/link-fix-wt/HEAD b/_to_delete_claude/link-fix-wt/HEAD deleted file mode 100644 index ff3d214b89e9..000000000000 --- a/_to_delete_claude/link-fix-wt/HEAD +++ /dev/null @@ -1 +0,0 @@ -ref: refs/heads/fix/remove-broken-link diff --git a/_to_delete_claude/link-fix-wt/HEAD.lock b/_to_delete_claude/link-fix-wt/HEAD.lock deleted file mode 100644 index e69de29bb2d1..000000000000 diff --git a/_to_delete_claude/link-fix-wt/ORIG_HEAD b/_to_delete_claude/link-fix-wt/ORIG_HEAD deleted file mode 100644 index ed9885610fcf..000000000000 --- a/_to_delete_claude/link-fix-wt/ORIG_HEAD +++ /dev/null @@ -1 +0,0 @@ -7ac60b27ae9650559dbf483ca7cab0c61175692b diff --git a/_to_delete_claude/link-fix-wt/commondir b/_to_delete_claude/link-fix-wt/commondir deleted file mode 100644 index aab0408ceca6..000000000000 --- a/_to_delete_claude/link-fix-wt/commondir +++ /dev/null @@ -1 +0,0 @@ -../.. diff --git a/_to_delete_claude/link-fix-wt/gitdir b/_to_delete_claude/link-fix-wt/gitdir deleted file mode 100644 index 2938a76bf930..000000000000 --- a/_to_delete_claude/link-fix-wt/gitdir +++ /dev/null @@ -1 +0,0 @@ -/sessions/rcw-01fzjwn1bbaygchutgdu2p81/link-fix-wt/.git diff --git a/_to_delete_claude/link-fix-wt/index b/_to_delete_claude/link-fix-wt/index deleted file mode 100644 index d3647a8d771205f819d3e53ff140a7657035489f..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 46740 zcmch=2|UzY`}qH{?^_FPwx~oy_LNGN(n47(Eoh9vSZ0{TRw3GmMA9auv`dRhn~IQ> zQc+T*Xy5l;|MS^q=9rnf@B91vKfPYh>r%JpdY|jM&biKhKCY9!T@VD3Mi8kr;a(fP zW#1>YlM<1VK@eH3N(5O_41Vyy|A*}VsTf`>rTsEJdDMy-6-oK6`OK%g5jFE*7A=C# zW`r_XY&uYhAfz5r68frOeKNbPulph;ZA*%VeJ^pHSp0JKk#gV7h^jfA6Ukt5*);QT z4yI0$z8awKm7si5OD1#8KQBBqs_*(r%iyj@u5|{XKc*l<%tIO6FkX-ahsI_^b2%0f zydXM_8%c?yGPo2rof@2A&I$Wdxocq#axeRAlg=QORZHUE4lQk8fB)LpC6BivgGD(U zE-Q+WNT*Pvqa*nc$^NN>{e!HSdvbgD%DEOMH`=uWjD0hQP*+x^i`v7Cj>m0bF)e5; zW(XscbR6k_QW9~v)We<{%8jRsf?95xmn+5>^GuCOWLug}iP|H~Ve^=z((rSWNST zs7N$Gs2y@rm3pKk?70GSlqX(ce)rmTXN~#!54kHni+o&CCp~UQOeAu6k&&Pt#PH}G zE>0r#lak;xz#N79f5;p&~?Il*5XqGeg}L+E$>^E%RO*^ZN@H> zjYxm_YlZ^}#=#AjvEt`s0PE)&q8{8dYfpkqWbT^ z`lVUL_cwjob*ms|Q*z>sq`tR}D5ts%34aUe2W^K<=WzI5k*L2F){kuZkTzlBbtNm` z?s@YLHX9mp8?}x4g8bH_{F0(7k#nzy|HF5ewdYJ)9kB89$>j6D<(md%nH?U9^uahp z;}>#18COyNw87<<&M>=d@a6FS<7ZoctT(&o7pD5nd&&Z$o|AeZ=aBIvB@x$lSTDkw zd}+MGi7dy~Y2U2m`W{S*dHOVO2N73NuUMyGdM#F9;{`b&3H|qb=(h;9KIx$o(mgls zYNkcg+ww3)oBHL5yg4&EicLcs45nvXJ)X~jB=mIj&?95kylroW-4(?Hdsd}*jOm#4 zc;CDXR8Oq19)C}~9s^0}dC)^o{nDB>^K#DF#rRyE9xMOm$C#M*8(c)gJep1Cav4G+ z7_3~P`X0jiq`oWrDD0CD9u~m$nAd;M-1p(B3dSv9JjA9)QP~k-{1QbBU?k}4g7qP) zPYRD%${D(=6>RZI`Iffmy!PG=n~=WdTsoUg4PmjPEPA9$33?yFdZlkvR9rj9o|3b$ zHP1Jlt+#aak$}PgP%i~~z1=3bdbpWK1*1_R;v#DQV^}Xz^<`k#lWmmfKGW*M1DCeg zjX%8Yrxc`@7>;m5{;2m!54{`X9lwOSbVV>TY%SMa(R-2ldlk(Y=_OR&C@O<#PHL4{ z-e*1Zu2JG#N%FQgh)T|rzSw0xUghfYvY*I6VZC6)5lJUUQG9>|KR<`{OD_sGed(J? zU*g_eqZ_KM+P(Q4!?p;F*93l!!u1pRokFG2SUe_|Lz*Ii^8)4|X2|tS z4#EXm6k|5}q%p&KX`mFlPK|zu@(TX$PKiNA7Vk9djJf zaGCDu>pj_drtf6WNqCjR$|tJtHLOosFXid%I`cf=Q>U(UQL5+LPIr8DZXlxUicLR4 z7?JqogRH-z`rg3$Ovcli2MxYh;yC)jYp0?)H|vMa*wVNSQJ*&1#m&>ljWS`z1Q&NV z)Mg3gdkgE6ol#cCx{!GH)1(DKaT7XwH?s|&^|nD&NPQlYeF+Cj(Dx43C$l8L_g1Z< zQ)*)O4_oAGC9`=!S?C-@Nzhm&=y?z8QD1B0YL+wI#p%dhH)o{{3u2Wj&d5|E{i%_m ztVjlxLSs|oBI#^%!Q27UyYMESmw_bW`vKOwGF2`6&~{#tlev8V<`=hZPADy3Z|a9A zGr=e~9@9pci~CPh-$z)Ve6Ve6nRoF424(W$VMAJ`_w%*L8u1ZPji%BfsG)Q)sbMj3 zjad2W^a4mplWhDIt9d<3vwv1Dw-M`3vUvG_OIo)OaT? z^F|;4dZTIYy2^b>!vBxuj{`G#7LQAb3j@;-4gk?P!Uf05{cS2vsy z@(a;&qmn4^FSxv4=A3nkS!vbrVBpzTiFtbZi!S^5z25l0C~r7bOnHL`>S5&tk|=LC zT;AF!c?Tog-oZyl~i%Pt_y+BqG>Q@!Mr|euYJpQZqK(%_FXPXLA>WnFSm5#2gnurYh6E7Cce_ZomoJIPd zltdh4VUBdZ>9v)WL-!u=yOr3Sr@n^9RoAk7jOdASh=1YtxTIcE68hy~{ZeK6SAO*8 z9?|_$G{CQ_!`D=y?v3FmWT>cqawV3=icSDamz*fVWu$&m5*!7Xg9NXqWsgnIeLT-! zm;T7@w#M0zVN7R4Ukr!NMZxqy+1it)^YGyC`3=Mf2hOknpxcDW^QQWi3Gr z#pq|#EclV<#7l~|GOSNa*o@_Kymz zA946Aq|os@+CRbl-Kb;CDK8$Ya| z?-$>pibLl;|KQ`_>6R#|{5&or63j!eCPC^YC81vp)-S#Iz5J%;p^YoDy>nQeqN3|8+YjaOB%YVxd=YO;nlf!P*Lu9#0Nt9o! zhyG{!*D9w!f6idqmX4mr*i%)tVD`pu;`|fG215^YXb<)w&?QPtuitpA|5gN&(BB)@ zFC8++B?0H)+7SIfu(;(6|(OBpqF7jU$ojO<2SpG-^N7OyoY_uUjF!=lR?au$g7Kjaa=#!ptHoy8e=KMEvaXJ3e` zc--#zm{b$nO*MUIyO~gaEt|cu+`ZifQI7`eQ0m$NM=T34Pj-J_H#u zTP7@JS?CS@aK)R^dVbs5KliPtBfT+w=;j7CVC5?%%PFc?2i7a)blWLr+A7nvt4<#* zXgR<(KT`48CJ^W)maWJdM6NawaTe9v57sNaepZnAVDs^b3IpAlFSB0mv{UVEu^dtB z*{US!>ksRbN?+8LBb%*e*gdr1XL-W-CF4VXWoaYITpl}!B^(~S9*UN4Agm9`*#3LZ z6XviZ>`|sNc^NfjN)OZJ?GaUC7sA4v&Wr_4l;-d*aD<7CO z9=qR91?fxbW76Y6HD<<=y{bgJb$jTI9{uC%m9S|))1_wC+Lg$a)b2?SXh-xRz39G4 z6qqCu2@8*vgnFe1>(>bNf3Ri7sO$DCx4ib|I(l?p<@kTjM6`wVlX~$5M+tiMVZBOP zQ{QOKuxsJXt(V`uI^lWKY#X2TYmq*rUeSgnL9YR<7YR7=Y5()#2VT{i4lRg#xpm$5 zt1~m7AOrY%SsX46tm8wj5XA9@7oMMhB-)t~q+cq(_I=In-M@H_I`xfj@8&=JanwO8 zArl$Q*Ut-zWPpw{D%8R6pxTlJ7X?pBhVr-KAu_|d?NzA49V&gs` zIG8fY+n3@=kE6^$*Qf+>7sD}yII<4;-qsBXU*9b((KXnXY*u-*sO4A4Z^TrLpC&{z zC=v7o4h4*y>2xN#GS#y_tGuYi;(|)TE;ERy^>XK%>dNMW<5p~aOWS&ZG4}iUsVxS1 zV(Xd9w8<2=cxqHM7&!};wXk-hy8QvhK_$T%0de}x&pCLa$-MH2%YWAVu3L*NyYmWwd%|57#B!_YXNa})JAT)QAatjujKJH z$I4Ix`(xiiM{k}hwtl#R(O0NAPhx2mi2XwcFl8dxp5jGP1@TiK*M`}LN`hwz@l-2*cDQ*m-|x^r zxP_&+YfO~#8B63voY;0I#1oDn>OXZ)1I#W|5*#atBQ4dQdttGsQg!eR8 zA+s~cPzgNIZUc*#dYu(+7mx(U2I8pJ9H?>Fzi{;Gv6e|vecMc24;iMK9g9ZBi{mh8 zEYQM0Ru82IqKl}3Q3*K^$Z^W$p7<`cJQ7A=e-96Ek~uX!jDvlEpB#}4AC(`GEZ z6)M|2Yr%r9SqmcE%X&2_Aa&0X3o&-O#e)MMY_O{B1J=C3((6nn2m67DA!gUBG@J({ z!Lx^W@^=m%PTKI=xiX#WJ6%`j=gE52txDeO5hF3Y$>`)9;AT*n!if^)Xg%1CaZpKc zMnRn3HyiFfUE_E5+_+&bbH>lJEpxql{O0pvV*6u~)5C)(r`NPtEKaB-I1Ug;*<-JF zbMVO*eUcX4cPoGS%=T?{E@EtnjF4mxx*On12ipUYoF0Z@ygjl3q$GHwA)fTF!6VK* zxqeGk&MWJg&Z&1_O16Ds_f8R;w=la<9+5>{cq08;@BQJ0C=ZncZw$m!`PiyrFFo#R zm~Z;IMA@D6uMY#0&nOp&?Qf=8QMg1-2BSh&q@^HV^=X)i*@a4i;|Ot7J>pE;?|#&8 zFCS1o{H)`iqRAg`7X>~*Mv3ubkJLYr0V*Te*G)#ZoCI9$5tH>$`%p=6$3k4?mkWo) zv?(#4ug%ytuc<_8;i#2kgDW${wsVh!z+ir}X469%U=RmdJ)0E{PCN#NiEHQm&oyFv zR1*Ag5WgSWXI;yLBOhl5`0sT_mY=%w#5cS?+FNWr^`vvriEhu9j@mcCF9eGtDhbYb zh$9#DUhUhBbG$d-*Cb^2=h;sm6I{Kjs$Fb-9g1#SxVR#|h%- z#SIEtyV>dIV^`-TeTwaW&d!|u`+mZC37j~JGb0kLbc6~w1=JqBBU9Q*NpL1W9Qkp| zrSs3X%{o6nyzJdO`Iu{08|)+78DiVP3|3?UdS(PnR=|=|Gz+Y(5GL{Sq`vL|%zvmP zc+L<{#&-APKC)7!@9P>~I-DDs->(1ADfrhXvF%)l7ad7W2xWs~2*Cm(YL|ZX2h5MC zBzP_mPwv_2XfLYb%wvm9mfkMdm)3e?SZj_Jiw|kfru@9Hzee-gDgUl_XF6}b6wKqJ1@lTT9-W;qkxu4(3Hm2O`VqhK3Hy(R z_8m}BcG=7R-AUhRKYV;x-^I2gpD-$$j*h8#QRJ8ktq3T`_>m3fFH{nCOoBM-wB09S zpT=*f*!dx?dP$x8;9>K^p0_)R^_LGZUnTRsP&*nTa}tX`DhZA|#6jlX+)-J`3JjM1 zUUS{@f?3Aru_M@Lo5kBha(p6rLIWz)p5coI>yeV+Ooli{`ZA+GRL)=HFeCraF#qu_ z^mVnok8KkWOEGzuw1)#`FT_Y-8rbs&RROaM<(RcE!g#18cvB#ru5<4Jjm4L4=X}*H z=%-m+p`mLUmv-768U9BeG=V`mBTO%1{zE0fnF?{_#%!zdo^ycRlgg%rF=B=KjS&wX;`)Ik^iPBI>vVK)Kie|A&EDQ=i_{72kali!`gkdC zvGb$Z)W}GXdx&12p9oMpDCU$xQW6{wh@-gq?RA=F-tpSn&TRKl%eOwAoG{bBqQ6)> zs9+w89k9R=nBHkeuy{~_B=mbi`eoHk%k!sQk8!zP@VeMi`{0I&_Xk{mVvE>_i3h45 z%#$g!NCsGorf?X+bg)7V25D@v3h?tOW!^{3f2bt5(;=?(K8Ga}>lkbAwti8h9%rtd zcxwMQ=QZ2^$VCr!f#Kl48EkO0!i5C1#x8G?Tf!?Rausj{&K;@J{8K)GV_%&UU=L6tNN) zM;@2u7Eh<~xO8$3jgRQ3S@A0;kq;>!GjJ}D1lI@R%5Aw8vh&v{^@@+aU%vieMNMW$ zo!7lQNbGn%i0JFlYY0Lh)Gl+G2F#zRBskzWmvH|vx+dXu_G(+h{Q0kD`j2X!liBX| zaG{^rd`L_!DKs9aF9MJR&P<4d^q;=w!^;7AvmL{AY)vh4(k&wCv)ZWTIM!c&snl!=UoH`>`0)C zIQW7qxb?yykeFSfyx9;Bakt-bJM34q?#h&cHVr?wEhC?$mY8S$iAOZIV9*9wOePrO z3iD?43&6NQ688B)JUQCe=Vn&C&aJJx{MBpTUa~j%l^i>H45BNhK7xEg;gQzh{jfQ+ z0QVn|g#I~@e(Bs*dt3EY{fi=&?b**}()7K`2Y+&TE_Qwl^fT!caLkv*7DS2QEWVG| zJ0JAB`2%2PK z{;D^{{RSk#n+NffIU5t6EtJWt>$|~BDrb#TUpuWDr}xEw;7O_$*m%Z5n^%Z(QAzOT z!@QP>H+OwjvETChjfKPB=XB{=I;9yV)?&xe#A-5`GkjUoMDm3go;h}yyVQEJClZ@+>x`oFgsC6a2G&ay|ma|`xV#socAn> z8aXvkRwX$5rejlIgd&cMt_Ra8tT-lrD}}-(XLope5W}NFJmhTQB;}-)6MQefQq4O$ zaq;QX8$9jTb%@RPApde$Y>|eC*|qi+ZWoY*T|p2>!DAU>etg|nvkS*}Zn_!x^qv1* z&Sy=%oPv-ig% zlFP-8L%`@cvk_oIY^Nfy2vxJUg{o>^d-? zM@JV*p?qw)QVX{WNP+_{s|s;sMy76{SPzcM?Qd=+qY!aSo+6j0Tip0(|6!+!z$F2^ zR$z7lNYN-AF;B~-P~*a&pq)`U&PKU`SvjJ1tFsHVVov^ zJyH^!aEK$lfEL&5(a~4YQ}#Hf-Hu7Ia*2LyZ{hvtIEh=uAma4?0d5zN1TO;ODYTEt zIcey1_~Ve{U&=yOyoFI7!Z5g^D_DI*CE-VKl1-?7NcW|kKj;)XNoB3#0QZ~^u20u}S3N#D zSL}ESJ3K)NrgEv!3=H*~7!DWWAQoEtTaSjh{JhfJaHy|e_`S3S&jl zDM6v;oLF?b3%A2qy%6I7N!Y=I^hhy1a@l#t>qjJoxj3La!5(=z-cBSze$}e3C#_7@}^?Z+C86lmSlHv?vzYtdW+2$ zXd?m@j}`&1Wh~Cs*^pBT^Tp5!teCGPpY@%-4e6K?*C#- zyqqw!`HBp7$$An!2lpqC1TPWdDS4b2*!#xCQRc=w$E&=Xp{QgXW_bUqCSoh59uhns z!m1wIMx=Z3`k7pS+X*DWT?lbySFF>kJZM|5JMq8}YrACcvtg>=k6s=jwtj-Q4%i8l zARd>?0wZmaGbNZmzm?)VAPL?gh^Jh9TsvfpebrpEw0G~6WKMWx?zpJ)d8*ic8t0M0 z1FZqtF2(H=JIQV*n_-8JlWyr6YNuZ{pRl;p3|-VLeX~cE)I`gVtD{D6ca~m))L8xV&E$fsQ+y2$}#_; zlF*+F=|@iF{QBlzx#w_8-+(yzYqeae^@i_X>c!6g_*;3zcuGt=uyOkqfN_B&cqtH1 zD!W%ZW3smsV^}ur%t_;W3x9n`dbjnP*nX4GBSVIt48Ziy98*Y2g0lqTNLzf#tGiZO zd1>4Jwyo!j4j-j)M_s+MMr^((PY(yPup7PPNefJWnlx??kOU_c;>e#J{=mL;!~1rZ zXP572xm{>>n-no*W1-mkz(%i#aw*YZ%a=b-;kPb4|J&rc;&uT^@RmY6sX*&T?u@Yt zyauEFSzmi!xR<%FzA$!;*nSz?m$V=zDFP5?mna8J8in#c^14uAw(k3qNX3LVOOB3G zSuitQUY)HfHXq|0{v?GYVVt7n?W82^Sq^ce+<#XjzE~F&cUkwRmi%EA+UuW3W>#PP zBPW&~3EmjtuThcuNl9>4Kpf=z`qO2Pf9xrVzZ6)y`RMGafoJVAr|$cM--yWxX$=vd zYaV!ffFw98A&znd()7Mt8gXn)F-h*dZj|$Yn~n2j$B3Pe3sTe&I+4K!w}!}OhUHz`&@MgHUQ`m?RWMh=y1lsmOcK|J4p!#)!ylYm{0ip+ zNpQ0uuHt|t3d(-Skb$39j4+tJ?L~;$nS`{7bH$ENIdqmq5SDh|MGTX(CDpn-xVN=N1BYVs_bS zoM}h>iAsW(4e?Y~+K*_xI{)hEq*ISpFV9OK-MxF*aZPYfN=(1P;ZoULay64*J#mit zgaC{KB*9q&aipu;RF#nH^LpR%S@=`^;Kx%Q9=Ero%@=PMmlw=nQOMyBc&30F+0(AE zX@wXMNP?FG@no~|-R?gdY!f@b<#U4Rpvi;RzrdpiLNiX3XFr&Z z@lZ+d)>(KYdkr>SS3SPvaFa)(9Z}0X_ z&)P9QkOVgm;>xPZ4Vk;u{E=Z-uZhn(#+*&bI=nOWfved5n$L}7gwSaTG@*St`~4@e zxS^8Ztb;gedC%8pIOm-im>YC)wEiT8#QI8PfzoEN>qi0(=um^fGA&+7Fgxy~;C=*> z;N(Lb1;fac8p9zI_q%<48)tvHB&Mq$<6`6?vExM{PAErs#~4eOSp6S0iZ=3@76`8;3}SQQInMDvIL6yl5+nWr5_arIDp zQAuz&KwLvbslAJHxz)zIUIk61-m=fqNxGmhVB^2$3iS{eZ|OPAzYahW+>H=dZDFM9 z=o0CTepatj?d~kQvU@!8aP7xFh_kr7LY~JEV=ps=OTo_~fkid&2o=A#!0W9;WgT7) zAc=Bpg36(|CMPAxeomVU;^S!AeLAb%M8ClPDMReImhX2Co`CQMgKpttSsb&wV_G{Y z3EpOir&9T|R+IX%GyiRI(7p@u>xMsH?zqIZRD3=aEXxS5n4tPckJy046_o_10OBZx z)eZ0KAa{3sLBHWkH$?l?UDe>Mqy~xIzs7E8pc|l+7#>&zz|uIFpMyP0wovzk)nhT- zEf5!}__=ESXdl}8`qZr58}bd86(7$m-)$ees=G z+(rXQ*jET~dXI>0UOAG!{zUDB`_n)7Z5Ztxp;)?9MQpt#4^fhv@?;m)R;=Y;PWr9lYJkR{xM9SNBcB8g;S#Jjv~`v4?SL%nM0LaJE4lskG4^ zdtD|xvprn!+WE;1t-Z_T(*}(^E!L0VG#tM04^~yMNwOf%jqWVN>j{tqrwHOGZShTt zT)R`l`m4(C)ehBbPb%#(%Q&9O;663x9gvSd=!oD34 z4|(1F;r!6wp31o{P&f|vBC!wzrx`Evr^wE)E5-5RJ4D)L0 zc06{!^y9r+t45MvgPX(V)In3beEwixTo{!*nd3^_i2!H6$PppR8)MOp*@sHPzMT+H zspON!2vgTngEz}mtzs{VU0hzby3Oq~GEPh$MV}A_r}TV?bn45Rfu0fMgh^P)k-*;t z@sT6OW!#D!l6=JqW%Pbs&tJ1w}U2M&dTy;yYh8oxmw57t}pKbU^c)OJ!5e%uS| zSFWD#%>4d&zAV>xgo(%4&f0~H$K08Myo`^?I2Ivvuvm&EOEw)`mZ392rz5y8K1P(Y z59Y{^+qz-;3HfT*GNY{~?Yrh|>L*>&R3n&Q!W?jUnFY)OJC@|Fbi7{^!`TmW2G&2h z_x@Df>n`SMQ$xD{lPQhm8m*~f>|w-XV@$Ah4$e%`!1dR^*i!;?`dis6oK}DGK+CN^ zZI8-@z=Q60lk?9C&ZUs{M1dcI-SS8^jtQ; zrQcFf{lt}33XK6S?_z-`<4sB;?gwH0HkZe~QdvBFV2owJCfe-u@kiv_&Ur^8{mAx% zzG~nO7T{-~J3n0TY=We6AAJJ(#Dw@T_?$5h`vzVae z2}&=q{6}Gqs@ZqdDT6<{og6;y#hduIon19Ix?lYeoL?5TV!IVMscBcI;%w?A=UW@GrEbq-sX z+TENqLLvt||K@}5#{P{{4s(>8GrXJX^IMgFZcY9cKJRF*)SlF& zgYDX(ArkHI#k!+E*>M`yFa5pBO>emCiE9Z{-@Wi_W>OP754qnGj01bv;me4kPX^0M zd@Cfz;|$D^J+*ym#)$VXU*3J*TWWQhip7C(HB$X0`fCc(E^b-740du4j zBixU!QLsv?RVOq?jF_86%yMcw(1EGlJnJBSih`qR9W@=w^Iify>8p^U2XQc zmMN7{6OsPH`3m?4jG1ZZ6O+XIG-&=K%TMINbFg0N0+UYJbK|)+2HmubU8T3H7fUHq z@4WfmXbJT@Ab)_% zC?NM)Ov421Z&CeKuzs14=oyH=-LJ~7(}&)gDDQvLZpP3F6ztca^@q^!;p*oCJOlEr zz%QcuFTnbx^Ts|bT=hvkA-H~)#f-hC=IziF$Gcr(&exbU8hJe&dNU@?*QZ#N$$={za1uG5tUi`s-l*N>{Xdr;RZ#H9G4ucgp9V zo4Y-(J~>=2m=_57AH0Qu`G*6Z=nkRsBDoe+^vpaNaFRnxf_Dk#4P4jauu%5f>v+cz zFVyD#NYZUR)wV58unzb~9@;R-@Zr@!_iOAz-e6h5 zJmil&C}N~tq$KRS4D*y4wW@!w)C#XGTfnkEmUMK&x$RC*ivJ-Ge<2qgTuF{!1I$x? z?9pZOdj4ToE8Q@qbgUPV~CzimI zV>6lHajIx+tkYv2CfW|0V4j>qdDC%|@73C0$KNSxR!Tm!*s|)R(0Nf29=e)IjH+=K zSszJB)XQd=qjEIs%I52NQt4;Et-cu_d~s;U>6(Y<1?&D|IrvH#cnrZCn`eT-slYru z&#YS2j&Xq`xVK^Mux$&Z)^L_R{G!)-{?VAU1$kle<%@T~d72CtR6S7rK8VIdv>(PK zp}z&vukAOyF7&(n6$6F4&UXtr@inX8&dxEBf%{2PKejLh+Bg1u6Q);hCE5@8AV3oO z??U-lo3jMxL{Yz?2bMS%^T70g8cFxJm}hQoZZp!x zA3O(*W-L-aDGAO!m?KLIsB0an5Xrf-$jK{o9=E^J@ln^7!}Ek59Nb+vL^7ux=Ex<~ zcHQp$amRSaym`fW6RQS{$$sutDL6MT#vTqYI-12sSN4bl8^BgZFlnA7`|iVBtr4|q z@1Aqt#lD!cvhP6b02NL>L25~ zb6SI(Tqiu9!TlEqR!ex;XEbmK85dF#@p%aA@54^HFjaT6p2pg_mrI(?U)3CH>X=z8 zIFBbNKb>ho4MOL<$^&LfzEn68r=ImJb8ozbaNySlrzR-_uOIAA7N&xP&4?`Z~G z1V(|AwD_~jU`rZ*x|+0yl!V_N_u#Sa?Xbw`7qKAra`~Fe=`%Bb&M}^NQfQrt-+oZL zARe($L+U3b!Fk$)!(ghNbRF(MeWp(emteu%gn?v z{_U(!?9nG?46Lm-+Rztq5+2w5fg9Q5%?OU50GPdF)$~Y7*!=?LJH=G6m0z&0GVglH zEnVQxUYJCotqvFL%ZaZ)q`4NN{7@b`R_51YB43J@<0V{>h11i|oZ9^5;Z-Vv?^P(8w@7Q4tsIE(}^CQgF@Hsy8ZCI53n(Yf{@ve#54^xyi zrrSu!YcRJ*7a@W73FZyF>9k)@?Zj>)hcISix#_@Zq0iT(4}!;ug1Dg@VPFRi_ba+n zg`R<7g3*vrgO13w`*x#6`b3|PK4g8Cbe1!WU(fECZ z^&>{kAKUw7H_a-&ZEI4tYPC`L@Pxy^CHN8350*zI_j{teZ#{Tj{XJs)?X_*LJu$#A3iiG+R+<_Y(EqMYwAr`Jep>SmehG|FSWEAxyDrYOinull_maTMDh@Hrq# z3?}jAGrVf{s4Qf=2)~JsTYx0m;SZRv?Yb}4=kvqLaeJ%Zc9{E}DcE*>LurPDevr=x z4?m(c1ulbdKPbxm33K-ij~@17UErL(Hw=G!FPfEf;d7AelFNegH&FZMb49Hr`WsQ+ zFPNupvF<{RX};h3(v;;{%ofwSL+2guX-epK`8<)KGxljdaL)yMT^KhQYagQgZkX>Z z_1nqxGDEl5LPO7zac@nQ4^dKOUxU|q`R$U==YmIC$u0upBx>XRJCJxhdxJ;|pVvj) zRVwCre7Je=#IdnqU&1QQ_S0hMo$&gF7!Ej#%x^Ek^;eW91@q+C8XE1V4>krgZquJq zJMZb#lf7QiWCiC?#K#eR?h56RSBCgTlJ!=UD-ClOd@$Vk=3`;7!qDwe)H|bf!lt~e zzdKZLKIG3_Jkc`2rjURv!M`#vS7FNagn-SD;$j2Njo!{ovZ;ylUGP*zLVgv*k+2uz z(!gt`0xUkh5Vcnh<|5NRt=C((=kxyaeV(s2bu0G^2`mTi+wtE+gzN<;*;za`cxqH! z0+e8a}a^V94o=EDlpgiTj_xzeSUjw-2PA|vu#kWQgux6u`h_X*nUOeR}n6HRV*qf zG6CP`2d_1V9SebGi`U}~oA7ZTkVL#y;c{7AeDNy(zNU2CE{2><)SY%!*K^%U*2wIC zTQ006#YBQ=dE&}l#aOn z+j8L!qT{EssgblWdK6JUNVCKdeGs>h69TJ#^^N%HmWPP z@ZKZM$|co}!>$ODt_^RDW(OX9vvrKY*vE!<&pfgC zd#Hfy6m@q@br_=Pmksp!lAc7?Odjy!K;xE+H&0dS zC8yjdj}dy`4yso@ctZW8C}$wdLAHNCG+W<8HPq2idit`#)>7vThMd=z5I+GY2z(I( ze7hQKx`Vs2!o3KQuSL0oU~WG0z!E!neVU&y%JuQ_ERaO~(S`ZyTa)iA4oMqkePp0{{gcWO`<&bMHateg{yRSU z=2|R07`-Y3*C$cF9?Uo1bvjW0?%jSNmNL?jMJEjgZhbPuX5_!MAM{os=o^q=uFVZ$ z#Q({DeVDJ)W^OiY*X1L}t}U6Lb^h|0BN0ubySFCZG}RPLyX1^N<*+y#tkA z#nD>*JZ4VWC)Mb4=E|{^$e6#xJ(!N&ibQ)VaclnkahfQ92+WsK@j9UQ;M2D#!(LL8 zMrQonSkrv!+$IV0I)S}C`NUlE58Poe7a2yCFR{w1v>86X<%{p@lsnp%hP)`m^`F~~ zJx}!q2S})ICU7~VY=7(?XYV{M>g$6E-MTw+cmK%Vd`_#ZBZz!4a~mWt1dfF$zX zaF|b()v&JV^YyY<)gI>Wqx%OskLi`pJ|TE#SwcG#@;{$X4UVOPW6Z%sC6vH7h50%U z8j zKIWyz&UEgvAFH&}-Xm`Rp*+~sfr3u{!80PU{H7_P92B@5y?(a8uYRV)wt2B(hy$NyozxV}Q;o{d;q95scgpa?0B=U$ATn-rv`qR#) zJv){KhE1P%{DQ&r$Z>7bEB|lt0q4V`z|~doa3fEsBgNt)S{`e-Jbjy9pD=C6+)&?f zOha3?aOJ+~VUw=DLMHwPzku^Q;DT8s1>ERC-`FKxBcU8Na5-#?hIn_Z&MNFmU-8@I z+{3m$$%o?FXGxfk{ka{-pbvY1c|H{{fdsxS%vb8yPua#M`ta4S7qcps46SfA{~GIE z_@Cl}UFZWDl>$zyg12zUM`_5FF$v|dgUds$j{4fR;TB6iF;#W%i-XrJ4qV;e8Tg;_ z8d(Bxagzyd0F#TISUEnL;NyKDiTY{}m*ey~z4MMUXI|_ZP(4e=)zR*|e&25^{#!l) zLrn0wEx<>86T$|s_n@BxAgc-9jz!Dk0G9{xxSVvWa@CcFL(%K^#_Uwr&C;xz?flnq zr%*qPUnAuYNcaN*3H}%j^9?S{PtiV{nNzm!dY(eRT+J9i%An&jk;(tOy$JZ=n>bts z_=*z$91!LU3FR0Amt(+*7a>DGUdl|roT-2An)-(bPn{Uu?tfEX1?Avj55DrN34Y!7 zZ*g&i%QLvD%WJ}LHzUW0f=~75^-OGHN_DTj_&4J-B1GW%D4|6S(D6y|$5@yz7iMlb z?p3<+vM;=y9b?0GD(v3#RQ4t^`k%)Id{%+Y3Ic**?nFdy+sHtKxw^XF*0 zUT3eU{@7P1J?2zw*}t(Lv`#8G14&F2_|;O9{Z24nuK5u2V`kb;={Ys*i7^-7KcCR< z@HPyY^3Uz(^U>8Utc?o24@xF4$^MwoqdZfsmQR!mkWXB7|E@>k;;E5_itMzce=}a? zmxsL9i$2pX{AMXpCbWJ?^(rYOC6UKm;PN0=>u3(OM+-Z0&pRC0YdJXo(0AcxuT};hnD>1Dzww6irZ?)@wZ7(^EXEe8?683xe2n+suDuRkga!5(=Cc!*)ySlmwN0!Ca?w6+5 zZVhmqxZGrW%B;W6n?tA!HiZY?PK*W{qcq`dCagV*sc(~Eu9S2A-SEK9+zIkU(>8s( zG)E`3am~*=683!sc48-5MArqy@TS1Lq4#Go?fnCmXasJo_gni_}E(*wb zkqL?5;e#G=HGGYYqosf(_|ss%(V(p}OBHISmQ@yv8gx-@+8)EZ4bL`8IDaByFP+JY zA}73&i;-kYNi?vH+~GRzi{?Pen88|D}Sv=guUc?qmY?+Jrd=5!d#2r zMQ5xi32iM}I%}@H53Gqf+TFcM;h)wcCOB96B|!oM8wH3;xc9P~{M>`R#F*LuT=0Fzu&5_~V1KTv1L(Q`=E{pF8K%HAFJUmCAy zRB^^k!hV#9-Q+)jPi=s!y5MfK&=`W`l9J$i!+h{s;op>Z0kh|!w z>&T@4Nj^A50$$?8z$A~91lJelD!$&f+BC7{(tLA^9SH-Mno$l>NTN5wwpl zTFgq0?Qq^XXIJ^r!S#Rdr(iBNIL0`Zme~AN3P^%C7v|ZGd#5t{#YE#TRSRUUvF-*Q zxa~c6%dNl83-~;EqePI^h`c7sp9k}GelN3T%b&aX!<*@@|NfU1+cu&5bLd~|7oQJ4 zU&3WGz&kVGx(Fu$e6bJiw?z5#VZQDH2TJSF5B=1JWU5^csrLHS*KkUM+dt=Hui1fb z2!TanFc88Hb_myRQGNi-pS{XtOs^*9$JEswhQ*1?f;~RWx)wwIYy0Ngk1zV+pKO8` zL?y&O5auKLuV+r3a)ISMdzCN4B4o_WP4QQbCj51MOFUofLa2mtEa*{=`D3F$cV9ZX z)|Ev`c%jof(XE_n#QE#|;}7K^XNVH`RG6=3yiqCh_QG{mr!x{SmdBUUSYfYYPW*Kp zRy-fOSHcCK)Inb_i3$djLhwgIIfCGF$g&@Q8G6~po2C2KdtBCgt@x6h&ZF*sUB3}u zj!5*QXMf?-V7~bpHtnv-Tb%`T&BTW9g>^F16#ZY1{cFC3`Cx@nu=b1D?ZgQnC6R}K zSA@^IC|2CnG&|aKZ+XM`aD`Esbw{p@rp-Dd;hYUQoZwjSxuUBRB#)E?mkx8)YkEhX z)B8NTrpmkA<*>HXoZ6yYSv&uEy(4Gg{IL~31(IA+68sRDuRQIQnnK0|o@(N^3%5^n zd8=3(J0Pil9XIpsj!xi)iLS>;iTXPf=Bm3?XN)v78vR!3)zH>aW?B1Vr%pWk^RMft zd@dORupN)S+mA1nq1`O{SR*#VAnhh4VSgB0jzK0-diM&IhIx+Z`}>oBv{T7c(@8Hj z{B`_}y$lDQ2tpsg6duor+RcD@YTZ+PXZ79DVNmsXqiyoo=FjrJpYE)baF2&Hl4HS% z02|}@fSI(1l!RRoFbA2z@?Pla)3tqJ{KTe$NmmQT%$#)P{$J+_B#{zDi^lhr$TWuM z4^jIfVXpSC-;Vn{$0aY7vV7A)TXM`h!*_<3$6wFgKwSKTWPkB%6wFmkeUajN?paQd z>ssr3$G$JL+Z$KH)DgVfE@A(-2N%3=Mq(w|%Y?Zq?}KvcKOTyBu+y+um9wPjgWU29 znxFrrz1RnaNH7^!QWEiH!Cbi;%y1i*EWi6}D_*{DJFqdgb(1SNCoBFQ1ZgFxN905R zjjw3V;`bAxagK)h^2@U#S4@4`>s8_H=ID-#tGY5<=j43-Yu?~Rg8>8BNXAZjL(2-d zzXQJD^H3lOyV)=ondGZ`xud=NrKfVQ$9)uqcPugX6f;{MpY%1y*WvxDCA{ zyp(^o! zSJ78eE|)suU&6C$nX@-hZVvr6Z`*#!c~Xqu!R`$BL=1m{OhUa%gt>^5`h@VJo96EPD#&RHh9mu&5Zf9H;Wc+OM8{aW$$j)VIF zo9m+oH^I?%K{O=#V=-I~#ZfBPpBrBK-1WZey+P3)^YoRE^>vR)J_k$sLo|m-fYAIqPjq%?1y8RxT4IdE7zr1X~NFjS_gtFi%DP(g)2GlZpmbXl>UX zo1ppR+(ZL9NAh|s$rByuNZ_TwJk`=O*Vuh||D@->#=H4th$>;w_p3p!C z?To-53A|L8hZxFS`{lpZj(HciZVfqP zQzJE0;yz8!7cI!jBiX;pU>@?l(s5A0nv)gA9h@z;Rw#p17kqOY?MH)F|n*LbK`<1d*eXy&B0b#2m>tT6R)fi`ASrO zHmo0M`I3{3j5!mnvr6ZS)1kBMu!ip8Z;`&_c>pf@Rb*5#|0M!nZ#S?0v&Bj-3fsZzRH_N?Xv|1C~u zuy5NT)&?V$O&!cb*vh`G?Zuj*+B*zasvA6P2UA(}a0B+=50_lrJoBXIv&f-N^Ssn; zzHAB~&H*3wBFztmsIDTn4(kKK|Fm6{{NQBYfYHjEmJ>vdoEq}s;qhCjsT^$W6bDy3i>89 zg~ddy0Hbl)z>jr%_HDlQYp=$k?7P-$UCmdZCz8;w%W)7}@EbD4lcM#k15G-2_ulfL zJ^O(Dq0n~1frz!01L}vQOWR9UG;60`aaJqwrwohF-m3$K?1<$kTLXLLkA0hEGsC*1 zy(VtFIeo***2YaLwb&*sVrgRotTDOl<^sR;4d-`6#_47c_A;b15ld?a13TrN z8b8xx2U3^Kq-{UL>Z4I<v8#X#}50m=7){czffuWbYFF?5Zs=^YJ>cgB~d<=E+PJ{&u(>8dL=!V zd$yv-wMGtBnEbtuIJfIUzRfwImyfKL&k4A6`VBeX)lZ$5J^j%Ji0z?}}L+ zblRh9$K8GnDql83cnun>7wckMcDirY@RA?WD>t#*_j;#!qorV?f`FP~qij)NJ*gpZ zd*s#w1GOhDov<$RP2g(ss4-$`2T-HEH_yDim>x5wOU|}4E3UY+e|R~L0*S;9ly*t} zMM}}R-DPuV3| z{HSE}xK>@{TKZW(8=YBxR@Qn8*s}ZV;UaHrg)H^_hrtz4?Wfy6q zPE390p7ZMM!|JDptOiImZH2c+K$RS+TwXl?@mGs4Q&+k#N{=_bFz&csxq)C%jaQhc zQ&X23I+xbVbL*KKC-2@e&|Ceqkn_-*-F?NLw=wO~=LL?{4Ovq>KW|XqQ;mHEu3ewgP-_Z zQ|G^yh~>4XZ(VjjhPIGb}r-d?0`R&6>Y9jUu$ z-eSS?(r8i`sXXk)?aD3klu&L`+0m%e`U|Vf(%4|&NIcPpMPU3W_A%LkrvnGMH;&$Q zYf#_N_Wpi?Q4{8iL$~XrKdBn@D$)7YbZ*ASJ~2sWI{0oQ2R>MtGkbBfeS%+=y;~`> z{p#+o+%GEvJg_DViVk-1YWq1?EAeex`YqTk+(CW`nS2D>CNj z49kCiplptc_MTG>%s^SP6G7Ae@{BddC*96pb>IB0N7d1DTCrV~yQ0B&G|}hj5Gyo+ z*PAHmoq9X??e(9W;)h#XII~IJLi^awY-yGa{X6zlE+_2o50DJi>T2b?~ z1IXf`amuW{uhOZe?s2P5@kQ*-#MX|=^TC0E=mA?!U?85~$M*Kj_MOsFG&5XhU;5Hs z6}G8a8v_FwQNV&g4wD+q0r%g~Uv>cMmdv(FoW5(+O>?R3sX2RghZS+R8H1RD=MgFB zu0D8a1I#TLG%f`k55)GHu}1c$+&RJ9W}V73>sRdBlZ#lJf7iR1gChXof*pA05bLLM zW%bM7pI)q@)n7xe|9kb;)Xo$y@DV9qBpuV>>rs06I?H+3>iE(@D@vn$w~hNg*U|s* XPLFl{>K`c6^aFb}xTr68>-_%!Z4+*I diff --git a/_to_delete_claude/link-fix-wt/index.lock b/_to_delete_claude/link-fix-wt/index.lock deleted file mode 100644 index e69de29bb2d1..000000000000 diff --git a/_to_delete_claude/link-fix-wt/locked b/_to_delete_claude/link-fix-wt/locked deleted file mode 100644 index 6109a85e9ea4..000000000000 --- a/_to_delete_claude/link-fix-wt/locked +++ /dev/null @@ -1 +0,0 @@ -initializing diff --git a/_to_delete_claude/link-fix-wt/logs/HEAD b/_to_delete_claude/link-fix-wt/logs/HEAD deleted file mode 100644 index a61ab6429d9e..000000000000 --- a/_to_delete_claude/link-fix-wt/logs/HEAD +++ /dev/null @@ -1,2 +0,0 @@ -0000000000000000000000000000000000000000 7ac60b27ae9650559dbf483ca7cab0c61175692b rcw-01fzjwn1bbaygchutgdu2p81 1783732562 +0000 -7ac60b27ae9650559dbf483ca7cab0c61175692b 7ac60b27ae9650559dbf483ca7cab0c61175692b rcw-01fzjwn1bbaygchutgdu2p81 1783732563 +0000 reset: moving to HEAD diff --git a/_to_delete_claude/remove-broken-link b/_to_delete_claude/remove-broken-link deleted file mode 100644 index ed9885610fcf..000000000000 --- a/_to_delete_claude/remove-broken-link +++ /dev/null @@ -1 +0,0 @@ -7ac60b27ae9650559dbf483ca7cab0c61175692b diff --git a/_to_delete_claude/remove-broken-link.lock b/_to_delete_claude/remove-broken-link.lock deleted file mode 100644 index e69de29bb2d1..000000000000 diff --git a/drafts/indexer-software/README.md b/drafts/indexer-software/README.md deleted file mode 100644 index 733efcebbdc6..000000000000 --- a/drafts/indexer-software/README.md +++ /dev/null @@ -1,90 +0,0 @@ -# Indexer Software — docs draft - -Draft of the **Indexer Software** documentation section, structured to slot into the docs site under `indexing/`. Every page is grounded in the source repos now consolidated under `graph-gtm-kit/context/indexer-software/` (`indexer`, `indexer-rs`, `graph-node`, `graphprotocol-mainnet-docker`, `graphprotocol-testnet-docker`). - -This folder mirrors the site's Nextra conventions (`_meta.js` for ordering, `_meta-titles.json` for folder titles, MDX pages with `title` / `sidebarTitle` frontmatter), so it can be moved into `website/src/pages/en/indexing/indexer-software/` as-is. - -## Structure - -``` -indexer-software/ "Indexer Software" -├── overview 3-part stack (agent + service-rs + tap-agent), architecture, Horizon -├── install-and-run Install/run all components, shared DB, multi-network, testnet -├── deployment/ "Deploy the Stack" -│ ├── overview What the Docker stack includes + flow -│ ├── mainnet-docker Full mainnet (Arbitrum One) Docker deployment -│ └── testnet-docker Testnet (Arbitrum Sepolia) Docker deployment -├── allocations/ "Managing Allocations" -│ ├── overview Three methods + automatic rule updates -│ ├── operation-modes AUTO / OVERSIGHT / MANUAL + reconciliation loop -│ ├── indexing-rules decisionBasis, thresholds, examples -│ ├── action-queue Queue, statuses, GraphQL API, integrations -│ └── direct-commands Immediate allocation ops -├── managing-provisions Horizon provisions (renamed from "Managing Your Provision") -├── graphtally GraphTally & Query Fees — receipt→RAV flow, redemption, addresses -├── cost-models Agora cost models -├── dispute-monitoring POI dispute monitoring -├── auto-graft Grafted-subgraph dependency automation -├── subgraph-freshness Freshness checker + tuning -├── reference/ "Reference" -│ ├── agent-configuration Full agent flag tables (TS indexer-agent) -│ ├── service-tap-configuration indexer-service-rs / indexer-tap-agent TOML + routes -│ ├── cli-reference Full CLI command listing -│ ├── network-configuration Mainnet/testnet networks + onboarding -│ ├── feature-support-matrix GIP-0008 matrix -│ └── error-codes IE001–IE071 -└── troubleshooting Common issues → fixes -``` - -## Source mapping - -| Draft page | Source (under `context/`) | -| --- | --- | -| overview | `indexer/README.md`, `indexer/CLAUDE.md` | -| install-and-run | `indexer/README.md`, `indexer/docs/testnet-setup.md` | -| deployment/* | `indexer-software/graphprotocol-mainnet-docker/*`, `.../graphprotocol-testnet-docker/*` | -| allocations/overview | `indexer/docs/allocation-management/README.md` | -| allocations/operation-modes | `indexer/docs/operation-modes.md` | -| allocations/indexing-rules | `indexer/docs/allocation-management/rules.md` | -| allocations/action-queue | `indexer/docs/allocation-management/action-queue.md` | -| allocations/direct-commands | `indexer/docs/allocation-management/direct.md` | -| managing-provisions | `indexer/docs/provision-management.md` | -| graphtally | `indexer-software/graph-tally/graph-tally-docs.md`, `.../graph-tally-indexer-micropayments.md`, `indexer-rs/README.md` | -| cost-models | `indexer/packages/indexer-cli/README.md` (cost commands) | -| dispute-monitoring | `indexer/packages/indexer-cli/README.md` (disputes), agent disputes flags | -| auto-graft | `indexer/docs/auto-graft.md` | -| subgraph-freshness | `indexer/docs/subgraph-freshness.md` | -| reference/agent-configuration | `indexer/packages/indexer-agent/README.md` | -| reference/service-tap-configuration | `indexer-rs/README.md`, `indexer-rs/docs/Routes.md`, `graph-tally/graph-tally-docs.md` | -| reference/cli-reference | `indexer/packages/indexer-cli/README.md` | -| reference/network-configuration | `indexer/docs/networks.md`, `.../testnet-setup.md` | -| reference/feature-support-matrix | `indexer/docs/feature-support-matrix.md` | -| reference/error-codes | `indexer/docs/errors.md` | - -## Slotting into the live docs - -Move this folder to `website/src/pages/en/indexing/indexer-software/`, then register it in `indexing/_meta.js` and `indexing/_meta-titles.json`: - -```js -// indexing/_meta.js — add the entry where it should appear in the sidebar -'indexer-software': titles['indexer-software'] ?? '', -``` - -```json -// indexing/_meta-titles.json -{ - "tooling": "Indexer Tooling", - "indexer-software": "Indexer Software" -} -``` - -## Open items / editorial notes - -- **Overlap with the live `/indexing/tap/` page:** the new `graphtally.mdx` is the operational query-fee guide for this section and draws on the same source as the live "GraphTally for Indexers" page. Decide whether this section's page consolidates/replaces `/indexing/tap/` or links to it (current draft links to it as the protocol-level guide). -- **Three-part stack:** Overview, Install and Run, and GraphTally now reflect `indexer-agent` (TS) + `indexer-service-rs` + `indexer-tap-agent` (Rust) sharing one database. The `deployment/*` pages still describe the community Compose stacks, which may package the legacy TS `indexer-service` — reconcile the service layer when finalizing. -- **v2.0.0 / Horizon:** service-rs and tap-agent v2.0.0+ require Horizon and drop V1 receipts; re-verify version gating and contract addresses against the live blockchain-addresses table at publish time. -- **Community Docker stacks:** the `deployment/*` pages document the StakeSquid mainnet/testnet Compose repos. Confirm whether these should be presented as first-party docs, framed as community-maintained (current framing), or linked out only. -- **Chain support:** `reference/feature-support-matrix` and `network-configuration` defer to the canonical Supported Networks source rather than asserting counts — verify links against the live site before publishing. -- **`present-poi` / `resize` / provisions** are marked Horizon-only throughout; re-check against the protocol status at publish time. -- **Error codes** IE037–IE040 are undocumented in source (marked reserved); fill in if descriptions exist upstream. -- Cross-links use `/indexing/indexer-software/...` paths assuming the folder lands under `indexing/`. Update if the final home differs. diff --git a/drafts/indexer-software/_meta-titles.json b/drafts/indexer-software/_meta-titles.json deleted file mode 100644 index 8a1ea65ec567..000000000000 --- a/drafts/indexer-software/_meta-titles.json +++ /dev/null @@ -1,5 +0,0 @@ -{ - "deployment": "Deploy the Stack", - "allocations": "Managing Allocations", - "reference": "Reference" -} diff --git a/drafts/indexer-software/_meta.js b/drafts/indexer-software/_meta.js deleted file mode 100644 index 0e1db3a4c054..000000000000 --- a/drafts/indexer-software/_meta.js +++ /dev/null @@ -1,16 +0,0 @@ -import titles from './_meta-titles.json' - -export default { - overview: '', - 'install-and-run': '', - deployment: titles.deployment ?? '', - allocations: titles.allocations ?? '', - 'managing-provisions': '', - graphtally: 'GraphTally & Query Fees', - 'cost-models': '', - 'dispute-monitoring': '', - 'auto-graft': '', - 'subgraph-freshness': '', - reference: titles.reference ?? '', - troubleshooting: '', -} diff --git a/drafts/indexer-software/allocations/_meta-titles.json b/drafts/indexer-software/allocations/_meta-titles.json deleted file mode 100644 index 0967ef424bce..000000000000 --- a/drafts/indexer-software/allocations/_meta-titles.json +++ /dev/null @@ -1 +0,0 @@ -{} diff --git a/drafts/indexer-software/allocations/_meta.js b/drafts/indexer-software/allocations/_meta.js deleted file mode 100644 index 4d646deecce1..000000000000 --- a/drafts/indexer-software/allocations/_meta.js +++ /dev/null @@ -1,7 +0,0 @@ -export default { - overview: '', - 'operation-modes': '', - 'indexing-rules': '', - 'action-queue': '', - 'direct-commands': '', -} diff --git a/drafts/indexer-software/allocations/action-queue.mdx b/drafts/indexer-software/allocations/action-queue.mdx deleted file mode 100644 index f30db4565092..000000000000 --- a/drafts/indexer-software/allocations/action-queue.mdx +++ /dev/null @@ -1,136 +0,0 @@ ---- -title: Action Queue -sidebarTitle: Action Queue ---- - -The action queue is a staged approach to allocation management. Actions are queued, reviewed, approved, and then executed by a background worker. This enables oversight, batching, and integration with third-party tools. It works in all [operation modes](/indexing/indexer-software/allocations/operation-modes/). - -## How it works - -1. Actions are added to the queue — by the agent, the CLI, or the GraphQL API. -2. Actions sit in `queued` status until approved. -3. Approved actions are picked up by the execution worker (polls roughly every 30 seconds). -4. The worker executes them on-chain and updates their status. - -## CLI commands - -```bash -# View actions -graph indexer actions get all -graph indexer actions get --status queued -graph indexer actions get --status approved -graph indexer actions get --orderBy createdAt --orderDirection desc - -# Queue actions -graph indexer actions queue allocate -graph indexer actions queue unallocate -graph indexer actions queue reallocate -graph indexer actions queue present-poi # Horizon only -graph indexer actions queue resize # Horizon only - -# Approve actions -graph indexer actions approve [ ...] -graph indexer actions approve queued # Approve all queued actions - -# Cancel / delete -graph indexer actions cancel [ ...] -graph indexer actions delete [ ...] - -# Update action parameters -graph indexer actions update --status queued --type reallocate force true poi 0x... - -# Force immediate execution of approved actions -graph indexer actions execute approved -``` - -## Action types - -| Type | Description | Required parameters | -| --- | --- | --- | -| `allocate` | Allocate stake to a deployment. | `deploymentID`, `amount` | -| `unallocate` | Close an existing allocation. | `deploymentID`, `allocationID` (optional `poi`, `force`) | -| `reallocate` | Atomically close an allocation and open a new one for the same deployment. | `deploymentID`, `allocationID`, `amount` (optional `poi`, `force`) | -| `present-poi` *(Horizon)* | Collect indexing rewards by presenting a POI without closing. | `deploymentID`, `allocationID` (optional `poi`, `blockNumber`, `publicPOI`, `force`) | -| `resize` *(Horizon)* | Change the allocated stake without closing. | `deploymentID`, `allocationID`, `amount` | - -## Action statuses - -| Status | Description | -| --- | --- | -| `queued` | Waiting for approval. | -| `approved` | Ready for execution. | -| `pending` | Being executed. | -| `success` | Executed successfully. | -| `failed` | Execution failed. | -| `canceled` | Canceled before execution. | - -## Behavior by operation mode - -| Mode | Agent behavior | Your actions | -| --- | --- | --- | -| **AUTO** | Queues actions as `approved`. | You can still queue your own. | -| **OVERSIGHT** | Queues actions as `queued`. | You must approve before execution. | -| **MANUAL** | Queues nothing. | You queue and approve everything. | - -## GraphQL API - -The indexer management server exposes a GraphQL endpoint (default port `18000`) for programmatic access — the basis for third-party optimizer integrations. - -### Queries and mutations - -```graphql -type Query { - action(actionID: String!): Action - actions(filter: ActionFilter, orderBy: ActionParams, orderDirection: OrderDirection, first: Int): [Action]! -} - -type Mutation { - queueActions(actions: [ActionInput!]!): [Action]! - approveActions(actionIDs: [String!]!): [Action]! - cancelActions(actionIDs: [String!]!): [Action]! - deleteActions(actionIDs: [String!]!): Int! - updateAction(action: ActionInput!): Action! - updateActions(filter: ActionFilter!, action: ActionUpdateInput!): [Action]! - executeApprovedActions: [ActionResult!]! -} -``` - -### Example — queue an action - -```graphql -mutation queueActions($actions: [ActionInput!]!) { - queueActions(actions: $actions) { - id - type - deploymentID - amount - status - } -} -``` - -```json -{ - "actions": [ - { - "status": "queued", - "type": "allocate", - "deploymentID": "QmXYZ...", - "amount": "10000", - "source": "my-optimizer", - "reason": "High signal deployment", - "priority": 0 - } - ] -} -``` - -## Third-party integration - -The action queue lets external optimizers drive allocations while keeping a human in the loop: - -1. The optimizer analyzes network state and identifies optimal allocations. -2. It queues actions via the GraphQL API with `status: queued`. -3. You review the queued actions. -4. You approve them via CLI or API. -5. The execution worker processes the approved actions. diff --git a/drafts/indexer-software/allocations/direct-commands.mdx b/drafts/indexer-software/allocations/direct-commands.mdx deleted file mode 100644 index bc0eee314d3a..000000000000 --- a/drafts/indexer-software/allocations/direct-commands.mdx +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: Direct Commands -sidebarTitle: Direct Commands ---- - -Direct commands execute allocation operations immediately on-chain, bypassing the [action queue](/indexing/indexer-software/allocations/action-queue/) and the reconciliation loop. Use them when you need instant execution without waiting for a queue cycle. They work in all [operation modes](/indexing/indexer-software/allocations/operation-modes/). - -All commands require `-n, --network` (for example `mainnet`, `arbitrum-one`, `sepolia`, `arbitrum-sepolia`) and accept `-o, --output` for `table` (default), `json`, or `yaml`. - -## Get allocations - -```bash -graph indexer allocations get --network -graph indexer allocations get --status active --network -graph indexer allocations get --status closed --network -graph indexer allocations get --allocation --network -``` - -- `--status` — filter by `active` or `closed`. -- `--allocation` — get a specific allocation by ID. - -## Create an allocation - -```bash -graph indexer allocations create [index-node] --network -``` - -- `deployment-id` — bytes32 or IPFS hash. -- `amount` — GRT to allocate. -- `index-node` — (optional) a specific index node to use. - -```bash -graph indexer allocations create QmXa1b2c3d4e5f... 10000 --network arbitrum-one -``` - -## Close an allocation - -```bash -graph indexer allocations close [poi] [block-number] [public-poi] --network -``` - -- `poi` — (optional) proof of indexing. -- `block-number`, `public-poi` — (optional, Horizon only) block the POI was computed at, and the matching public POI. -- `-f, --force` — bypass POI accuracy checks. - -```bash -graph indexer allocations close 0x1234...abcd --network arbitrum-one -graph indexer allocations close 0x1234...abcd 0xpoi... --force --network arbitrum-one -``` - -## Reallocate - -Atomically close an allocation and open a new one for the same deployment. - -```bash -graph indexer allocations reallocate [poi] [block-number] [public-poi] --network -``` - -```bash -graph indexer allocations reallocate 0x1234...abcd 15000 --network arbitrum-one -``` - -## Present POI — Horizon only - -Collect indexing rewards by presenting a POI **without closing** the allocation. - -```bash -graph indexer allocations present-poi [poi] [block-number] [public-poi] --network -``` - -```bash -graph indexer allocations present-poi 0x1234...abcd --network arbitrum-one -``` - -## Resize — Horizon only - -Change the allocated stake without closing the allocation. - -```bash -graph indexer allocations resize --network -``` - -```bash -graph indexer allocations resize 0x1234...abcd 20000 --network arbitrum-one -``` - -## Collect query fees - -Trigger [GraphTally](/indexing/indexer-software/graphtally/) receipt collection for an allocation. This is a separate operation from allocation management — it collects query-fee receipts, not an allocation action. - -> Unlike the other commands here, `collect` **cannot** be queued via the action queue; it always executes immediately. - -```bash -graph indexer allocations collect --network -``` diff --git a/drafts/indexer-software/allocations/indexing-rules.mdx b/drafts/indexer-software/allocations/indexing-rules.mdx deleted file mode 100644 index 12546ca95c85..000000000000 --- a/drafts/indexer-software/allocations/indexing-rules.mdx +++ /dev/null @@ -1,107 +0,0 @@ ---- -title: Indexing Rules -sidebarTitle: Indexing Rules ---- - -Indexing rules tell the agent which subgraph deployments to allocate to and how much stake to use. The [reconciliation loop](/indexing/indexer-software/allocations/operation-modes/) evaluates these rules and queues allocation actions through the [action queue](/indexing/indexer-software/allocations/action-queue/). - -> Rules drive automatic allocation decisions only in **AUTO** and **OVERSIGHT** modes. In **MANUAL** mode the reconciliation loop is skipped entirely and rules have no effect. - -## CLI commands - -```bash -# Set a rule for a specific deployment -graph indexer rules set [ ...] - -# Set the global (default) rule -graph indexer rules set global [ ...] - -# Get rules -graph indexer rules get all -graph indexer rules get -graph indexer rules get global - -# Delete a rule / clear all rules (keeps global) -graph indexer rules delete -graph indexer rules clear - -# Shorthand commands -graph indexer rules start # decisionBasis = always -graph indexer rules stop # decisionBasis = never -graph indexer rules maybe # decisionBasis = rules -graph indexer rules prepare # decisionBasis = offchain -``` - -## Rule parameters - -### Decision basis - -The `decisionBasis` field determines whether the agent allocates to a deployment: - -| Value | Behavior | -| --- | --- | -| `always` | Always allocate to this deployment. | -| `never` | Never allocate to this deployment. | -| `offchain` | Index the deployment but don't allocate (no on-chain stake). | -| `rules` | Evaluate against the threshold parameters below. | - -### Threshold parameters - -Applied when `decisionBasis` is `rules`: - -| Parameter | Description | -| --- | --- | -| `minStake` | Minimum total stake on the deployment. | -| `minSignal` | Minimum curation signal on the deployment. | -| `minAverageQueryFees` | Minimum average query fees. | -| `maxSignal` | Maximum signal (avoid over-allocated deployments). | -| `maxAllocationPercentage` | Maximum percentage of the Indexer's stake to allocate. | - -### Allocation parameters - -| Parameter | Description | -| --- | --- | -| `allocationAmount` | Amount of GRT to allocate. | -| `allocationLifetime` | Number of epochs before reallocating. | -| `parallelAllocations` | Number of parallel allocations to maintain. | - -### Safety parameters - -| Parameter | Description | -| --- | --- | -| `safety` | Enable safety checks (won't allocate to failed deployments). | -| `requireSupported` | Only allocate if the deployment is on a supported network. | -| `autoRenewal` | Automatically reallocate when an allocation expires. | - -## Global vs. deployment-specific rules - -The **global** rule supplies default values for all deployments. A **deployment-specific** rule overrides the global values for that deployment. The agent merges the two, with deployment-specific values taking precedence. - -## Examples - -```bash -# Global defaults -graph indexer rules set global \ - decisionBasis rules \ - minSignal 100 \ - minStake 1000 \ - allocationAmount 10000 \ - safety true - -# Always allocate to a specific high-value deployment -graph indexer rules set QmXYZ... decisionBasis always allocationAmount 50000 - -# Index but don't allocate (offchain indexing) -graph indexer rules set QmABC... decisionBasis offchain - -# Stop allocating to a deployment -graph indexer rules stop QmDEF... -``` - -## How rules drive the reconciliation loop - -1. The agent fetches all deployments from the Network Subgraph. -2. For each, it finds the applicable rule (deployment-specific or global). -3. It evaluates the `decisionBasis`: `always` → allocate; `never` / `offchain` → don't allocate (offchain still indexes locally); `rules` → evaluate thresholds. -4. It compares desired state against current allocations. -5. It queues actions to reconcile: `allocate` (missing), `unallocate` (shouldn't hold), or `reallocate` (expiring). diff --git a/drafts/indexer-software/allocations/operation-modes.mdx b/drafts/indexer-software/allocations/operation-modes.mdx deleted file mode 100644 index 723144168e4b..000000000000 --- a/drafts/indexer-software/allocations/operation-modes.mdx +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: Operation Modes -sidebarTitle: Operation Modes ---- - -The Indexer Agent can manage your allocations automatically through a **reconciliation loop** — a background process that continuously monitors the network and adjusts allocations based on your [indexing rules](/indexing/indexer-software/allocations/indexing-rules/). The **operation mode** controls whether and how that loop runs. - -Set the mode with `--allocation-management` or `INDEXER_AGENT_ALLOCATION_MANAGEMENT`: - -| Mode | Reconciliation loop | Behavior | Best for | -| --- | --- | --- | --- | -| **AUTO** (default) | Runs | Agent decides, auto-approves, and executes. | Hands-off operation. | -| **OVERSIGHT** | Runs | Agent decides and queues actions for your approval. | Review before execution. | -| **MANUAL** | Skipped | You manage allocations yourself via the CLI. | Full manual control, third-party tools. | - -## What is the reconciliation loop? - -The reconciliation loop is the agent's core automation mechanism. On each cycle it: - -1. **Evaluates** which deployments you *should* be allocated to, based on your indexing rules. -2. **Compares** that desired state against your actual on-chain allocations. -3. **Queues actions** to reconcile the difference (allocate, unallocate, reallocate). - -``` -┌─────────────────────┐ ┌──────────────────────────┐ ┌─────────────┐ -│ Deployment │ --> │ Allocation │ --> │ Action │ -│ Evaluation │ │ Reconciliation │ │ Executor │ -│ "What SHOULD we │ │ "What do we need to DO │ │ Execute │ -│ allocate to?" │ │ to match desired state?"│ │ on-chain │ -└─────────────────────┘ └──────────────────────────┘ └─────────────┘ -``` - -In **AUTO** mode, queued actions are auto-approved and execute immediately. In **OVERSIGHT** mode, they wait for your approval. In **MANUAL** mode the loop doesn't run — you queue actions yourself. - -## Reconciliation loop details - -### Polling intervals - -The loop runs on two intervals: a **small interval** (`pollingInterval`) for frequently changing data, and a **large interval** (`pollingInterval * 5`) for stable data. - -| Data | Interval | -| --- | --- | -| Current epoch number | Large | -| Max allocation duration | Large | -| Indexing rules | Small | -| Active deployments on Graph Node | Large (AUTO mode only) | -| Network deployments | Small | -| Active allocations | Small | -| Recently closed allocations | Small | - -### Phase 1 — Deployment evaluation - -Determines which deployments you should be allocated to: - -- Fetches all deployments from the Network Subgraph. -- Matches each against your indexing rules (deployment-specific or global). -- Outputs `toAllocate: true/false` for each deployment. - -Decision basis options: `always`, `never`, `offchain` (index locally, don't allocate on-chain), or `rules` (evaluate against thresholds such as `minStake`, `minSignal`, `minAverageQueryFees`). See [Indexing Rules](/indexing/indexer-software/allocations/indexing-rules/). - -### Phase 2 — Allocation reconciliation - -Compares desired state against actual allocations and queues actions: - -| Condition | Action queued | -| --- | --- | -| Should allocate + no active allocation | ALLOCATE | -| Shouldn't allocate + has active allocation | UNALLOCATE | -| Should allocate + allocation expiring | REALLOCATE | - -An allocation is considered expiring when `currentEpoch >= createdAtEpoch + allocationLifetime`. - -## Safety mechanisms - -The agent includes safeguards against problematic allocations: - -1. **Health check** — won't allocate to deployments with a "failed" health status (when `safety=true` in the rule). -2. **Zero-POI safety** — won't reallocate if the previous allocation closed with a zero POI. -3. **Approved-actions check** — skips reconciliation while pending approved actions exist, preventing conflicts. -4. **Network Subgraph protection** — never auto-allocates to the Network Subgraph unless explicitly enabled via `--allocate-on-network-subgraph`. - -## Related - -- [Indexing Rules](/indexing/indexer-software/allocations/indexing-rules/) — configure what the agent should allocate to. -- [Action Queue](/indexing/indexer-software/allocations/action-queue/) — queue, approve, and execute actions. -- [Direct Commands](/indexing/indexer-software/allocations/direct-commands/) — execute operations immediately. diff --git a/drafts/indexer-software/allocations/overview.mdx b/drafts/indexer-software/allocations/overview.mdx deleted file mode 100644 index 187e096ca83b..000000000000 --- a/drafts/indexer-software/allocations/overview.mdx +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: Managing Allocations -sidebarTitle: Overview ---- - -An **allocation** is stake an Indexer commits to a specific subgraph deployment in order to index it and earn indexing rewards and query fees. Managing allocations is the core day-to-day job of the Indexer Software. There are three ways to do it, ranging from fully automated to fully manual. - -| Method | How it works | When to use | -| --- | --- | --- | -| **[Indexing Rules](/indexing/indexer-software/allocations/indexing-rules/)** | Set rules; the agent decides and acts. | Automated or semi-automated management in AUTO/OVERSIGHT mode. | -| **[Action Queue](/indexing/indexer-software/allocations/action-queue/)** | Queue actions, approve, execute. | Batching, oversight, third-party optimizers. | -| **[Direct Commands](/indexing/indexer-software/allocations/direct-commands/)** | Execute immediately on-chain. | One-off operations, debugging, immediate control. | - -Which of these are active depends on the [operation mode](/indexing/indexer-software/allocations/operation-modes/) the agent runs in. Start there if you haven't set a mode yet. - -## Indexing Rules - -You define rules that specify which deployments to allocate to and how much stake to use. The agent's [reconciliation loop](/indexing/indexer-software/allocations/operation-modes/) evaluates these rules and queues the necessary actions automatically through the action queue. - -```bash -graph indexer rules set QmXYZ... decisionBasis always allocationAmount 10000 -``` - -**Best for:** hands-off operation, where the agent manages allocations based on signal, stake thresholds, or explicit deployment lists. - -**Requires:** AUTO or OVERSIGHT mode. In MANUAL mode the reconciliation loop is skipped and rules have no effect. - -## Action Queue - -Actions are queued, reviewed, approved, and then executed by a background worker — giving you oversight and control over what lands on-chain. - -```bash -graph indexer actions queue allocate QmXYZ... 10000 -graph indexer actions approve 1 -``` - -**Best for:** reviewing actions before execution, batching operations, integrating third-party allocation optimizers, and keeping a history of every action. **Works in all modes.** - -## Direct Commands - -Execute allocation operations immediately, bypassing the action queue entirely. - -```bash -graph indexer allocations create QmXYZ... 10000 --network arbitrum-one -``` - -**Best for:** one-off operations, debugging, or immediate execution without waiting for a queue cycle. **Works in all modes** and always executes immediately. - -## Automatic rule updates - -When allocation actions execute — whether you queued them manually or ran a direct command — the agent updates the corresponding indexing rule so it stays in sync and doesn't fight your manual changes in AUTO/OVERSIGHT mode: - -| Action | Rule update | -| --- | --- | -| `allocate` | Sets `decisionBasis: ALWAYS` | -| `unallocate` | Sets `decisionBasis: OFFCHAIN` | -| `reallocate` | Sets `decisionBasis: ALWAYS` | -| `resize` | Sets `decisionBasis: ALWAYS` | -| `present-poi` | No change | diff --git a/drafts/indexer-software/auto-graft.mdx b/drafts/indexer-software/auto-graft.mdx deleted file mode 100644 index 440f0dcf7fb5..000000000000 --- a/drafts/indexer-software/auto-graft.mdx +++ /dev/null @@ -1,70 +0,0 @@ ---- -title: Auto-Graft -sidebarTitle: Auto-Graft ---- - -Auto-graft lets the Indexer Agent automatically deploy and sync the dependencies of a grafted subgraph. Without it, deploying a grafted subgraph means manually identifying every dependency in the graft chain, deploying each in the right order, syncing each to its required block, and pausing it. Auto-graft does all of that for you, so a grafted subgraph deploys like any other. - -Grafting itself lets a new subgraph build on an existing one at a chosen block height, reusing already-indexed data instead of re-indexing from genesis. See the [subgraph grafting docs](/subgraphs/cookbook/grafting/) for authoring details. - -## Enabling auto-graft - -Auto-graft is **disabled by default** (as of agent v0.24.3) and requires an IPFS endpoint to fetch dependency manifests. - -```sh -graph-indexer-agent start \ - --enable-auto-graft \ - --ipfs-endpoint https://ipfs.network.thegraph.com \ - ... -``` - -| Setting | Flag / Env | Default | -| --- | --- | --- | -| Enable auto-graft | `--enable-auto-graft` / `INDEXER_AGENT_ENABLE_AUTO_GRAFT` | `false` | -| IPFS endpoint | `--ipfs-endpoint` / `INDEXER_AGENT_IPFS_ENDPOINT` | `https://ipfs.network.thegraph.com` | - -> Prior to v0.24.3, auto-graft was enabled automatically whenever an IPFS endpoint was configured. It must now be enabled explicitly. - -## How it works - -When you deploy a subgraph that declares a graft, the agent: - -1. **Detects** the graft configuration in the subgraph manifest. -2. **Resolves** the full dependency chain, recursively fetching manifests from IPFS. -3. **Orders** dependencies from deepest to root so they deploy in the correct sequence. -4. **Deploys** any missing dependencies. -5. **Syncs** each dependency to its required block height. -6. **Pauses** each dependency once it reaches its target block, to save resources. - -For a chain where your subgraph grafts from A at block 15M, A grafts from B at 10M, and B grafts from C at 5M, auto-graft deploys and syncs C → B → A in order, then begins indexing your subgraph from block 15M. - -## Monitoring progress - -Track auto-graft through the agent logs. Key messages include: - -- `Auto graft deploy subgraph dependencies` — process started -- `graft dep chain found` — dependencies identified -- `Begin syncing subgraph deployment to block` — a dependency is syncing -- `Graft dependency has reached target block height. Continuing to index past graft point.` — dependency ready - -Check dependency status with the CLI: - -```sh -graph indexer status -graph indexer status -``` - -## Troubleshooting - -| Problem | Likely cause and fix | -| --- | --- | -| `IPFS request failed` | Verify `INDEXER_AGENT_IPFS_ENDPOINT` is reachable and the manifest hash is valid. | -| `Sync to block X deadline reached` | The dependency is syncing slowly — check Graph Node performance and that the chain is fully synced. | -| `Subgraph not found in indexing status` | Confirm the dependency hash is correct and that the dependency was created successfully; check Graph Node logs. | -| Circular dependency | Ensure the graft chain is linear; fix circular references in the manifests. | - -## Requirements - -- Graph Node running with grafting support (supported on all networks). -- The Indexer must be able to reach an IPFS endpoint (`/api/v0` HTTP API). -- Auto-graft explicitly enabled. diff --git a/drafts/indexer-software/cost-models.mdx b/drafts/indexer-software/cost-models.mdx deleted file mode 100644 index 7e3e4654acab..000000000000 --- a/drafts/indexer-software/cost-models.mdx +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: Cost Models -sidebarTitle: Cost Models ---- - -Cost models let an Indexer price the queries it serves. Each model is written in **Agora**, a small declarative language for mapping GraphQL query shapes to a price. Gateways use the advertised prices when routing, and `indexer-service-rs` exposes them on its `/cost` endpoint. - -Cost models are managed with the Indexer CLI and stored in the shared database, so they take effect without restarting the agent. - -## CLI commands - -```sh -$ graph indexer cost --help -Manage costing for subgraphs - - indexer cost set model Update a cost model - indexer cost get Get cost models for one or all subgraphs - indexer cost delete Remove one or many cost models -``` - -### Set a cost model - -Set a model for a specific deployment, or set the `global` model that applies to any deployment without its own: - -```sh -# Apply an Agora model file to a deployment -graph indexer cost set model my-model.agora - -# Set the global default model -graph indexer cost set model global my-model.agora -``` - -### Get cost models - -```sh -graph indexer cost get all -graph indexer cost get -graph indexer cost get global -``` - -### Delete cost models - -```sh -graph indexer cost delete -``` - -## Global vs. deployment-specific models - -As with [indexing rules](/indexing/indexer-software/allocations/indexing-rules/), a `global` cost model provides defaults and deployment-specific models override it. A deployment without its own model falls back to `global`. - -## Related - -- [Indexing Rules](/indexing/indexer-software/allocations/indexing-rules/) — deciding *what* to index and allocate to. -- [GraphTally & Query Fees](/indexing/indexer-software/graphtally/) — how the query fees priced here are collected. diff --git a/drafts/indexer-software/deployment/_meta-titles.json b/drafts/indexer-software/deployment/_meta-titles.json deleted file mode 100644 index 0967ef424bce..000000000000 --- a/drafts/indexer-software/deployment/_meta-titles.json +++ /dev/null @@ -1 +0,0 @@ -{} diff --git a/drafts/indexer-software/deployment/_meta.js b/drafts/indexer-software/deployment/_meta.js deleted file mode 100644 index c154dfd6ab2a..000000000000 --- a/drafts/indexer-software/deployment/_meta.js +++ /dev/null @@ -1,5 +0,0 @@ -export default { - overview: '', - 'mainnet-docker': '', - 'testnet-docker': '', -} diff --git a/drafts/indexer-software/deployment/mainnet-docker.mdx b/drafts/indexer-software/deployment/mainnet-docker.mdx deleted file mode 100644 index 93cb4b6f6f28..000000000000 --- a/drafts/indexer-software/deployment/mainnet-docker.mdx +++ /dev/null @@ -1,131 +0,0 @@ ---- -title: Mainnet Docker Deployment -sidebarTitle: Mainnet Docker ---- - -The **mainnet Docker Compose** stack spins up a complete Indexer on a single machine for The Graph Network mainnet (Arbitrum One): Graph Node, the Indexer Agent/Service/CLI, PostgreSQL, and a full monitoring stack. It is community-maintained at [github.com/StakeSquid/graphprotocol-mainnet-docker](https://github.com/StakeSquid/graphprotocol-mainnet-docker). - -> Read the stack's full documentation before running in production. You must supply your own Ethereum archive node (EIP-1898); it is not part of this setup. - -## Prerequisites - -### Stake and operator - -Stake a minimum of **100,000 GRT** through [Graph Explorer](https://thegraph.com/explorer) (Profile → Indexing → Stake), then register a separate **operator wallet** (Settings → Operators) that the stack uses to send transactions while your staked GRT stays on a different wallet. See [Network Configuration](/indexing/indexer-software/reference/network-configuration/). - -### Hardware (guidance) - -Requirements scale with your stake and the subgraphs you serve. As a rough guide from the stack maintainers: - -| | Minimum | Recommended | -| --- | --- | --- | -| Graph infra CPU | 16 vcore | 64 vcore | -| Graph infra RAM | 32 GB | 128 GB | -| Graph infra storage | 300 GB SSD | 2 TB NVMe | -| Archive node storage (Erigon) | 3 TB SSD | 5 TB NVMe | - -### Software - -```bash -apt update -y && apt upgrade -y && apt autoremove -y -apt install docker.io docker-compose httpie curl wget git jq nano apparmor -y -# install envsubst -curl -L https://github.com/a8m/envsubst/releases/download/v1.2.0/envsubst-`uname -s`-`uname -m` \ - -o envsubst && chmod +x envsubst && sudo mv envsubst /usr/bin/envsubst -``` - -## Install - -```bash -git clone git@github.com:StakeSquid/graphprotocol-mainnet-docker.git -cd graphprotocol-mainnet-docker -git submodule init -git submodule update -``` - -## Configure DNS - -Point two subdomains at your server's IP: - -``` -index.sld.tld -grafana.sld.tld -``` - -## Configure environment - -Edit `.env` and set at least the required variables: - -```bash -EMAIL=email@sld.tld # for SSL certificate issuance -INDEX_HOST=index.sld.tld # public indexer endpoint (gateway queries this) -GRAFANA_HOST=grafana.sld.tld # monitoring dashboard -ADMIN_USER=your_user # Grafana/Prometheus/Alertmanager -ADMIN_PASSWORD=your_password -DB_USER=your_db_user # Postgres init -DB_PASS=your_db_password -GRAPH_NODE_DB_NAME=your_graphnode_db_name -AGENT_DB_NAME=your_agent_db_name -CHAIN_0_NAME="network-name" # chain to index -CHAIN_0_RPC="http://ip:port" # your archive RPC -TXN_RPC="http://ip:port" # RPC used by agent/service for transactions -OPERATOR_SEED_PHRASE="12 or 15 word mnemonic" -STAKING_WALLET_ADDRESS=0xAddress -GEO_COORDINATES='69.420 69.420' -``` - -Optional stacks (Agent GUI, POIfier, Graphcast Subgraph Radio) have their own commented variables in `.env`. - -### Supporting multiple chains - -To index more than one chain, add a `[chains.${CHAIN_N_NAME}]` provider block to `graph-node-configs/config.tmpl` and add the matching `CHAIN_N_NAME` / `CHAIN_N_RPC` variables: - -``` -CHAIN_0_NAME="gnosis" -CHAIN_0_RPC="http://ip:port" -CHAIN_1_NAME="matic" -CHAIN_1_RPC="http://ip:port" -``` - -## Start - -```bash -bash start-essential # graph-node + indexer + monitoring — everything to get on the network -``` - -Other start scripts: `start-optional`, `start-autoagora`, and `start-all`. To rebuild a component, append `--force-recreate `; omit the container name to rebuild the whole stack. - -Initial startup takes several minutes (the CLI container is slow to build). Verify with: - -```bash -docker ps -``` - -Look for containers stuck `restarting` — inspect their logs to debug. - -## Default ports - -| Service | Port | Purpose | -| --- | --- | --- | -| Graph Node | 8000 | GraphQL HTTP (subgraph queries) | -| Graph Node | 8020 | JSON-RPC (manage deployments) | -| Graph Node | 8030 | Indexing status API | -| Graph Node | 8040 | Prometheus metrics | -| Indexer Service | 7600 | GraphQL HTTP (paid queries) | -| Indexer Service | 7300 | Prometheus metrics | -| Indexer Agent | 8000 | Indexer management API (`graph indexer`) | - -## Updating - -```bash -cd graphprotocol-mainnet-docker -git fetch && git pull -bash start-essential --force-recreate -git submodule update # update Agora / Qlog helper modules -``` - -## Next steps - -- [Set up allocations](/indexing/indexer-software/allocations/overview/) -- [Configure cost models](/indexing/indexer-software/cost-models/) -- [Troubleshooting](/indexing/indexer-software/troubleshooting/) diff --git a/drafts/indexer-software/deployment/overview.mdx b/drafts/indexer-software/deployment/overview.mdx deleted file mode 100644 index 7614b7d6ee03..000000000000 --- a/drafts/indexer-software/deployment/overview.mdx +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: Deploy the Indexer Stack -sidebarTitle: Overview ---- - -Running an Indexer means operating several coordinated services: [Graph Node](/indexing/tooling/graph-node/) (index and query nodes), the [Indexer Agent and Service](/indexing/indexer-software/overview/), PostgreSQL databases, and a monitoring stack. The community-maintained Docker Compose stacks bundle all of these on a single machine, which is the fastest way to stand up a full Indexer. - -Two variants exist, differing mainly in the protocol network they target: - -| Stack | Network | Use it for | -| --- | --- | --- | -| [Mainnet Docker](/indexing/indexer-software/deployment/mainnet-docker/) | The Graph Network mainnet (Arbitrum One) | Production indexing on mainnet. | -| [Testnet Docker](/indexing/indexer-software/deployment/testnet-docker/) | The Graph Network testnet (Arbitrum Sepolia) | Practicing and qualifying before mainnet. | - -> These Docker stacks are community-maintained by [StakeSquid](https://github.com/StakeSquid) and are not the only way to run an Indexer. Bare-metal and Kubernetes deployments are also supported. Read the full stack documentation before running in production. - -## What the stack includes - -A full deployment spins up several groups of containers: - -- **Graph Node stack** — index node, query node, and a Postgres database. -- **Indexer stack** — Indexer Agent, Indexer Service, Indexer CLI, an Nginx/SSL proxy, and a Postgres database. -- **Monitoring stack** — Prometheus, Grafana, Alertmanager, Node Exporter, cAdvisor, and Pushgateway. -- **Optional stacks** — AutoAgora (automated cost models), POIfier, and the Indexer Agent GUI. - -You bring your own **Ethereum archive node** — an archive RPC supporting EIP-1898 is required and is *not* part of the Docker setup. - -## What you need before starting - -- A server sized for the workload (production indexing needs substantial CPU, RAM, and NVMe storage — plan to scale with your stake). -- Docker Engine, Docker Compose, and supporting tools (`git`, `jq`, `curl`, `wget`, `httpie`, `envsubst`). -- An archive RPC endpoint (EIP-1898) for each chain you index. -- A domain name (for SSL on your public indexer and Grafana endpoints). -- An **operator wallet** mnemonic and your **staking wallet** address (kept on separate mnemonics). - -## Deployment flow - -Both stacks follow the same shape: - -1. [Stake and set an operator](/indexing/indexer-software/reference/network-configuration/) on the target network. -2. Clone the repository and initialize its submodules. -3. Point DNS subdomains at your server. -4. Fill in the `.env` file with your hosts, database credentials, RPCs, and operator seed phrase. -5. Start the essential stack (`bash start-essential`), then verify with `docker ps`. -6. Configure [indexing rules](/indexing/indexer-software/allocations/indexing-rules/) and [cost models](/indexing/indexer-software/cost-models/). - -Pick your network to continue: [Mainnet Docker](/indexing/indexer-software/deployment/mainnet-docker/) or [Testnet Docker](/indexing/indexer-software/deployment/testnet-docker/). diff --git a/drafts/indexer-software/deployment/testnet-docker.mdx b/drafts/indexer-software/deployment/testnet-docker.mdx deleted file mode 100644 index a20335b271e9..000000000000 --- a/drafts/indexer-software/deployment/testnet-docker.mdx +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: Testnet Docker Deployment -sidebarTitle: Testnet Docker ---- - -The **testnet Docker Compose** stack is the counterpart of the [mainnet stack](/indexing/indexer-software/deployment/mainnet-docker/), targeting The Graph Network testnet on **Arbitrum Sepolia**. It's the recommended way to practice running an Indexer — and to qualify through the testnet — before deploying on mainnet. It is community-maintained at [github.com/StakeSquid/graphprotocol-testnet-docker](https://github.com/StakeSquid/graphprotocol-testnet-docker). - -The container layout, `.env` structure, start scripts, and ports are the same as the mainnet stack. This page covers only what differs for testnet. - -## Get testnet funds - -Participation requires Sepolia ETH and testnet GRT (minimum stake **100k testnet GRT**): - -1. Join [The Graph Discord](https://thegraph.com/discord/). -2. Get the `@testnetindexer` role in the `#roles` channel. -3. Request testnet GRT in the `#arbi-sepolia-faucet` channel. - -## Stake and set an operator - -Use the [testnet explorer](https://testnet.thegraph.com/) (Metamask → Arbitrum Sepolia) to stake and register an operator, or the Contracts CLI. See [Network Configuration](/indexing/indexer-software/reference/network-configuration/#testnet-arbitrum-sepolia) for the exact commands. - -## Install and configure - -```bash -git clone git@github.com:StakeSquid/graphprotocol-testnet-docker.git -cd graphprotocol-testnet-docker -git submodule init -git submodule update -``` - -Configure DNS subdomains and the `.env` file exactly as in the [mainnet guide](/indexing/indexer-software/deployment/mainnet-docker/#configure-environment), with two differences: - -- Point `CHAIN_0_RPC` / `TXN_RPC` at **Arbitrum Sepolia** archive/transaction RPCs. -- Fund the operator wallet with **Sepolia ETH**, not mainnet ETH. - -## Start and verify - -```bash -bash start-essential -docker ps -``` - -## Next steps - -Once the stack is healthy, exercise the full workflow on testnet before going to mainnet: - -- [Set up allocations](/indexing/indexer-software/allocations/overview/) -- [Configure cost models](/indexing/indexer-software/cost-models/) -- [Troubleshooting](/indexing/indexer-software/troubleshooting/) - -When you're ready for production, follow the [Mainnet Docker Deployment](/indexing/indexer-software/deployment/mainnet-docker/). diff --git a/drafts/indexer-software/dispute-monitoring.mdx b/drafts/indexer-software/dispute-monitoring.mdx deleted file mode 100644 index e63d9de2e0a8..000000000000 --- a/drafts/indexer-software/dispute-monitoring.mdx +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: POI Dispute Monitoring -sidebarTitle: Dispute Monitoring ---- - -Indexers submit **Proofs of Indexing (POIs)** when they close allocations. A POI attests that the Indexer holds correct data for a deployment at a given block. The Indexer Agent can monitor the network for POIs that disagree with your own, surfacing potential disputes before they become a problem. - -## Enabling dispute monitoring - -POI dispute monitoring is off by default. Enable it on the agent: - -```sh -graph-indexer-agent start \ - --poi-dispute-monitoring \ - --poi-disputable-epochs 1 \ - ... -``` - -| Flag | Description | Default | -| --- | --- | --- | -| `--poi-dispute-monitoring` | Monitor the network for potential POI disputes. | `false` | -| `--poi-disputable-epochs` | How many past epochs to look back for potential disputes. | `1` | - -## Reviewing potential disputes - -Use the CLI to cross-check POIs submitted across the network against your own: - -```sh -$ graph indexer disputes --help -Configure allocation POI monitoring - - indexer disputes get Cross-check POIs submitted in the network -``` - -```sh -graph indexer disputes get -``` - -This lists allocations where a submitted POI is potentially disputable, so you can investigate before an on-chain dispute is raised. - -## Related - -- [Direct Commands](/indexing/indexer-software/allocations/direct-commands/) — where POIs are supplied when closing allocations. -- [Indexing Overview](/indexing/overview/) — arbitration and slashing context. diff --git a/drafts/indexer-software/graphtally.mdx b/drafts/indexer-software/graphtally.mdx deleted file mode 100644 index e1efc623cecf..000000000000 --- a/drafts/indexer-software/graphtally.mdx +++ /dev/null @@ -1,89 +0,0 @@ ---- -title: GraphTally & Query Fees -sidebarTitle: GraphTally & Query Fees ---- - -**GraphTally** (formerly the Timeline Aggregation Protocol, TAP) is The Graph's payment system for query fees — a fast, trust-minimized micropayment protocol integrated into the core protocol through [Graph Horizon](/graph-horizon/overview/). This page covers how query fees flow through your Indexer stack and how to operate the components that collect them. For the full TOML settings, see [Service & TAP Agent Configuration](/indexing/indexer-software/reference/service-tap-configuration/). - -## Why GraphTally - -Active Indexers serve hundreds of thousands of queries per day. Settling each one with an on-chain transaction would cost far more than the query is worth. GraphTally instead uses a **one-way payment channel**: the gateway (Sender) signs a small **Receipt** for each query, the Indexer (Receiver) verifies and tallies receipts off-chain, and only periodically settles the accumulated total on-chain. Because payment flows in one direction, no dispute window is needed — the Indexer is incentivized to submit the latest total. - -## How it works - -GraphTally aggregates many signed **Receipts** into a single **Receipt Aggregate Voucher (RAV)** that can be redeemed on-chain. In your stack: - -1. The gateway sends a signed receipt with each query. -2. `indexer-service-rs` validates the receipt and stores it in the shared database. -3. `indexer-tap-agent` periodically aggregates receipts into a RAV, keeping unaggregated value below your `max_amount_willing_to_lose_grt` threshold. -4. RAVs accumulate value as new receipts arrive. -5. After an allocation closes, a final RAV is created and the **Indexer Agent** redeems it on-chain. - -The three components — service, TAP agent, and agent — all share the same PostgreSQL database. Run **exactly one** `indexer-tap-agent`; `indexer-service-rs` can be scaled horizontally. - -## RAV redemption lifecycle - -Redemption is fully automated when `indexer-tap-agent` and `indexer-agent` are both running: - -1. The Indexer closes an allocation. -2. After the `recently-closed-allocation-buffer` period, `indexer-tap-agent` aggregates the remaining receipts into a final RAV marked `last`. -3. `indexer-agent` submits the redeem transaction on-chain. -4. During the `finality-time` period, `indexer-agent` watches for chain reorganizations — reverted transactions are resubmitted, confirmed ones are marked `final`. - -The TAP agent reconciles redemptions against the Network Subgraph (querying `paymentsEscrowTransactions`) roughly every 5 minutes by default (`tap.allocation_reconciliation_interval_secs`). - -## Receipt validation - -`indexer-service-rs` validates every incoming receipt before storing it, checking that: the receipt targets a valid, active allocation; the `payer` matches a known sender; the `data_service` matches your configured `subgraph_service_address`; the `service_provider` matches your Indexer address; the sender has sufficient escrow balance; the value doesn't exceed `max_receipt_value_grt`; and the timestamp is within bounds. - -## Blockchain addresses - -Configure your services with the correct contract and gateway addresses for the network. These are the canonical values from the GraphTally guide; verify against the [live blockchain addresses table](/indexing/tap/#blockchain-addresses) before use. - -### Contracts - -| Contract | Arbitrum Mainnet (42161) | Arbitrum Sepolia (421614) | -| --- | --- | --- | -| TAP Verifier | `0x8f69F5C07477Ac46FBc491B1E6D91E2be0111A9e` | `0x382863e7B662027117449bd2c49285582bbBd21B` | -| Subgraph Service | `0xb2Bb92d0DE618878E438b55D5846cfecD9301105` | `0xc24A3dAC5d06d771f657A48B20cE1a671B78f26b` | -| TAP Escrow | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` | - -### Gateway - -| Component | Arbitrum Mainnet | Arbitrum Sepolia (Testnet) | -| --- | --- | --- | -| Sender | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467` | `0xC3dDf37906724732FfD748057FEBe23379b0710D` | -| Aggregator | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` | - -## Software requirements - -- **indexer-agent** — [latest version](https://github.com/graphprotocol/indexer/releases) -- **indexer-service-rs** v2.0.0+ — [latest release](https://github.com/graphprotocol/indexer-rs/releases?q=indexer-service-rs) -- **indexer-tap-agent** v2.0.0+ — [latest release](https://github.com/graphprotocol/indexer-rs/releases?q=indexer-tap-agent) - -> **Horizon required from v2.0.0.** Starting with v2.0.0, `indexer-service-rs` and `indexer-tap-agent` require Graph Horizon and legacy V1 receipt support is removed. Set `[horizon].enabled = true` and configure `receipts_verifier_address_v2` and `subgraph_service_address` before upgrading. See the migration steps in [Service & TAP Agent Configuration](/indexing/indexer-software/reference/service-tap-configuration/#upgrading-to-v200). - -## Monitoring - -Both Rust services expose Prometheus metrics on port `7300` (`/metrics`). Key things to watch: - -- **Unaggregated fees** — keep below `max_amount_willing_to_lose_grt`; if it climbs, the TAP agent isn't aggregating fast enough (or at all). -- **RAV request success/failure** — repeated failures usually mean an aggregator endpoint or sender-config problem. -- **Sender balances** — track escrow balances and outstanding obligations. - -Import the [official Grafana dashboard](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) to visualize receipt flow, RAV lifecycle, and error rates. - -## Troubleshooting - -| Symptom | Things to check | -| --- | --- | -| RAV requests failing | Aggregator endpoint connectivity; `tap.sender_aggregator_endpoints` config; debug logs (`RUST_LOG=...=debug`). | -| Receipts not aggregating | Exactly one `indexer-tap-agent` running; database connectivity; `max_amount_willing_to_lose_grt` not set too high. | -| High unaggregated fees | Lower `max_amount_willing_to_lose_grt` to aggregate more often; check whether a specific sender is failing. | -| Service won't start (missing config) | `horizon.enabled = true`; both `receipts_verifier_address_v2` and `subgraph_service_address` set; Network Subgraph reachable. | - -## Related - -- [Service & TAP Agent Configuration](/indexing/indexer-software/reference/service-tap-configuration/) — full TOML reference. -- [Direct Commands](/indexing/indexer-software/allocations/direct-commands/#collect-query-fees) — manually triggering receipt collection. -- [GraphTally for Indexers](/indexing/tap/) — the protocol-level guide. diff --git a/drafts/indexer-software/install-and-run.mdx b/drafts/indexer-software/install-and-run.mdx deleted file mode 100644 index f2288504b943..000000000000 --- a/drafts/indexer-software/install-and-run.mdx +++ /dev/null @@ -1,118 +0,0 @@ ---- -title: Install and Run the Indexer Software -sidebarTitle: Install and Run ---- - -This page covers installing and starting the Indexer stack: the TypeScript **Indexer Agent** and **CLI**, plus the Rust **Indexer Service** (`indexer-service-rs`) and **TAP Agent** (`indexer-tap-agent`). For the complete flag/config references, see [Agent Configuration](/indexing/indexer-software/reference/agent-configuration/) and [Service & TAP Agent Configuration](/indexing/indexer-software/reference/service-tap-configuration/). - -> The agent, service, and TAP agent all share **one PostgreSQL database**. Run the agent's migrations against it (see below); the Rust services use the same schema but must not run their own migrations. Run exactly **one** `indexer-tap-agent` instance; `indexer-service-rs` can be scaled horizontally. - -## Prerequisites - -- **Node.js** >= 18 -- **PostgreSQL** — a database the agent can connect to -- A running **[Graph Node](/indexing/tooling/graph-node/)** with query, status, and admin endpoints reachable -- An **Ethereum/Arbitrum RPC** endpoint -- An **operator wallet** mnemonic and your **Indexer address** -- Access to the **Network Subgraph** and **Epoch Subgraph** endpoints (or a gateway that serves them) - -## Installation - -The Indexer CLI is an extension for [`graph-cli`](https://github.com/graphprotocol/graph-cli), so install them together. - -```sh -# Indexer Agent -npm install -g @graphprotocol/indexer-agent - -# CLI (plus graph-cli, which it extends) -npm install -g @graphprotocol/graph-cli -npm install -g @graphprotocol/indexer-cli -``` - -### Indexer Service and TAP Agent (Rust) - -The Rust services are distributed as prebuilt Docker images (tags track their own release versions on [`indexer-rs`](https://github.com/graphprotocol/indexer-rs/releases)): - -```sh -docker pull ghcr.io/graphprotocol/indexer-service-rs:latest -docker pull ghcr.io/graphprotocol/indexer-tap-agent:latest -``` - -They can also be built from source with Rust: - -```sh -git clone https://github.com/graphprotocol/indexer-rs.git && cd indexer-rs -cargo build --release -p indexer-service-rs -cargo build --release -p indexer-tap-agent -``` - -Both take a single shared TOML config via `--config`. See [Service & TAP Agent Configuration](/indexing/indexer-software/reference/service-tap-configuration/) and [GraphTally & Query Fees](/indexing/indexer-software/graphtally/). - -### Docker (Agent) - -Prebuilt agent images are published to GitHub Container Registry. - -```sh -docker pull ghcr.io/graphprotocol/indexer-agent:latest -docker run -p 8000:8000 ghcr.io/graphprotocol/indexer-agent:latest start ... -``` - -## Running the agent - -```sh -graph-indexer-agent start \ - --network-provider \ - --graph-node-query-endpoint /subgraphs \ - --graph-node-status-endpoint /graphql \ - --graph-node-admin-endpoint /deploy \ - --mnemonic \ - --indexer-address \ - --postgres-host \ - --postgres-database \ - --network-subgraph-endpoint \ - --epoch-subgraph-endpoint \ - --gateway-endpoint \ - --public-indexer-url -``` - -Every flag can also be set with an `INDEXER_AGENT_`-prefixed environment variable (for example `--network-provider` ↔ `INDEXER_AGENT_ETHEREUM`). See the [Agent Configuration reference](/indexing/indexer-software/reference/agent-configuration/) for the full list. - -## Connecting the CLI - -The CLI talks to the agent's indexer management API (default port `8000`). - -```sh -graph indexer connect http://url.of.indexer-agent:8000/ -``` - -Once connected you can drive the agent: - -```sh -# Set a global rule to allocate to everything at 1000 GRT -graph indexer rules set global decisionBasis always allocationAmount 1000 - -# List your allocations on a network -graph indexer allocations get --network arbitrum-one - -# Inspect the action queue -graph indexer actions get all -``` - -## Database migrations - -The agent, service, and TAP agent share one PostgreSQL database, and **only the Indexer Agent runs migrations** against it. Point `indexer-service-rs` and `indexer-tap-agent` at the same `postgres_url` but never run migrations from the `indexer-rs` stack — doing so risks schema conflicts. The agent manages schema changes with Umzug. From the `indexer-agent` package: - -```sh -yarn migrator:pending # View pending migrations -yarn migrator:executed # View applied migrations -yarn migrator:up # Apply pending migrations -yarn migrator:down # Roll back the last migration -``` - -## Multi-network mode - -To run the agent across multiple protocol networks at once, set `INDEXER_AGENT_MULTINETWORK_MODE=true` and provide a directory of network specification files via `--network-specifications-directory`. See the [Agent Configuration reference](/indexing/indexer-software/reference/agent-configuration/) for the multi-network flag set. - -## Testnet - -The Graph Network testnet runs on **Arbitrum Sepolia**. To participate you need Sepolia ETH and testnet GRT (minimum stake 100k testnet GRT), which you can request through The Graph Discord. You can approve, stake, and set an operator either through [Graph Explorer](https://testnet.thegraph.com/) or the Contracts CLI. See the [Network Configuration reference](/indexing/indexer-software/reference/network-configuration/) for testnet setup details. diff --git a/drafts/indexer-software/managing-provisions.mdx b/drafts/indexer-software/managing-provisions.mdx deleted file mode 100644 index 367cdde69661..000000000000 --- a/drafts/indexer-software/managing-provisions.mdx +++ /dev/null @@ -1,113 +0,0 @@ ---- -title: Managing Provisions -sidebarTitle: Managing Provisions ---- - -In [Graph Horizon](/graph-horizon/overview/), stake is assigned to **provisions** rather than held as a single pool. A provision commits a portion of your stake to a specific data service — currently the `SubgraphService`, which powers subgraph indexing and query serving. This page explains how provisions work and how to manage them with the Indexer CLI. - -## Stake terminology - -| Term | Meaning | -| --- | --- | -| **Indexer stake** | All tokens the Indexer has staked. | -| **Idle stake** | Stake not assigned to a provision and not part of legacy allocations. | -| **Provisioned stake** | Stake assigned to a provision. | -| **Delegated stake** | Stake delegated to a specific (Indexer, provision). Pre-Horizon delegation is automatically credited to the `SubgraphService` provision. | -| **Available stake** | Stake usable within the provision (for example, for allocations). Includes provisioned tokens plus delegated stake. | - -## Creating the SubgraphService provision - -The **Indexer Agent** performs the initial provision creation. It is attempted only when the agent starts, and only if the Indexer's idle stake exceeds 100k GRT: - -``` -idle stake > 100k GRT -(indexer stake − legacy allocated stake) > 100k GRT -``` - -The agent must be configured with a maximum initial provision size: - -```sh -# Environment variable -INDEXER_AGENT_MAX_PROVISION_INITIAL_SIZE=100000 -``` - -```yaml -# Config file -indexerOptions: - maxProvisionInitialSize: 100000 -``` - -## Provision operations - -There are three basic operations on a provision: - -- **`provision()` / `addToProvision()`** — add idle stake to a provision. -- **`thaw()`** — begin thawing available stake out of a provision (subject to a thawing period). -- **`deprovision()`** — move thawed stake back into the idle stake pool. - -Getting stake into and out of the protocol still requires `stake()` and `unstake()` separately. - -These operations can be run through the Indexer CLI or Graph Explorer. The CLI is recommended because it is more flexible. - -### Graph Explorer - -- Staking through Graph Explorer automatically provisions the added stake to the `SubgraphService` (if the provision exists). -- Unstaking/withdrawing automatically thaws and deprovisions stake from the provision. - -### Indexer CLI - -```sh -$ graph indexer provision --help -Manage indexer's provision - - indexer provision get List indexer provision details - indexer provision add Add stake to the indexer's provision - indexer provision thaw Thaw stake from the indexer's provision - indexer provision list-thaw List thaw requests for the indexer's provision - indexer provision remove Remove thawed stake from the indexer's provision -``` - -> **Note:** The provision must first be created by the Indexer Agent (see above) before these CLI commands can manage it. - -**Get provision details** - -```sh -$ graph indexer --network arbitrum-one provision get -``` - -Shows `tokensProvisioned`, `tokensAllocated`, `tokensThawing`, `maxVerifierCut`, and `thawingPeriod` for each data service, plus your current idle stake. - -**Add stake to the provision** - -```sh -$ graph indexer --network arbitrum-one provision add 100000 -``` - -**Thaw stake from the provision** - -Multiple thaw requests can be in flight simultaneously. Each is subject to the provision's thawing period. - -```sh -$ graph indexer --network arbitrum-one provision thaw 50000 -``` - -**List ongoing thaw requests** - -Also shows thaw requests initiated through Graph Explorer. - -```sh -$ graph indexer --network arbitrum-one provision list-thaw -``` - -**Remove thawed stake** - -Moves thawed stake back into the Indexer's idle stake pool. - -```sh -$ graph indexer --network arbitrum-one provision remove -``` - -## Related - -- [Managing Allocations](/indexing/indexer-software/allocations/overview/) — how provisioned stake is put to work. -- [Graph Horizon Overview](/graph-horizon/overview/) — the architecture behind provisions. diff --git a/drafts/indexer-software/overview.mdx b/drafts/indexer-software/overview.mdx deleted file mode 100644 index 80bc9c984e19..000000000000 --- a/drafts/indexer-software/overview.mdx +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: Indexer Software Overview -sidebarTitle: Overview ---- - -Indexer Software is the set of components an Indexer runs to participate in The Graph Network: an agent that manages allocations and redeems payments, a Rust service that answers paid queries, a Rust agent that turns query receipts into redeemable vouchers, and a CLI to operate it all. This section covers how to install, configure, and operate that software. For the economics and responsibilities of being an Indexer, see the [Indexing Overview](/indexing/overview/). - -## Components - -The modern Indexer stack spans two repositories — the TypeScript [`indexer`](https://github.com/graphprotocol/indexer) (agent + CLI) and the Rust [`indexer-rs`](https://github.com/graphprotocol/indexer-rs) (service + TAP agent): - -| Component | Language | What it does | -| --- | --- | --- | -| **Indexer Agent** | TypeScript | Monitors the network, manages allocations from your indexing rules, submits POIs, runs provision creation, and redeems RAVs on-chain. Owns database migrations. | -| **Indexer Service** (`indexer-service-rs`) | Rust | Answers paid queries: validates [GraphTally](/indexing/indexer-software/graphtally/) receipts, routes queries to Graph Node, and returns attestations. Stateless and horizontally scalable. | -| **Indexer TAP Agent** (`indexer-tap-agent`) | Rust | Aggregates query-fee receipts into Receipt Aggregate Vouchers (RAVs) and prepares them for redemption. Run **exactly one** instance. | -| **Indexer CLI** | TypeScript | Command-line plugin for `graph-cli` to manage rules, allocations, provisions, cost models, and the action queue: `graph indexer ...` | -| **Indexer Common** | TypeScript | Shared library used by the agent and CLI. Not run directly. | - -> `indexer-service-rs` and `indexer-tap-agent` supersede the legacy TypeScript `indexer-service`. From v2.0.0 they require [Graph Horizon](/graph-horizon/overview/) and no longer process legacy V1 receipts. - -All three runtime components — agent, service, and TAP agent — **share the same PostgreSQL database**. Only the Indexer Agent runs migrations against it; the Rust services read and write the same schema but must not run their own migrations. - -## How the pieces fit together - -``` - ┌────────────────────┐ - │ Indexer CLI │ graph indexer ... - │ (graph-cli plugin)│ - └─────────┬──────────┘ - │ management API (:8000) - query + receipt ▼ - ┌──────────┐ ┌─────────────────────┐ ┌────────────────────┐ ┌──────────────────┐ - │ Gateway │──►│ indexer-service-rs │──►│ Graph Node │ │ Network contracts│ - │ (Sender) │ │ validate + route │ │ (index/query) │ │ + subgraphs │ - └──────────┘ └─────────┬───────────┘ └────────────────────┘ └────────┬─────────┘ - │ receipts ▲ - ▼ │ - ┌────────────────────┐ ┌────────────────────┐ │ - │ PostgreSQL (shared)│◄──────►│ indexer-tap-agent │ │ - └─────────┬───────────┘ RAVs │ receipts → RAVs │ │ - │ └────────────────────┘ │ - ▼ │ - ┌────────────────────┐ allocations, POIs, RAV redemption │ - │ Indexer Agent │─────────────────────────────────────┘ - │ reconciliation loop│ - └────────────────────┘ -``` - -## Architecture at a glance - -The **Indexer Agent** runs a **reconciliation loop**: it continuously compares the deployments you *should* be allocated to (per your [indexing rules](/indexing/indexer-software/allocations/indexing-rules/)) against your actual on-chain allocations, and queues the actions needed to close the gap. How much of this runs automatically is controlled by the [operation mode](/indexing/indexer-software/allocations/operation-modes/). - -The **query-fee path** is handled by the Rust services: `indexer-service-rs` validates each incoming GraphTally receipt and serves the query, and `indexer-tap-agent` aggregates those receipts into RAVs. When an allocation closes, the agent redeems the final RAV on-chain. See [GraphTally & Query Fees](/indexing/indexer-software/graphtally/). - -Underneath, the software relies on: - -- **PostgreSQL** — shared by the agent, service, and TAP agent. Stores indexing rules, the action queue, cost models, POI dispute data, and TAP receipts/RAVs. Migrations are owned by the agent (Umzug). -- **Ethereum / Arbitrum** — on-chain transactions for allocations, provisions, and RAV redemption, submitted through the operator wallet. -- **Network Subgraph** — the source of truth for protocol state (deployments, signal, allocations, and Horizon escrow accounts). -- **GraphTally** — The Graph's trust-minimized micropayment system for query fees (formerly TAP). See [GraphTally & Query Fees](/indexing/indexer-software/graphtally/). - -## Graph Horizon support - -The Indexer Software supports [Graph Horizon](/graph-horizon/overview/), the protocol's data-services architecture. Key differences you'll encounter throughout this section: - -- **Provisions** replace the legacy single-stake model. Stake is provisioned to the `SubgraphService` data service. See [Managing Provisions](/indexing/indexer-software/managing-provisions/). -- **New allocation operations** are available: `present-poi` (collect rewards without closing) and `resize` (change allocation size without closing). -- **GraphTally (TAP v2)** uses collection-based aggregation with RAV v2; from `indexer-service-rs`/`indexer-tap-agent` v2.0.0, Horizon is required and V1 receipts are removed. -- The agent runs a **dual-contract system**, supporting legacy and Horizon contracts simultaneously, and detects Horizon-enabled networks automatically. - -Horizon-only commands and options are marked as such throughout these pages. - -## Where to go next - -- [Install and Run](/indexing/indexer-software/install-and-run/) — get the agent, service, and TAP agent running. -- [Managing Allocations](/indexing/indexer-software/allocations/overview/) — the core day-to-day workflow. -- [GraphTally & Query Fees](/indexing/indexer-software/graphtally/) — how you get paid for queries. -- [Reference](/indexing/indexer-software/reference/agent-configuration/) — full agent flags, service/TAP config, and CLI commands. diff --git a/drafts/indexer-software/reference/_meta-titles.json b/drafts/indexer-software/reference/_meta-titles.json deleted file mode 100644 index 0967ef424bce..000000000000 --- a/drafts/indexer-software/reference/_meta-titles.json +++ /dev/null @@ -1 +0,0 @@ -{} diff --git a/drafts/indexer-software/reference/_meta.js b/drafts/indexer-software/reference/_meta.js deleted file mode 100644 index e937e782dd30..000000000000 --- a/drafts/indexer-software/reference/_meta.js +++ /dev/null @@ -1,8 +0,0 @@ -export default { - 'agent-configuration': '', - 'service-tap-configuration': 'Service & TAP Agent Config', - 'cli-reference': 'CLI Command Reference', - 'network-configuration': '', - 'feature-support-matrix': '', - 'error-codes': '', -} diff --git a/drafts/indexer-software/reference/agent-configuration.mdx b/drafts/indexer-software/reference/agent-configuration.mdx deleted file mode 100644 index 5a43861858bb..000000000000 --- a/drafts/indexer-software/reference/agent-configuration.mdx +++ /dev/null @@ -1,118 +0,0 @@ ---- -title: Agent Configuration -sidebarTitle: Agent Configuration ---- - -Full configuration reference for `graph-indexer-agent start`. Every flag has a matching `INDEXER_AGENT_`-prefixed environment variable. For a task-oriented walkthrough, see [Install and Run](/indexing/indexer-software/install-and-run/). - -> This reference reflects the agent's `--help` output. Run `graph-indexer-agent start --help` against your installed version for the authoritative list, as defaults and options change between releases. - -## Indexer infrastructure - -| Flag | Description | Default | -| --- | --- | --- | -| `--indexer-management-port` | Port for the indexer management API. | `8000` | -| `--metrics-port` | Port for Prometheus metrics. | `7300` | -| `--syncing-port` | Port serving the Network Subgraph and other syncing data for the indexer service. | `8002` | -| `--log-level` | Log level. | `debug` | -| `--polling-interval` | Polling interval for data collection (ms). | `120000` | -| `--ipfs-endpoint` | IPFS endpoint for querying manifests. | `https://ipfs.network.thegraph.com` | -| `--enable-auto-graft` | Automatically deploy and sync graft dependencies. See [Auto-Graft](/indexing/indexer-software/auto-graft/). | `false` | -| `--graph-node-query-endpoint` | Graph Node endpoint for querying subgraphs. | *required* | -| `--graph-node-status-endpoint` | Graph Node endpoint for indexing statuses. | *required* | -| `--graph-node-admin-endpoint` | Graph Node endpoint for applying/updating deployments. | *required* | -| `--deployment-management` | Subgraph deployment management mode (`auto` \| `manual`). | `auto` | -| `--public-indexer-url` | Indexer endpoint for receiving requests from the network. | *required* | -| `--indexer-geo-coordinates` | Indexer location (latitude, longitude). | — | -| `--restake-rewards` | Restake claimed rewards; if `false`, rewards go to the wallet. | `true` | -| `--allocation-management` | Allocation automation mode (`auto` \| `manual` \| `oversight`). See [Operation Modes](/indexing/indexer-software/allocations/operation-modes/). | `auto` | -| `--auto-allocation-min-batch-size` | Minimum allocation transactions per batch. | `1` | -| `--auto-allocation-max-batch-size` | Maximum allocation transactions per batch (prevents multicall failures). | — | -| `--enable-auto-migration-support` | Auto-migrate allocations from L1 to L2 (multi-network mode only). | `false` | - -## Postgres - -| Flag | Description | Default | -| --- | --- | --- | -| `--postgres-host` | Postgres host. | *required* | -| `--postgres-port` | Postgres port. | `5432` | -| `--postgres-username` | Postgres username. | `postgres` | -| `--postgres-password` | Postgres password. | `""` | -| `--postgres-database` | Postgres database name. | *required* | -| `--postgres-sslenabled` | Enable Postgres SSL. | `false` | -| `--postgres-pool-size` | Maximum connection pool size. | `50` | - -## Ethereum - -| Flag | Description | Default | -| --- | --- | --- | -| `--network-provider`, `--ethereum` | Ethereum node or provider URL. | *required* | -| `--ethereum-polling-interval` | Provider polling interval (ms). | `4000` | -| `--gas-increase-timeout` | Seconds after which transactions are resubmitted with higher gas. | `240` | -| `--gas-increase-factor` | Factor by which gas is increased on resubmission. | `1.2` | -| `--base-fee-per-gas-max` | Max base fee per gas (gwei). | — | -| `--transaction-attempts` | Max transaction attempts (`0` = unlimited). | `0` | -| `--confirmation-blocks` | Blocks to wait for confirmation. | `3` | -| `--mnemonic` | Operator wallet mnemonic. | *required* | -| `--indexer-address` | Ethereum address of the Indexer. | *required* | -| `--payments-destination` | Address to send payments to; if unset, payments are restaked. | — | - -## Network Subgraph - -| Flag | Description | Default | -| --- | --- | --- | -| `--network-subgraph-deployment` | Network Subgraph deployment. | — | -| `--network-subgraph-endpoint` | Endpoint to query the Network Subgraph. | — | -| `--allocate-on-network-subgraph` | Whether to allocate to the Network Subgraph. | `false` | -| `--epoch-subgraph-deployment` | Epoch Subgraph deployment (for local hosting). | — | - -## TAP Subgraph - -| Flag | Description | -| --- | --- | -| `--tap-subgraph-deployment` | TAP (GraphTally) subgraph deployment. | -| `--tap-subgraph-endpoint` | Endpoint to query the TAP subgraph. | - -## Protocol - -| Flag | Description | Default | -| --- | --- | --- | -| `--epoch-subgraph-endpoint` | Endpoint for the epoch block oracle subgraph. | *required* | -| `--subgraph-max-block-distance` | Blocks a subgraph may lag behind the chain head. See [Subgraph Freshness](/indexing/indexer-software/subgraph-freshness/). | `1000` | -| `--subgraph-freshness-sleep-milliseconds` | Wait before retrying a stale subgraph query. | `5000` | -| `--default-allocation-amount` | Default GRT to allocate to a deployment. | `0.01` | -| `--register` | Whether to register the Indexer on chain. | `true` | -| `--max-provision-initial-size` | Initial SubgraphService provision size (Horizon). See [Managing Provisions](/indexing/indexer-software/managing-provisions/). | `0` | - -## Query fees - -| Flag | Description | Default | -| --- | --- | --- | -| `--rebate-claim-threshold` | Min rebate value (GRT) for a single allocation to be batched. | `1` | -| `--rebate-claim-batch-threshold` | Min total rebate value (GRT) before a batch is claimed. | `5` | -| `--rebate-claim-max-batch-size` | Max rebates per batch. | `100` | -| `--voucher-redemption-threshold` | Min rebate value (GRT) for a single allocation to be redeemed. | `1` | -| `--voucher-redemption-batch-threshold` | Min total value (GRT) before a batch is redeemed. | `5` | -| `--voucher-redemption-max-batch-size` | Max vouchers per batch. | `100` | -| `--gateway-endpoint`, `--collect-receipts-endpoint` | Gateway endpoint base URL. | *required* | - -## Disputes - -| Flag | Description | Default | -| --- | --- | --- | -| `--poi-disputable-epochs` | Past epochs to scan for potential POI disputes. | `1` | -| `--poi-dispute-monitoring` | Monitor the network for potential POI disputes. See [Dispute Monitoring](/indexing/indexer-software/dispute-monitoring/). | `false` | - -## Horizon and other options - -| Flag | Description | -| --- | --- | -| `--offchain-subgraphs` | Subgraphs to index that are not on chain (comma-separated). | -| `--horizon-address-book` | Graph Horizon contracts address book path. | -| `--subgraph-service-address-book` | SubgraphService contracts address book path. | -| `--tap-address-book` | TAP contracts address book path. | -| `--chain-finalize-time` | Seconds the chain takes to finalize blocks. Default `3600`. | - -## Multi-network mode - -Set `INDEXER_AGENT_MULTINETWORK_MODE=true` and provide `--network-specifications-directory` (`--dir`) pointing at a directory of network specification files. In multi-network mode, per-network Ethereum/protocol settings come from those spec files rather than individual flags. diff --git a/drafts/indexer-software/reference/cli-reference.mdx b/drafts/indexer-software/reference/cli-reference.mdx deleted file mode 100644 index 8d159828ace4..000000000000 --- a/drafts/indexer-software/reference/cli-reference.mdx +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: CLI Command Reference -sidebarTitle: CLI Command Reference ---- - -Complete command listing for the Indexer CLI (`graph indexer ...`), a plugin for [`graph-cli`](https://github.com/graphprotocol/graph-cli). This page is the canonical command reference; the task pages linked below explain when and how to use each group. - -> Run `graph indexer --help` (or `graph indexer --help`) against your installed version for the authoritative list. - -## Connecting - -```sh -graph indexer connect http://url.of.indexer-agent:8000/ -``` - -Connects the CLI to the agent's [indexer management API](/indexing/indexer-software/install-and-run/#connecting-the-cli). - -## Status - -| Command | Description | -| --- | --- | -| `indexer status` | Check the status of an Indexer. | - -## Rules - -See [Indexing Rules](/indexing/indexer-software/allocations/indexing-rules/). - -| Command | Description | -| --- | --- | -| `indexer rules get` | Get one or more indexing rules. | -| `indexer rules set` | Set one or more indexing rules. | -| `indexer rules start` (`always`) | Always index a deployment (start indexing if needed). | -| `indexer rules stop` (`never`) | Never index a deployment (stop indexing if needed). | -| `indexer rules maybe` | Index a deployment based on `rules` thresholds. | -| `indexer rules prepare` (`offchain`) | Offchain-index a deployment. | -| `indexer rules clear` (`reset`) | Clear one or more indexing rules. | -| `indexer rules delete` | Remove one or many indexing rules. | - -## Allocations - -See [Direct Commands](/indexing/indexer-software/allocations/direct-commands/). - -| Command | Description | -| --- | --- | -| `indexer allocations get` | List one or more allocations. | -| `indexer allocations create` | Create an allocation. | -| `indexer allocations close` | Close an allocation. | -| `indexer allocations reallocate` | Reallocate to a subgraph deployment. | -| `indexer allocations collect` | Collect receipts for an allocation. | -| `indexer allocations present-poi` | Present POI and collect rewards without closing *(Horizon)*. | -| `indexer allocations resize` | Resize allocation stake without closing *(Horizon)*. | - -## Actions - -See [Action Queue](/indexing/indexer-software/allocations/action-queue/). - -| Command | Description | -| --- | --- | -| `indexer actions get` | List one or more actions. | -| `indexer actions queue` | Queue an action (allocate, unallocate, reallocate, present-poi, resize). | -| `indexer actions approve` | Approve an action item. | -| `indexer actions execute` | Execute approved items in the queue. | -| `indexer actions update` | Update one or more actions. | -| `indexer actions cancel` | Cancel an item in the queue. | -| `indexer actions delete` | Delete one or many actions. | - -## Provision *(Horizon)* - -See [Managing Provisions](/indexing/indexer-software/managing-provisions/). - -| Command | Description | -| --- | --- | -| `indexer provision get` | List provision details. | -| `indexer provision add` | Add stake to the provision. | -| `indexer provision thaw` | Thaw stake from the provision. | -| `indexer provision list-thaw` | List thaw requests. | -| `indexer provision remove` | Remove thawed stake from the provision. | - -## Cost - -See [Cost Models](/indexing/indexer-software/cost-models/). - -| Command | Description | -| --- | --- | -| `indexer cost get` | Get cost models for one or all subgraphs. | -| `indexer cost set model` | Update a cost model. | -| `indexer cost delete` | Remove one or many cost models. | - -## Disputes - -See [Dispute Monitoring](/indexing/indexer-software/dispute-monitoring/). - -| Command | Description | -| --- | --- | -| `indexer disputes get` | Cross-check POIs submitted in the network. | - -## Output format - -Most read commands accept `-o, --output` with `table` (default), `json`, or `yaml`, and allocation commands require `-n, --network`. diff --git a/drafts/indexer-software/reference/error-codes.mdx b/drafts/indexer-software/reference/error-codes.mdx deleted file mode 100644 index e5526b698dc3..000000000000 --- a/drafts/indexer-software/reference/error-codes.mdx +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: Error Codes -sidebarTitle: Error Codes ---- - -The Indexer Agent and Service tag errors with `IE0xx` codes. This page lists every code and its meaning. To isolate a code in your logs: - -```bash -grep | grep IE004 -``` - -If a code points at an unhealthy dependency you can't explain, collect the matching logs and file an issue at [github.com/graphprotocol/indexer](https://github.com/graphprotocol/indexer/issues). - -## Frequently seen codes - -A few codes have detailed guidance worth calling out: - -- **IE004 — Failed to synchronize with network.** The agent can't fetch data from the contracts, the Network Subgraph, the Graph Node status API, or its own database. Isolate which dependency is failing: an unhealthy or rate-limiting Ethereum provider, an unreachable/outdated Network Subgraph endpoint, a Graph Node connectivity problem, or a database issue. Switching provider, fixing connectivity, or upgrading the provider subscription typically resolves it. -- **IE005 — Failed to reconcile indexer and network.** The agent couldn't start/stop deployments, open/close allocations, or claim rebates. Common causes: can't reach Graph Node, allocation transactions failing from lack of ETH, or no free stake to allocate. See also IE013 and IE020. -- **IE013 — Insufficient free stake.** All stake is locked in existing allocations. Reduce allocation amounts and wait for allocations to close and release GRT; it resolves automatically. -- **IE034 — Not authorized as an operator.** The operator address isn't registered for the Indexer. Add the operator address (included in the error message) to your Indexer in Graph Explorer. -- **IE067 — POI not available at current epoch start block.** The deployment is too far behind chain head to resolve a valid POI. Wait for it to sync, or forfeit rewards by force-closing with a zero POI: `graph indexer actions queue unallocate 0 true`. -- **IE068 — Provided POI doesn't match graph-node reference.** Check the subgraph's sync and health; provide a valid POI or use `--force` to bypass POI checks. - -## Full code list - -| Code | Summary | -| --- | --- | -| IE001 | Unable to run database migrations. | -| IE002 | The URL used to connect to Ethereum is invalid. | -| IE003 | Failed to index Network Subgraph. | -| IE004 | Failed to synchronize with network. | -| IE005 | Failed to reconcile indexer and network. | -| IE006 | Failed to cross-check allocation state with contracts. | -| IE007 | Failed to check for network pause. | -| IE008 | Failed to check operator status for indexer. | -| IE009 | Failed to query subgraph deployments worth indexing. | -| IE010 | Failed to query indexer allocations. | -| IE011 | Failed to query claimable indexer allocations. | -| IE012 | Failed to register indexer. | -| IE013 | Failed to allocate: insufficient free stake. | -| IE014 | Failed to allocate: allocation not created on chain. | -| IE015 | Failed to close allocation. | -| IE016 | Failed to claim allocation. | -| IE017 | Failed to ensure default global indexing rule. | -| IE018 | Failed to query indexing status API. | -| IE019 | Failed to query proof of indexing. | -| IE020 | Failed to ensure subgraph deployment is indexing. | -| IE021 | Failed to migrate cost model. | -| IE022 | Failed to identify attestation signer for allocation. | -| IE023 | Failed to handle state channel message. | -| IE024 | Failed to connect to indexing status API. | -| IE025 | Failed to query indexer management API. | -| IE026 | Failed to deploy subgraph deployment (sub-error of IE020). | -| IE027 | Failed to remove subgraph deployment. | -| IE028 | Failed to reassign subgraph deployment. | -| IE029 | Invalid Scalar-Receipt header provided. | -| IE030 | No Scalar-Receipt header provided. | -| IE031 | Invalid Scalar-Receipt value provided. | -| IE032 | Failed to process paid query. | -| IE033 | Failed to process free query. | -| IE034 | Not authorized as an operator for the indexer. | -| IE035 | Unhandled promise rejection (often internal to ethers.js). | -| IE036 | Unhandled error somewhere in the system. | -| IE037 | *(Reserved / undocumented.)* | -| IE038 | *(Reserved / undocumented.)* | -| IE039 | *(Reserved / undocumented.)* | -| IE040 | *(Reserved / undocumented.)* | -| IE041 | Problem looking up Vector transfers for closed allocations (DB). | -| IE042 | A Vector transfer cannot be stored in the database. | -| IE043 | A Vector transfer cannot be marked as resolved in the database. | -| IE044 | Failed to collect query fees on chain. | -| IE045 | Failed to queue transfers for resolving. | -| IE046 | Failed to resolve transfer. | -| IE047 | Failed to mark transfer as failed. | -| IE048 | Failed to withdraw query fees for allocation. | -| IE049 | Failed to clean up transfers for allocation. | -| IE050 | Transaction reverted due to gas limit being hit. | -| IE051 | Transaction reverted for unknown reason. | -| IE052 | Transaction aborted: maximum configured gas price reached. | -| IE053 | Failed to queue receipts for collecting. | -| IE054 | Failed to collect receipts in exchange for query fee voucher. | -| IE055 | Failed to redeem query fee voucher. | -| IE056 | Failed to remember allocation for collecting receipts later. | -| IE057 | Transaction reverted due to failing assertion in contract. | -| IE058 | Transaction failed because nonce has already been used. | -| IE059 | Failed to check latest operator ETH balance. | -| IE060 | Failed to allocate: subgraph is already allocated to. | -| IE061 | Failed to allocate: invalid allocation amount provided. | -| IE062 | Action not executed: contracts paused or operator not authorized. | -| IE063 | Failed to unallocate: no active allocation with provided id. | -| IE064 | Failed to unallocate: allocation created in the current epoch. | -| IE065 | Failed to unallocate: allocation already closed. | -| IE066 | Allocation not created: allocation ID already exists. | -| IE067 | Failed to resolve POI: POI not available at current epoch start block. | -| IE068 | Failed to resolve POI: provided POI doesn't match graph-node reference. | -| IE069 | Failed to query Epoch Block Oracle Subgraph. | -| IE070 | Failed to query BlockHashFromNumber from graph-node. | -| IE071 | Epoch subgraph required for networks whose RPC isn't provided (sub-error of IE069). | diff --git a/drafts/indexer-software/reference/feature-support-matrix.mdx b/drafts/indexer-software/reference/feature-support-matrix.mdx deleted file mode 100644 index 6c7caaace7b9..000000000000 --- a/drafts/indexer-software/reference/feature-support-matrix.mdx +++ /dev/null @@ -1,71 +0,0 @@ ---- -title: Feature Support Matrix -sidebarTitle: Feature Support Matrix ---- - -As described in [GIP-0008](https://snapshot.org/#/council.graphprotocol.eth/proposal/0xbdd884654a393620a7e8665b4289201b7542c3ee62becfad133e951b0c408444), the **Feature Support Matrix** defines which indexing and querying features are experimental or not fully supported for indexing/query rewards and arbitration. The matrix below reflects the canonical Council-ratified version; ratification is required for each update. - -> This page mirrors the matrix maintained in the indexer repository. Treat the source matrix and the accepted `graph-node` version range as authoritative for arbitration purposes. - -## Core features - -| Subgraph feature | Implemented | Experimental | Query arbitration | Indexing arbitration | Indexing rewards | -| --- | --- | --- | --- | --- | --- | -| Full-text Search | Yes | No | No | Yes | Yes | -| Non-Fatal Errors | Yes | Yes | Yes | Yes | Yes | -| Grafting | Yes | Yes | Yes | Yes | Yes | - -## Data source types - -| Network (alias) | Implemented | Experimental | Query arbitration | Indexing arbitration | Indexing rewards | -| --- | --- | --- | --- | --- | --- | -| `eip155:*` (\*) | Yes | No | No | No | No | -| `eip155:1` (mainnet) | Yes | No | Yes | Yes | Yes | -| `eip155:100` (gnosis) | Yes | Yes | Yes | Yes | Yes | -| `near:*` (\*) | Yes | Yes | No | No | No | -| `eip155:42161` (arbitrum-one) | Yes | Yes | Yes | Yes | Yes | -| `eip155:42220` (celo) | Yes | Yes | Yes | Yes | Yes | -| `eip155:43114` (avalanche) | Yes | Yes | Yes | Yes | Yes | -| `eip155:250` (fantom) | Yes | Yes | Yes | Yes | Yes | -| `eip155:137` (polygon) | Yes | Yes | Yes | Yes | Yes | -| `eip155:10` (optimism) | Yes | Yes | Yes | Yes | Yes | -| `eip155:8453` (base) | Yes | Yes | Yes | Yes | Yes | -| `eip155:534352` (scroll) | Yes | Yes | Yes | Yes | Yes | -| `eip155:59144` (linea) | Yes | Yes | Yes | Yes | Yes | -| `eip155:56` (bsc) | Yes | Yes | Yes | Yes | Yes | -| `eip155:7777777` (zora) | Yes | Yes | Yes | Yes | Yes | -| `eip155:1284` (moonbeam) | Yes | Yes | Yes | Yes | Yes | -| `eip155:30` (rootstock) | Yes | Yes | Yes | Yes | Yes | -| `eip155:11155111` (sepolia) | Yes | Yes | Yes | Yes | Yes | -| `eip155:97` (chapel) | Yes | Yes | Yes | Yes | Yes | -| `eip155:130` (unichain) | Yes | Yes | Yes | Yes | Yes | - -`arweave:*` was deprecated in graph-node v0.39.0. - -## Data source features - -| Feature | Implemented | Experimental | Query arbitration | Indexing arbitration | Indexing rewards | -| --- | --- | --- | --- | --- | --- | -| `ipfs.cat` in mappings | Yes | Yes | No | No | No | -| ENS | Yes | Yes | Yes | Yes | Yes | -| File data sources: Arweave | Yes | Yes | No | Yes | Yes | -| File data sources: IPFS | Yes | Yes | No | Yes | Yes | -| Substreams: mainnet | Yes | Yes | Yes | Yes | Yes | -| Substreams: optimism | Yes | Yes | Yes | Yes | Yes | - -## Accepted graph-node version range - -The matrix always specifies an accepted `graph-node` range comprising the latest version and the one immediately preceding it: - -``` -graph-node: >=0.38.0 <=0.44.0 -``` - -## Notes - -- A single matrix currently reflects protocol behaviour for both Ethereum mainnet and Arbitrum One. -- Aliases can be used in subgraph manifests to refer to specific networks. -- Experimental features are generally not fully supported for indexing rewards and arbitration; their use is considered during any arbitration. -- Query fees apply to all queries regardless of the features a subgraph uses. -- Features not named in the matrix are assumed to be fully supported for rewards and arbitration. -- Under [GGP-0057](https://snapshot.box/#/s:council.graphprotocol.eth/proposal/0x4eff14202f6204c0927860a9adff865fce33c32b6cbe7054227457631ee261b9), authority to approve new chain integrations and deprecate chains is delegated to The Graph Foundation, contingent on Technical Advisory Board (TAB) approval; the Council retains override authority. diff --git a/drafts/indexer-software/reference/network-configuration.mdx b/drafts/indexer-software/reference/network-configuration.mdx deleted file mode 100644 index 43a694359e5d..000000000000 --- a/drafts/indexer-software/reference/network-configuration.mdx +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: Network Configuration -sidebarTitle: Network Configuration ---- - -The Indexer Software runs on The Graph Network's mainnet (Arbitrum One) and testnet (Arbitrum Sepolia). This page covers network-specific configuration and testnet onboarding. - -> For the canonical, up-to-date list of which chains are supported for indexing and querying, refer to The Graph's [Supported Networks](/supported-networks/) page and the [Feature Support Matrix](/indexing/indexer-software/reference/feature-support-matrix/). Do not infer chain support from configuration examples alone. - -## Protocol networks - -The `--network` / protocol-network values used across the CLI and agent include `mainnet`, `arbitrum-one`, `sepolia`, and `arbitrum-sepolia`. The Graph Network protocol itself runs on **Arbitrum One** (mainnet) and **Arbitrum Sepolia** (testnet). - -## Mainnet - -Configure the agent with mainnet endpoints and an Arbitrum One protocol network. See the [Agent Configuration reference](/indexing/indexer-software/reference/agent-configuration/) for every flag, and [Deploy the Stack](/indexing/indexer-software/deployment/overview/) for a full Docker-based mainnet deployment. - -## Testnet (Arbitrum Sepolia) - -The Graph Network testnet runs on **Arbitrum Sepolia**. Network information is available at the [testnet explorer](https://testnet.thegraph.com/explorer/network). - -### Registration and funding - -To participate you need Sepolia ETH and testnet GRT: - -1. Join [The Graph Discord](https://thegraph.com/discord/). -2. Get the `@testnetindexer` role in the `#roles` channel. -3. Request testnet GRT in the `#arbi-sepolia-faucet` channel. - -### Staking - -The testnet is open to everyone; the only requirement is a minimum stake of **100k testnet GRT**. You can approve and stake either through [Graph Explorer](https://testnet.thegraph.com/) (Metamask → Arbitrum Sepolia → your profile → Indexing → Stake) or the Contracts CLI: - -```bash -git clone https://github.com/graphprotocol/contracts -cd contracts -npm install && npm run compile - -# Approve GRT to be spent by the staking contract -./cli/cli.ts -m -p \ - contracts graphToken approve --account --amount - -# Stake -./cli/cli.ts -m -p \ - contracts staking stake --amount -``` - -### Setting an operator - -Use a separate operator wallet to send transactions on behalf of your staking wallet. Set it via Graph Explorer (Settings → Operators) or the Contracts CLI: - -```bash -./cli/cli.ts -m -p \ - contracts staking setOperator --operator --allowed true -``` - -## Subgraph freshness per network - -Block-distance defaults were tuned for Arbitrum One. On other networks, adjust `maxBlockDistance` and `freshnessSleepMilliseconds` to the chain's block rate — see [Subgraph Freshness](/indexing/indexer-software/subgraph-freshness/). diff --git a/drafts/indexer-software/reference/service-tap-configuration.mdx b/drafts/indexer-software/reference/service-tap-configuration.mdx deleted file mode 100644 index 6fcbae2b96cd..000000000000 --- a/drafts/indexer-software/reference/service-tap-configuration.mdx +++ /dev/null @@ -1,123 +0,0 @@ ---- -title: Service & TAP Agent Configuration -sidebarTitle: Service & TAP Agent Config ---- - -Configuration reference for the Rust `indexer-service-rs` and `indexer-tap-agent` (the [`indexer-rs`](https://github.com/graphprotocol/indexer-rs) stack). Both binaries take a single shared TOML file via `--config`. For how these components fit into query-fee collection, see [GraphTally & Query Fees](/indexing/indexer-software/graphtally/); for the TypeScript agent's flags, see [Agent Configuration](/indexing/indexer-software/reference/agent-configuration/). - -> Authoritative templates live in the repo: the [minimal config](https://github.com/graphprotocol/indexer-rs/blob/main/crates/config/minimal-config-example.toml) (recommended), the [maximal config](https://github.com/graphprotocol/indexer-rs/blob/main/crates/config/maximal-config-example.toml), and [default values](https://github.com/graphprotocol/indexer-rs/blob/main/crates/config/default_values.toml). - -## Running - -```sh -indexer-service-rs --config /path/to/config.toml -indexer-tap-agent --config /path/to/config.toml -``` - -Both read the same file. `postgres_url` must point at the **same database as `indexer-agent`**, and you must not run migrations from the `indexer-rs` stack — the agent owns migrations. - -## Example configuration - -```toml -[indexer] -indexer_address = "0x1111111111111111111111111111111111111111" -operator_mnemonic = "your twelve word mnemonic phrase here ..." -# For key rotation, specify multiple mnemonics; all are tried when creating -# attestation signers. The first is the primary identity on /info. -# operator_mnemonics = ["previous mnemonic phrase here if you rotated keys"] - -[database] -postgres_url = "postgresql://user:password@localhost:5432/indexer_db" - -[graph_node] -query_url = "http://graph-node:8000" -status_url = "http://graph-node:8000/graphql" - -[subgraphs.network] -# Network Subgraph (includes Horizon escrow data). Prefer local indexing via deployment_id. -query_url = "https://api.thegraph.com/subgraphs/name/graphprotocol/graph-network-arbitrum" -# deployment_id = "Qm..." - -[blockchain] -chain_id = 42161 -receipts_verifier_address_v2 = "0x8f69F5C07477Ac46FBc491B1E6D91E2be0111A9e" -subgraph_service_address = "0xb2Bb92d0DE618878E438b55D5846cfecD9301105" - -[tap] -max_amount_willing_to_lose_grt = "0.1" - -[tap.sender_aggregator_endpoints] -"0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467" = "https://tap-aggregator.network.thegraph.com" - -[horizon] -enabled = true -``` - -Swap the `[blockchain]` and aggregator values for testnet (`chain_id = 421614`, the Arbitrum Sepolia addresses). See the full address tables in [GraphTally & Query Fees](/indexing/indexer-software/graphtally/#blockchain-addresses). - -## Required fields - -| Field | Section | Description | -| --- | --- | --- | -| `indexer_address` | `[indexer]` | Your Indexer's Ethereum address. | -| `operator_mnemonic` | `[indexer]` | BIP-39 mnemonic for the operator wallet. | -| `postgres_url` | `[database]` | PostgreSQL connection URL (same DB as the agent). | -| `query_url` | `[graph_node]` | Graph Node query endpoint. | -| `status_url` | `[graph_node]` | Graph Node status endpoint. | -| `query_url` or `deployment_id` | `[subgraphs.network]` | Network Subgraph endpoint. | -| `chain_id` | `[blockchain]` | Network chain ID (`42161` Arbitrum One, `421614` Arbitrum Sepolia). | -| `receipts_verifier_address_v2` | `[blockchain]` | TAP Verifier contract address. | -| `subgraph_service_address` | `[blockchain]` | SubgraphService contract address. | -| `enabled = true` | `[horizon]` | Horizon mode — required from v2.0.0. | - -## Environment variable overrides - -Any value can be overridden with environment variables, prefixed per binary and using `__` for nested fields: - -```bash -# Pattern: [PREFIX]__[SECTION]__[KEY] (PREFIX: INDEXER_SERVICE or TAP_AGENT) -export INDEXER_SERVICE__DATABASE__POSTGRES_URL="postgresql://..." -export TAP_AGENT__TAP__MAX_AMOUNT_WILLING_TO_LOSE_GRT="0.5" -``` - -## Routes (indexer-service-rs) - -| Route | Description | -| --- | --- | -| `/` | Greeting message. | -| `/info` | Operator's public address. | -| `/healthz` | Dependency health (database + Graph Node); HTTP 200 healthy, 503 otherwise. | -| `/version` | Service version and dependencies. | -| `/subgraphs/id/{id}` | Paid query endpoint; requires a receipt or valid token. | -| `/subgraph/health/{id}` | Subgraph health state. | -| `/status` | Routes to the Graph Node status API. | -| `/cost` | Cost Model GraphQL API. See [Cost Models](/indexing/indexer-software/cost-models/). | -| `/dips` | DIPs (Direct Indexing Payments) GraphQL API. | -| `/escrow` | Escrow subgraph proxy (token-protected). | -| `/network` | Network Subgraph proxy (token-protected). | - -## Logging - -```bash -# Production -export RUST_LOG=indexer_service=info,indexer_tap_agent=info -# Debugging the receipt/RAV lifecycle -export RUST_LOG=indexer_service=debug,indexer_tap_agent=debug -``` - -## Upgrading to v2.0.0 - -v2.0.0 removes legacy V1 receipts; all processing uses Graph Horizon (GraphTally) exclusively. - -- **Horizon is required** — `[horizon].enabled = true`; configs with `enabled = false` are rejected at startup. -- **`receipts_verifier_address_v2` and `subgraph_service_address` are required** under `[blockchain]`. -- **`receipts_verifier_address` (V1) is deprecated** and can be removed. -- **Escrow data comes from the Network Subgraph**, not a separate escrow subgraph; the `[subgraphs.escrow]` section can be removed unless you proxy the escrow subgraph via `serve_escrow_subgraph = true`. -- **Redeem all V1 RAVs before upgrading** — the new version cannot process V1 receipts. - -After updating config and pulling the latest images, restart both services. - -## Deployment - -- **Docker Compose** — run `indexer-service-rs` (ports `7600` query, `7300` metrics) and `indexer-tap-agent` (metrics `7300`, commonly remapped to `7301`) with the config mounted and `RUST_LOG` set. See [Deploy the Stack](/indexing/indexer-software/deployment/overview/). -- **Kubernetes** — the [Graph Launchpad charts](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer) include Helm charts, ConfigMap templates, and Prometheus ServiceMonitors for both services. diff --git a/drafts/indexer-software/subgraph-freshness.mdx b/drafts/indexer-software/subgraph-freshness.mdx deleted file mode 100644 index 5acc8b4e1685..000000000000 --- a/drafts/indexer-software/subgraph-freshness.mdx +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Subgraph Freshness -sidebarTitle: Subgraph Freshness ---- - -The **Subgraph Freshness Checker** improves the reliability of query responses when a subgraph might lag behind the chain head. It compares the subgraph's latest indexed block against the most recent block on the network and, if the gap is too large, retries the query and emits a warning rather than serving stale data. - -## How it works - -If a subgraph is further behind the chain head than an allowed distance, the checker retries the query after a short sleep, logging the current block distance from the chain head. This continues until the subgraph is fresh enough to serve. - -## Configuration - -Two settings control the behavior. They can be set via CLI flags/environment variables or in a network specification file. - -| Option | Description | Default | -| --- | --- | --- | -| `maxBlockDistance` | Acceptable distance, in blocks, between the subgraph's latest indexed block and the chain head. Beyond this, the subgraph is considered stale. | `1000` | -| `freshnessSleepMilliseconds` | How long to wait before retrying a query deemed stale. | `10000` (10s) | - -The corresponding agent flags are `--subgraph-max-block-distance` and `--subgraph-freshness-sleep-milliseconds`. - -### Network specification example - -```yaml -subgraphs: - maxBlockDistance: 5000 - freshnessSleepMilliseconds: 10000 -``` - -## Choosing values per network - -The defaults were established from **Arbitrum One** observations. High-throughput chains produce blocks quickly, so a value tuned for one network may be wrong for another. If the agent or service uses default (Ethereum-oriented) settings on a fast network like Arbitrum, queries may be considered non-fresh indefinitely — the software will warn you when it detects this risk. Adjust `maxBlockDistance` and `freshnessSleepMilliseconds` to match each network's block rate. - -## Disabling the check - -Setting a very high `maxBlockDistance` effectively disables the freshness check, because the distance condition will always pass. diff --git a/drafts/indexer-software/troubleshooting.mdx b/drafts/indexer-software/troubleshooting.mdx deleted file mode 100644 index 92087ce482b1..000000000000 --- a/drafts/indexer-software/troubleshooting.mdx +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: Troubleshooting -sidebarTitle: Troubleshooting ---- - -Common issues when running the Indexer Software and where to look. For coded agent errors (`IE001`, `IE004`, …), see the [Error Codes reference](/indexing/indexer-software/reference/error-codes/). - -## The agent starts but nothing allocates - -- Confirm the [operation mode](/indexing/indexer-software/allocations/operation-modes/). In **MANUAL** mode the reconciliation loop is skipped and [indexing rules](/indexing/indexer-software/allocations/indexing-rules/) have no effect. -- Check your rules: a `global` rule of `never`, or missing thresholds under `decisionBasis: rules`, can mean nothing qualifies. -- In **OVERSIGHT** mode, actions wait in the [action queue](/indexing/indexer-software/allocations/action-queue/) until you approve them. - -## The agent can't sync with the network (`IE004`) - -Usually one of: an unhealthy or rate-limiting Ethereum provider, an unreachable or outdated Network Subgraph endpoint, an unreachable Graph Node status API, or a database connection problem. Isolate which dependency is failing from the error logs. See [Error Codes](/indexing/indexer-software/reference/error-codes/) for the full breakdown. - -## Database migration failures (`IE001`) - -The agent logs the underlying error that caused the migration to fail. Check database connectivity and permissions, and review the logged cause. Migration commands are listed in [Install and Run](/indexing/indexer-software/install-and-run/#database-migrations). - -## Grafted subgraphs won't deploy their dependencies - -Confirm auto-graft is enabled and the IPFS endpoint is reachable. See the [Auto-Graft troubleshooting table](/indexing/indexer-software/auto-graft/#troubleshooting). - -## Query fees aren't being collected or redeemed - -If receipts aren't aggregating into RAVs or RAVs aren't redeeming, confirm exactly one `indexer-tap-agent` is running, that it and `indexer-service-rs` share the agent's database, and that `[horizon].enabled = true` with the v2 verifier and SubgraphService addresses set. See the [GraphTally troubleshooting table](/indexing/indexer-software/graphtally/#troubleshooting). - -## Queries are always considered stale - -On fast chains, the default `maxBlockDistance` may be too small. Tune the [Subgraph Freshness](/indexing/indexer-software/subgraph-freshness/) settings for the network. - -## Filtering logs - -The agent tags errors with codes. To isolate a specific error: - -```bash -grep | grep IE004 -``` - -## Getting help - -If a Network Subgraph endpoint appears reachable but is misbehaving, collect the relevant error logs and file an issue at [github.com/graphprotocol/indexer](https://github.com/graphprotocol/indexer), or ask in [The Graph Discord](https://thegraph.com/discord/). From e94f259cc51ae4584e45d1ab01ad815ec7553b30 Mon Sep 17 00:00:00 2001 From: Brandon Kramer Date: Mon, 13 Jul 2026 13:43:58 -0400 Subject: [PATCH 6/7] cleaned up indexer docs section --- nginx.conf | 6 +++--- website/next.config.js | 2 +- website/route-lockfile.txt | 6 +++--- website/src/HomePage.tsx | 10 ++++++++-- website/src/pages/en/indexing/_meta.js | 6 +++--- website/src/pages/en/indexing/tooling/_meta.js | 5 +++++ 6 files changed, 23 insertions(+), 12 deletions(-) create mode 100644 website/src/pages/en/indexing/tooling/_meta.js diff --git a/nginx.conf b/nginx.conf index e7cc008f9575..54158f86d736 100644 --- a/nginx.conf +++ b/nginx.conf @@ -107,9 +107,9 @@ http { rewrite ^/docs/en/developing/supported-networks/$ $scheme://$http_host/docs/en/supported-networks/ permanent; rewrite ^/docs/en/developing/unit-testing-framework/$ $scheme://$http_host/docs/en/subgraphs/tooling/unit-testing-framework/ permanent; rewrite ^/docs/en/explorer/$ $scheme://$http_host/docs/en/subgraphs/existing-subgraphs/explorer/ permanent; - rewrite ^/docs/en/firehose/$ $scheme://$http_host/docs/en/indexing/firehose/ permanent; + rewrite ^/docs/en/firehose/$ $scheme://$http_host/docs/en/indexing/tooling/firehose/ permanent; rewrite ^/docs/en/glossary/$ $scheme://$http_host/docs/en/resources/glossary/ permanent; - rewrite ^/docs/en/graphcast/$ $scheme://$http_host/docs/en/indexing/graphcast/ permanent; + rewrite ^/docs/en/graphcast/$ $scheme://$http_host/docs/en/indexing/tooling/graphcast/ permanent; rewrite ^/docs/en/indexing/$ $scheme://$http_host/docs/en/indexing/overview/ permanent; rewrite ^/docs/en/managing/delete-a-subgraph/$ $scheme://$http_host/docs/en/subgraphs/developing/managing/deleting-a-subgraph/ permanent; rewrite ^/docs/en/managing/deprecate-a-subgraph/$ $scheme://$http_host/docs/en/subgraphs/developing/managing/deleting-a-subgraph/ permanent; @@ -122,7 +122,7 @@ http { rewrite ^/docs/en/network/explorer/$ $scheme://$http_host/docs/en/subgraphs/existing-subgraphs/explorer/ permanent; rewrite ^/docs/en/network/indexing/$ $scheme://$http_host/docs/en/indexing/overview/ permanent; rewrite ^/docs/en/new-chain-integration/$ $scheme://$http_host/docs/en/indexing/new-chain-integration/ permanent; - rewrite ^/docs/en/operating-graph-node/$ $scheme://$http_host/docs/en/indexing/graph-node/ permanent; + rewrite ^/docs/en/operating-graph-node/$ $scheme://$http_host/docs/en/indexing/tooling/graph-node/ permanent; rewrite ^/docs/en/publishing/publishing-a-subgraph/$ $scheme://$http_host/docs/en/subgraphs/developing/deploying-publishing/publishing-a-subgraph/ permanent; rewrite ^/docs/en/querying/graph-client/README/$ $scheme://$http_host/docs/en/subgraphs/querying/graph-client/README/ permanent; rewrite ^/docs/en/querying/graph-client/architecture/$ $scheme://$http_host/docs/en/subgraphs/querying/graph-client/architecture/ permanent; diff --git a/website/next.config.js b/website/next.config.js index c1b8a7841dce..9631434857c8 100644 --- a/website/next.config.js +++ b/website/next.config.js @@ -73,7 +73,7 @@ const withNextra = nextra({ }, indexing: { type: 'children', - title: 'Indexer Tooling', + title: t('global.navigation.indexing'), }, '---5': { type: 'separator', diff --git a/website/route-lockfile.txt b/website/route-lockfile.txt index 8ea5708db956..9fb5bce7cf92 100644 --- a/website/route-lockfile.txt +++ b/website/route-lockfile.txt @@ -8,13 +8,13 @@ /en/graph-horizon/overview/ /en/graph-horizon/what-changes/ /en/indexing/chain-integration-overview/ -/en/indexing/firehose/ -/en/indexing/graph-node/ -/en/indexing/graphcast/ /en/indexing/new-chain-integration/ /en/indexing/overview/ /en/indexing/supported-network-requirements/ /en/indexing/tap/ +/en/indexing/tooling/firehose/ +/en/indexing/tooling/graph-node/ +/en/indexing/tooling/graphcast/ /en/resources/benefits/ /en/resources/glossary/ /en/resources/roles/curating/ diff --git a/website/src/HomePage.tsx b/website/src/HomePage.tsx index 9bac8230797f..e14b1bb8f44b 100644 --- a/website/src/HomePage.tsx +++ b/website/src/HomePage.tsx @@ -128,7 +128,9 @@ export default function HomePage({ supportedNetworks }: { supportedNetworks: Sup title={t('index.products.graphNode.title')} description={t('index.products.graphNode.description')} cta={ - {t('index.products.graphNode.cta')} + + {t('index.products.graphNode.cta')} + } icon={
@@ -139,7 +141,11 @@ export default function HomePage({ supportedNetworks }: { supportedNetworks: Sup {t('index.products.firehose.cta')}} + cta={ + + {t('index.products.firehose.cta')} + + } icon={
diff --git a/website/src/pages/en/indexing/_meta.js b/website/src/pages/en/indexing/_meta.js index 78e198dda138..8a2b538a1fbd 100644 --- a/website/src/pages/en/indexing/_meta.js +++ b/website/src/pages/en/indexing/_meta.js @@ -1,8 +1,8 @@ +import titles from './_meta-titles.json' + export default { overview: '', - firehose: '', - 'graph-node': '', - graphcast: 'GraphCast', + tooling: titles.tooling ?? '', tap: 'GraphTally for Indexers', 'supported-network-requirements': 'Supported Networks and Node Requirements', 'new-chain-integration': '', diff --git a/website/src/pages/en/indexing/tooling/_meta.js b/website/src/pages/en/indexing/tooling/_meta.js new file mode 100644 index 000000000000..f7082f09b4e6 --- /dev/null +++ b/website/src/pages/en/indexing/tooling/_meta.js @@ -0,0 +1,5 @@ +export default { + firehose: '', + 'graph-node': '', + graphcast: 'GraphCast', +} From 46783470ef56e63fd7326b40ee607c3c9b310612 Mon Sep 17 00:00:00 2001 From: benface Date: Tue, 14 Jul 2026 10:14:26 -0400 Subject: [PATCH 7/7] Clean up --- website/next.config.js | 6 +++--- website/route-lockfile.txt | 4 ++++ 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/website/next.config.js b/website/next.config.js index 9631434857c8..88e5e9cbbf37 100644 --- a/website/next.config.js +++ b/website/next.config.js @@ -54,21 +54,21 @@ const withNextra = nextra({ type: 'separator', }, 'ai-overview': 'AI Tooling', - '---1b': { + '---2': { type: 'separator', }, subgraphs: { type: 'children', title: t('global.navigation.subgraphs'), }, - '---2': { + '---3': { type: 'separator', }, substreams: { type: 'children', title: t('global.navigation.substreams'), }, - '---3': { + '---4': { type: 'separator', }, indexing: { diff --git a/website/route-lockfile.txt b/website/route-lockfile.txt index 9fb5bce7cf92..56b6947927d2 100644 --- a/website/route-lockfile.txt +++ b/website/route-lockfile.txt @@ -87,6 +87,8 @@ /en/substreams/developing/solana/account-changes/ /en/substreams/developing/solana/transactions/ /en/substreams/overview/ +/en/substreams/providers/the-graph-market/ +/en/substreams/public-substreams/substreams-dev/ /en/substreams/publishing/ /en/substreams/quick-start/ /en/substreams/tooling/skills/ @@ -143,6 +145,7 @@ /en/supported-networks/mainnet/ /en/supported-networks/matic/ /en/supported-networks/mbase/ +/en/supported-networks/megaeth/ /en/supported-networks/monad-testnet/ /en/supported-networks/monad/ /en/supported-networks/moonbeam/ @@ -157,6 +160,7 @@ /en/supported-networks/polygon-amoy/ /en/supported-networks/polygon-zkevm-cardona/ /en/supported-networks/polygon-zkevm/ +/en/supported-networks/robinhood/ /en/supported-networks/rootstock-testnet/ /en/supported-networks/rootstock/ /en/supported-networks/scroll-sepolia/