GraphTally: Enabling Trust-Minimized Micropayments for Decentralized Networks
TL;DR
GraphTally is a high-throughput, trust-minimized micropayment system designed for decentralized networks. It enables fast, efficient, and cost-effective payments for Indexers handling large query volumes. Using a one-way payment channel model, GraphTally removes the need for dispute windows, ensuring seamless transactions between Senders and Receivers. The system leverages a trust minimized solution to maintain secure on-chain settlement while keeping operational costs low. As web3 infrastructure advances, GraphTally provides a scalable payment solution for decentralized services, bridging blockchain data access with next-generation protocols.
Blockchains are evolving. In the early days of crypto, excitement centered around simple, trustless, cheap, human-to-human payments. With the introduction of smart contracts and high-speed blockchains, a new future is emerging —one where machines interact trustlessly within blockchain protocols. Machines can exchange vast amounts of information far faster than humans, and when participating in blockchain networks, they require efficient payment mechanisms for the work they perform.
The Graph foresaw this challenge early on: Indexers participating in The Graph’s decentralized network needed a scalable way to receive payments for the millions of queries they serve. This led to the creation of GraphTally, a high-throughput, trust-minimized micro-payment solution that enables machines participating in the next generation of blockchain protocols to get paid.
GraphTally, built by Semiotic Labs, is a micropayments solution designed to create trust-minimized payment channels for decentralized networks. Built to optimize efficiency and security, GraphTally allows network participants to exchange value seamlessly while preserving decentralization.
The Need for Efficient, Low-Cost Payments in Web3
The Graph is a decentralized blockchain protocol that enables indexing and querying blockchain data. Indexers form the backbone of the protocol, indexing blockchain data based on consumer specifications and then responding to consumer query requests on that data. Like all blockchain networks, The Graph relies on crypto-economic incentives to maintain and grow its ecosystem. So how are Indexers compensated for serving data?
In The Graph ecosystem, Indexers receive payment for each query they serve, with query pricing determined by gateways. The Graph aims to support all queries for blockchain data across any blockchain. This means that an Indexer receives a lot of queries. As of today, the most active Indexers see about 500,000 queries per day and that number will continue to increase as the need for web3 data continues to grow. The Graph needs a payment solution that ensures Indexers are appropriately paid for each query they serve. The solution needs to support a high volume of payments.
A straightforward approach might involve consumers submitting blockchain transactions to transfer funds to Indexers for each query. However, even on low-cost networks like , a simple ETH transfer costs approximately . At a rate of 500K queries per day, an Indexer would lose around $45,000 in fees alone—making this method impractical. Instead, an off-chain payment solution with cost-efficient on-chain settlement is required.
The One-Way Payment Channel Solution
Payment (and state) channels provide a viable alternative. These protocols work by having two parties exchange signed messages agreeing on the current state. Whenever a party wants to end a session (settle), they post the latest signed message to the settlement chain. The primary overhead cost of the protocol is the verification of a single signed message. What happens if the party initiating the settlement posts a signed message that isn’t actually the latest state? Most payment channels solve this by requiring a period of time which gives the other party a chance to dispute.
However, The Graph’s use case simplifies this process: payments only flow in one direction—from a gateway (Sender) to an Indexer (Receiver). This arrangement removes the need for a dispute window as Receivers have a financial incentive to post the latest agreed-on payment amount to maximize earnings. As long as the payments are validly signed by the Sender, then there is no need for a dispute window. This arrangement is called a One-way Payment Channel.
Another key requirement for The Graph is that Senders are stateless. This is to support highly scalable, distributed Senders. Imagine a use-case where a protocol uses geographically-distributed servers. In this case, the individual servers might not be able to efficiently communicate with each other to agree on the total amount owed to a Receiver. The Receiver might receive conflicting signed messages for the amount owed. One solution for this is to have the Sender sign a message for the amount owed for a single query, rather than the total accumulated amount owed, and let the Receiver tally the total on their side.
The challenge then becomes how the Receiver can prove the total amount owed without incurring excessive on-chain costs. Posting and verifying all signed messages on-chain is prohibitively expensive due to high call data and signature verification costs. Various solutions, including for batch-proven signature verification, were explored. Ultimately, a more straightforward approach was implemented. By allowing minimal communication between the Sender and Receiver and making slight trust assumptions, the protocol achieves a secure, high-throughput, stateless, one-way payment channel. Using well-established cryptographic primitives (ECDSA), this design effectively scales to meet the demands of modern data infrastructure while maintaining security and efficiency.
GraphTally Architecture: Stateless and Trust-Minimized Payments
The high-level architecture of GraphTally is simple: there are Senders and Receivers. Senders sign messages indicating an amount owed to the Receiver for a specific request, called Receipts. Receivers verify the Receipts, store them, and accumulate the total amount owed.
As indicated above, the Receivers need a way to efficiently prove, on-chain, the total amount owed by the Sender. To achieve this, the Receiver specifies an amount they are willing to risk losing and once the total amount owed reaches this threshold they send a request for a single signed message for the total amount owed back to the Sender. Included in this request are all of the Sender signed Receipts which add up to the total amount owed. The Sender verifies all of the Receipts, computes the total owed, and signs and returns a message with this total; we call this message a Receipt Aggregate Voucher (RAV). Note that the Sender might be offline or choose not to respond to the Receivers request, in which case the Receiver will stop doing business with the Sender and will be unable to claim the amount owed according to their threshold. To ensure successful RAV requests, the Receiver needs to set the threshold according to the trustworthiness of the Sender.
A RAV can be used to claim the total amount owed on-chain, but Receivers may choose to request multiple RAVs and accumulate them before submitting an on-chain transaction. To allow for this, Receivers can send the last unclaimed RAV they received along with the Receipts back to the Sender. The Sender verifies the RAV and the Receipts, adds the accumulated Receipt value to the RAV, and returns an updated RAV. Timestamps prevent double-spending, as Receipts are only added to a RAV if their timestamp is later than the previous RAV’s timestamp. The updated RAV includes the latest timestamp from the batch.
The figure below details how Receipts are sent, batched, and the RAV request flow. The Sender is continuously signing and sending Receipts for every request. The Receiver is verifying and accumulating the Receipt values. Once the value threshold is reached, the Receiver requests a RAV by sending all Receipts received up to a timestamp in a batch (🟩). After the initial RAV request, the Sender requests an updated RAV by sending the previous RAV along with all the Receipts with a timestamp after the initial RAVs timestamp (🟦). This process continues until the Receiver is ready to submit a claim, on-chain, using the latest RAV they have received.
Why GraphTally Works: Performance, Scalability, and Low Costs
This solution meets all predefined requirements:
- High-throughput: The bottleneck is the time to sign and verify ECDSA signatures, one of the fastest cryptographic operations.
- Stateless and scalable: Senders do not need to track amounts owed.
- Trust-minimized: Receivers configure a threshold to maintain the channel and can claim owed amounts on-chain without further interaction from the Sender.
- Cost efficiency: The major on-chain cost is verifying a single ECDSA signature (~3,000 gas). As of this writing, redemptions cost ~, approximately $0.015.
Smart Contracts: Verifiable, Secure Fund Allocation
Smart contracts play a critical role in:
- Verifying RAVs to ensure valid settlements.
- Transferring funds from Senders to Receivers.
- Allocating funds securely by locking payments in escrow for valid RAV submissions.
Senders can withdraw their funds, but withdrawal requires a thawing period. This is to allow Receivers enough time to claim any outstanding RAVs.
A Scalable Payment Solution for Decentralized Networks
GraphTally’s architecture is uniquely positioned to enable decentralized micro-payments with massive throughput. As web3 continues to evolve, an increasing number of protocols require fast, decentralized services operating at web2 speeds. Agents, solvers, and data availability providers must ensure reliable payment systems for network nodes. GraphTally enables seamless, scalable payments in this new paradigm.
If you are building one of these protocols and would like to learn more about how to integrate GraphTally, !
About The Graph
is the source of data and information for the decentralized internet. As the original decentralized data marketplace that introduced and standardized subgraphs, The Graph has become web3’s method of indexing and accessing blockchain data. Since its launch in 2018, tens of thousands of developers have for dapps across 90+ blockchains - including Ethereum, Solana, Arbitrum, Optimism, Base, Polygon, Celo, Fantom, Gnosis, and Avalanche.
Discover more about how The Graph is shaping the future of decentralized physical infrastructure networks (DePIN) and stay connected with the community. Follow The Graph on , , , , , and . Join the community on The Graph’s , join technical discussions on The Graph’s .
oversees The Graph Network. The Graph Foundation is overseen by the . , , , , , and are seven of the many organizations within The Graph ecosystem.
