Summary: Graph Tally (formerly TAP, Timeline Aggregation Protocol) is best understood not as generic API billing or a simple payment channel, but as a trust-minimized settlement rail for decentralized data services. Its core mechanism is the split between stateless payer-side gateways that issue per-query signed receipts, receiver-side indexers that accumulate those receipts, an aggregation step that rolls them into a signed Receipt Aggregate Voucher (RAV), and onchain escrow redemption after an allocation closes. That makes it a useful comparison class for x402, L402, and machine-payments protocols: those systems focus on request authorization and paid API access, while Graph Tally makes the payer gateway, aggregation authority, credit threshold, replay protection, and final escrow settlement explicit inside a high-volume query market.
What it does:
Lets gateways pay indexers per query using signed offchain receipts instead of one onchain transaction per request
Aggregates many receipts into a single Receipt Aggregate Voucher (RAV) that can be redeemed onchain from gateway escrow
Uses allocation IDs, timestamps, and EIP-712 signatures to bind receipts and RAVs to specific service periods and prevent replay or double-claiming
Integrates with The Graph’s indexer stack and Graph Horizon’s broader data-service framework
Exposes configurable credit-risk and operations knobs such as sender aggregator endpoints and max_amount_willing_to_lose_grt
Positions the same payments primitive for broader data services beyond subgraphs, including other query- and data-serving markets
Key claims:
The central analytical move is to separate request serving from settlement. Gateways can stay stateless and sign one receipt per request, while indexers bear temporary aggregation and storage work and later redeem a single aggregate claim onchain.
The receipt-to-RAV lifecycle is the main reusable primitive. Receipts record per-query debt; RAVs compress that debt into one redeemable voucher; escrow plus an onchain verifier turn the aggregate back into settlement.
Allocation-scoped validity is important because it shows where replay protection and accounting boundaries live. A receipt is not a generic IOU; it is bound to a specific sender and a specific allocation window.
The official docs and GraphTally blog make the trust model unusually legible: indexers choose how much unaggregated value they are willing to risk, gateways or their aggregators must answer RAV requests, and thawing periods on escrowed funds protect outstanding claims. That is more analytically useful than generic micropayments rhetoric.
Graph Horizon broadens the importance of the protocol. Graph Tally is not only for subgraph queries; it is positioned as a reusable payments substrate for arbitrary data services, which could move the same control surface into oracle, agent, or other machine-query markets.
The main remaining choke point is the gateway / aggregator layer. Even with cryptographic receipts, practical power still sits with payer onboarding, signer rotation, aggregator reliability, sender balance management, and escrow operations.
Graph Tally belongs in the active corpus because it cleanly separates request authorization, metered service delivery, receipt accumulation, aggregation authority, and final settlement. If it stayed folded into a generic The Graph label, that lower-layer machine-payment mechanism would be easy to miss.
Whitepaper: No canonical standalone Graph Tally PDF surfaced in this pass. The strongest primary materials were The Graph’s official GraphTally docs and blog post, the official graph-tally repository README, and GIP-0054 / GIP-0066. See ../whitepapers/graph-tally-primary-sources-2026-05-11.md.