Tatum company primary sources — 2026-08-09

Project status in this pass

• This pass was for a taxonomy split: keep projects/tatum.md on the product surface and add companies/tatum.md for the named operator boundary.
• No standalone company whitepaper is the important artifact here.
• The decisive primary materials were the current homepage plus the docs pages that make Tatum’s account-linked API keys, plan limits, gateway routing workflow, and KMS queueing model explicit.

Primary-source snapshots

1) Homepage

• URL: https://tatum.io/
• Key excerpt:
  • Tatum frames itself as Enterprise-Grade Blockchain Infrastructure.
  • The homepage says developers get a unified abstraction layer, API's, RPC's and access to all blockchains.
  • The same page still presents Tatum as one platform for blockchain applications rather than as a single narrow RPC product.

2) Docs overview

• URL: https://docs.tatum.io/
• Key excerpt:
  • The docs homepage says developers get a unified abstraction layer to access all blockchains.
  • It groups RPC Nodes, Indexed Block Data, Real-Time Blockchain Alerts, Fee Estimation, Virtual Accounts, and Secure Key Management under one platform surface.
  • This is the clearest first-party summary that the useful question is about one company-run stack rather than one isolated feature.

3) Authentication & Security

• URL: https://docs.tatum.io/docs/authentication
• Key excerpt:
  • The docs say Tatum REST API and SDK usage requires an API key.
  • They say API keys are bound to a Tatum account and a pricing plan, and those bindings define requests per second plus monthly request volume.
  • The page routes users through the Tatum Dashboard to create and manage those keys.

4) Plans & Limits

• URL: https://docs.tatum.io/docs/plans-limits
• Key excerpt:
  • The plans page says the free plan includes 2 API keys, 100K credits, and 3 requests per second.
  • Paid plans raise credit and rate ceilings through the same account and dashboard shell.
  • This matters because throughput and access policy are company-issued, not neutral background conditions.

5) RPC Gateway

• URL: https://docs.tatum.io/docs/rpc-gateway
• Key excerpt:
  • Tatum describes RPC Gateway as middleware in front of a node pool that handles routing, failover, and consistency.
  • The page explicitly points users to dashboard-managed Gateway creation, custom gateways, bring-your-own-RPC, routing strategies, and powerups.
  • This is strong evidence that Tatum wants to own request-path policy and operational reliability, not only expose raw nodes.

6) KMS

• URL: https://docs.tatum.io/docs/tatum-key-management-system-kms
• Key excerpt:
  • The KMS docs describe a self-custodial local-signing tool for custodial blockchain applications.
  • They say KMS periodically pulls pending transactions to sign from Tatum Cloud, signs them locally using stored private keys, and broadcasts them.
  • The same page stresses that Tatum does not store the private keys or mnemonics.
  • That combination is exactly why the split matters: signing may stay local, but transaction origination and workflow publication can still remain Tatum-shaped.

7) Docs index / llms.txt

• URL: https://docs.tatum.io/llms.txt
• Key excerpt:
  • The docs index exposes pages for authentication, API-key management, plans and limits, routing strategies, custom gateways, and KMS under one documentation tree.
  • It also shows how much of the platform is account, routing, and workflow management rather than only endpoint access.

Working conclusion

Tatum clears the bar for a company/entity split because the useful question is not only what blockchain APIs or RPC endpoints exist? It is which named operator issues the credentials, ties them to plans and rate limits, shapes routing and failover policy, publishes the pending transactions KMS consumes, and becomes the default workflow shell for multichain application operations? That is a company-layer control surface, not only a product description.