Skip to main content

Payments

Dispatch uses GraphTally (TAP v2) — the same payment infrastructure used by The Graph’s SubgraphService. GRT moves off-chain per request via signed receipts, then settles on-chain in batches.

End-to-end flow

valueAggregate in a RAV is cumulative and never resets. Each collect() call computes the delta from the last collected value. This means a lost RAV doesn’t lose funds — the next RAV covers the gap.

EIP-712 domain

All receipts and RAVs are signed against this domain on Arbitrum One:
The data_service field in every receipt is set to RPCDataService’s address, preventing cross-service receipt replay.

CU-weighted pricing

Request value is proportional to compute units (CUs) — a weight assigned per method. Receipt value = CU x base_price_per_cu. Default base_price_per_cu is 4_000_000_000_000 GRT wei (~$40/million requests at $0.09 GRT).

TAP receipt overhead

Receipt processing must not slow down requests. In practice:

Data service fee cut

On each collect(), RPCDataService takes a 2% cut from the fees routed through it: The remaining 98% flows to the provider’s paymentsDestination.

Stake locking

On each collect(), RPCDataService locks fees x stakeToFeesRatio in a stake claim via DataServiceFees._createStakeClaim(). The claim releases after thawingPeriod. This ensures providers maintain sufficient economic stake relative to fees collected. Default stakeToFeesRatio is 5 — consistent with SubgraphService.

Payments destination

The GRT recipient on collect() is paymentsDestination[serviceProvider], not necessarily the provider’s staking address. Providers can separate their operator key from their payment wallet via setPaymentsDestination(address). Defaults to the provider address on registration.