You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Update `DisputeManager` and Arbitration Charter to support disputing Indexing Fees.
5
-
* Support indexing agreement upgadeability, so that there is a mechanism to adjust the rates without having to cancel and start over.
6
-
* Built-in upgrade path to indexing agreements v2. So that indexers can be paid per byte instead of per entity.
7
-
* Support for agreements that end up in `RecurringCollectorCollectionTooLate` or ways to avoid getting to that state.
8
-
* Should we deal with zero entities declared as a special case?
9
-
* Since an allocation is required for collecting, do we want to expect that the allocation is not stale? Do we want to add code to collect rewards as part of the collection of fees? Make sure allocation is more than one epoch old if we attempt this.
10
-
* Reject Zero POIs?
11
-
* What happens if the escrow doesn't have enough funds? Since you can't collect that means you lose out forever?
3
+
* Double-check it supports paying per byte instead of per entity and eventually a subgraph-gas metric. DONE: ~~Built-in upgrade path to indexing agreements v2~~
4
+
* Update Arbitration Charter to support disputing Indexing Fees. DONE: ~~Support `DisputeManager`~~
5
+
* Economics
6
+
* If service wants to collect more than collector allows. Collector limits but doesn't tell the service?
7
+
* Support for agreements that end up in `RecurringCollectorCollectionTooLate` or ways to avoid getting to that state.
8
+
* Should we deal with zero entities declared as a special case?
9
+
* Since an allocation is required for collecting, do we want to expect that the allocation is not stale? Do we want to add code to collect rewards as part of the collection of fees? Make sure allocation is more than one epoch old if we attempt this.
10
+
* Reject Zero POIs?
11
+
* What happens if the escrow doesn't have enough funds? Since you can't collect that means you lose out forever?
12
+
* Don't pay for entities on initial collection?
13
+
* Should we set a different param for initial collection time max? Some subgraphs take a lot to catch up.
14
+
* How do we solve for the case where an indexer has reached their max expected payout for the initial sync but haven't reached the current epoch (thus their POI is incorrect)?
15
+
* Double check cancelation policy. Who can cancel when? Right now is either party at any time.
12
16
* Expose a function that indexers can use to calculate the tokens to be collected and other collection params?
17
+
* Support a way for gateway to shop an agreement around? Deadline + dedup key? So only one agreement with the dedupe key can be accepted?
18
+
* Maybe check that the epoch the indexer is sending is the one the transaction will be run in?
19
+
* Check upgrade conditions. Support indexing agreement upgadeability, so that there is a mechanism to adjust the rates without having to cancel and start over.
20
+
* If an indexer closes an allocation, what should happen to the accepeted agreement?
21
+
* test_SubgraphService_CollectIndexingFee_Integration fails with PaymentsEscrowInconsistentCollection
22
+
* Reduce the number of errors declared and returned
23
+
* DONE: ~~Make `agreementId` unique globally so that we don't need the full tuple (`payer`+`indexer`+`agreementId`) as key?~~
24
+
* DONE: ~~Maybe IRecurringCollector.cancel(address payer, address serviceProvider, bytes16 agreementId) should only take in agreementId?~~
0 commit comments