feat: on-chain acceptance fixes for DIPs recurring agreements#1178
Open
MoonBoi9001 wants to merge 21 commits intofeat/dips-on-chain-cancelfrom
Open
feat: on-chain acceptance fixes for DIPs recurring agreements#1178MoonBoi9001 wants to merge 21 commits intofeat/dips-on-chain-cancelfrom
MoonBoi9001 wants to merge 21 commits intofeat/dips-on-chain-cancelfrom
Conversation
This squashed commit adds support for DIPs (Distributed Indexing Payments), which allows indexers to receive indexing fees for indexing subgraphs requested via the DIPs system. Key changes: - Add 'dips' as a new IndexingDecisionBasis enum value - Add indexing agreements model and database support - Add DIPs client for interacting with the gateway DIPs service - Support for matching DIPs agreements with allocations - Allow actions on deployments that are not published yet (for DIPs) - Update allocation management to handle DIPs-based allocations - Add proper handling for cancelled agreements Co-authored-by: Multiple contributors from the DIPs development team
- Updated all DIPs-related code to use ethers v6 API - Migrated from BigNumberish to bigint for all numeric operations - Fixed provider and signer initialization patterns - Updated test suite to use new ethers v6 patterns - Removed temporary migration documentation 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
- Add DipsReceipt model with snake_case fields matching database conventions - Update DipsCollector to store Receipt IDs instead of TAP receipts - Implement GetReceiptById polling in collectAllPayments method - Update to @graphprotocol/dips-proto 0.3.0 for new proto definitions - Remove TAP receipt dependencies from DIPs payment flow - Add comprehensive logging for payment status transitions This completes the indexer-agent implementation for the new DIPs Safe payment system, replacing TAP receipts with an asynchronous Receipt ID based approach. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
The third DIP commit changed tryCollectPayment to use receipt-based responses (receiptId, amount) but the test still mocked the old tapReceipt-based response shape. Also regenerates yarn.lock with new DIP dependencies.
When generating allocation IDs for new DIP allocations, closed/stopped allocations still exist on-chain. The uniqueAllocationID function only knows about active allocations, so it can generate the same ID as a previously closed allocation. Add a retry loop that queries on-chain state and excludes colliding IDs before retrying.
Maikol
approved these changes
Mar 12, 2026
Rewarded subgraphs use defaultAllocationAmount (or per-deployment rule), denied subgraphs use dipsAllocationAmount (default changed to 0 for altruistic allocations immune to force-close).
Add a filtered query method to PendingRcaConsumer so cleanupDipsRule doesn't re-fetch all proposals. Hoist duplicated createMockAllocation to top level in tests.
MoonBoi9001
changed the title
MoonBoi9001
force-pushed
the
fix/getrewards-subgraph-service
branch
2 times, most recently
from
eb58bc9 to
3c2f23f
Compare
MoonBoi9001
force-pushed
the
fix/getrewards-subgraph-service
branch
from
9e70b84 to
163ac0b
Compare
MoonBoi9001
changed the title
MoonBoi9001
force-pushed
the
fix/getrewards-subgraph-service
branch
from
163ac0b to
3915cca
Compare
MoonBoi9001
force-pushed
the
fix/getrewards-subgraph-service
branch
from
3915cca to
3a60410
Compare
MoonBoi9001
changed the base branch from
feat/dips-on-chain-accept
to
feat/dips-continuous-collection
MoonBoi9001
force-pushed
the
fix/getrewards-subgraph-service
branch
2 times, most recently
from
9a65178 to
15d1704
Compare
MoonBoi9001
changed the base branch from
feat/dips-continuous-collection
to
feat/dips-on-chain-collect
MoonBoi9001
force-pushed
the
fix/getrewards-subgraph-service
branch
from
15d1704 to
d634e46
Compare
The contract's abi.decode(data, (CollectIndexingFeeDataV1)) expects tuple encoding, not flat parameter encoding. Also use MaxUint256 for maxSlippage to avoid RecurringCollectorExcessiveSlippage reverts from rate limiting (tracked as TODO to investigate and switch back to 0).
Three fixes that together enable end-to-end DIPs on-chain acceptance: 1. Pass SubgraphService (not HorizonStaking) to RewardsManager.getRewards in the allocation stakeUsageSummary call. 2. Decouple DIPs proposal acceptance from the 120s reconciliation loop into a dedicated 5s polling loop (startProposalAcceptanceLoop). The 300s RCA deadline left insufficient slack with the old 240s+ latency. 3. Log full revert context (reason, data, message, contract target) when on-chain acceptance fails, instead of just the parsed error (which was null for unknown custom errors). Test metadata version updated to 0 to match the Solidity enum IndexingAgreementVersion.V1 (first variant = 0). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
MoonBoi9001
force-pushed
the
fix/getrewards-subgraph-service
branch
from
d634e46 to
ad6035a
Compare
MoonBoi9001
changed the base branch from
feat/dips-on-chain-collect
to
feat/dips-on-chain-cancel
Maikol
force-pushed
the
feat/dips-on-chain-cancel
branch
3 times, most recently
from
95bca8e to
c4d0d52
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
The indexer-agent's DIPs on-chain acceptance path had three issues preventing agreements from being accepted on-chain. These were discovered during local end-to-end testing of the full DIPs pipeline (dipper -> IISA -> proposal -> indexer-service -> agent -> SubgraphService contract).
Summary
1. Wrong contract in getRewards call
AllocationManager.stakeUsageSummary()calledRewardsManager.getRewards(HorizonStaking, allocationId)butHorizonStakingis not a registered rewards issuer --SubgraphServiceis. Every allocation operation (including DIPs acceptance) reverted with "Not a rewards issuer".2. Acceptance latency exceeded RCA deadline
Proposal acceptance was tied to the agent's 120s reconciliation loop, requiring 2+ cycles (240s+) before attempting on-chain acceptance. The RCA deadline is 300s, leaving insufficient slack. Added a dedicated
startProposalAcceptanceLoop()that pollspending_rca_proposalsevery 5 seconds, independent of the reconciliation cycle.3. Opaque contract revert errors
When on-chain acceptance failed, the log showed
error: nullbecausetryParseCustomErrorcouldn't decode unknown custom errors. Added full revert context (reason, data, message, contract target) to the rejection log so the root cause is immediately visible.Test metadata version updated to
0to matchIndexingAgreementVersion.V1(first Solidity enum variant = 0). See companion PRs: edgeandnode/dipper#583, graphprotocol/indexer-rs#983.Generated with Claude Code