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: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 eachcollect(), RPCDataService takes a 2% cut from the fees routed through it:
The remaining 98% flows to the provider’s
paymentsDestination.
Stake locking
On eachcollect(), 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 oncollect() 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.