Chainstack

• Name: Chainstack
• URL: https://chainstack.com/
• Category: blockchain RPC infrastructure / node hosting / self-hosted and managed developer control plane company
• Tags: ethereum-ecosystem solana-ecosystem
• Summary: Chainstack belongs as an entity note, not a protocol note. The useful object is the named operator running a broad chain-access control plane across hosted endpoints, region and cloud placement, archive and debug access, self-hosted management surfaces, and now explicit AI-agent tooling. The leverage comes from what Chainstack chooses to expose, where it exposes it, and how much of a team’s operational path settles around Chainstack-specific defaults.
• What it does:
  • Provides managed blockchain node access across many networks through global, dedicated, archive, and specialized offerings
  • Publishes chain-by-chain region and feature matrices, including support details like archive or debug access
  • Offers self-hosted deployment and management alongside hosted cloud infrastructure
  • Markets AI-agent-facing surfaces including MCP support and llms.txt documentation indexing
• Key claims:
  • The homepage and docs position Chainstack as a broad multi-chain infrastructure platform rather than a simple endpoint reseller
  • The docs expose a detailed per-network matrix for regions, cloud providers, node modes, and feature support, which is one of the clearer operational signals in the note
  • The AI-agents page and llms.txt feed show that Chainstack is deliberately trying to become agent-friendly infrastructure, not just retrofitting a marketing page
  • The GitHub organization reinforces the control-plane framing with public tooling, portal, MCP, and example repos
• Whitepaper: No canonical Chainstack whitepaper or litepaper surfaced in this pass. The clearest primary sources remain the official site, docs portal, AI-agent materials, llms.txt, and Chainstack Labs GitHub references already collected in ../whitepapers/chainstack-primary-sources-2026-04-27.md.
• Sources:
  • https://chainstack.com/
  • https://docs.chainstack.com/docs/platform-introduction.md
  • https://docs.chainstack.com/docs/nodes-clouds-regions-and-locations.md
  • https://docs.chainstack.com/llms.txt
  • https://chainstack.com/blockchain-rpc-nodes-for-ai-agents/
  • https://github.com/chainstacklabs

Internal linkages

• Legacy project-layer alias kept for old links: chainstack.
• Best operator-platform contrasts: alchemy, quicknode, and drpc.
• Reusable lens: the important dependency is on hosted placement, capability exposure, and workflow defaults, not on raw endpoint resale.

Protocol / company boundary

• Keep chainstack only as an alias so legacy links keep resolving without pretending there is a separate Chainstack protocol layer doing useful analytical work.
• This company note is the real object: hosted endpoint placement, cloud and region exposure, archive/debug feature policy, self-hosted management surfaces, and the newer AI-agent tooling all sit under one named operator boundary.
• That split matters because the question is not what protocol is Chainstack? but which company controls the easiest multichain access and operations path many teams inherit by default?

Control surface

• Authority sits in credentials, rate limits, region placement, cloud choice, chain support, archive and debug availability, and the agent-facing interfaces layered on top.

• Chainstack matters because those defaults shape how developers and agents reach chains even when the underlying protocols are elsewhere.

• Read it as a company-run chain-access and node-operations shell, not as a protocol peer.

• Last reviewed: 2026-08-10 UTC