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
Copy file name to clipboardExpand all lines: IndexingPaymentsTodo.md
+21-13
Original file line number
Diff line number
Diff line change
@@ -1,25 +1,33 @@
1
1
# Still pending
2
2
3
3
* Arbitration Charter: Update to support disputing IndexingFee.
4
-
* Economics
5
-
* If service wants to collect more than collector allows. Collector limits but doesn't tell the service?
6
-
* 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.
7
-
* What should happen if the escrow doesn't have enough funds?
8
-
* Don't pay for entities on initial collection? Where did we land in terms of payment terms?
9
-
* Should we set a different param for initial collection time max? Some subgraphs take a lot to catch up.
10
-
* 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)?
11
-
* Double check cancelation policy. Who can cancel when? Right now is either party at any time.
4
+
* Double check cancelation policy. Who can cancel when? Right now is either party at any time. If gateway cancels allow collection till that point.
12
5
* Expose a function that indexers can use to calculate the tokens to be collected and other collection params?
13
-
* Support a way for gateway to shop an agreement around? Deadline + dedup key? So only one agreement with the dedupe key can be accepted?
14
-
* If an indexer closes an allocation, what should happen to the accepeted agreement?
15
6
* test_SubgraphService_CollectIndexingFee_Integration fails with PaymentsEscrowInconsistentCollection
16
-
* Switch `duration` for `endsAt`?
7
+
* Switch timestamps to uint64.
17
8
* Check that UUID-v4 fits in `bytes16`
18
-
* Test `upgrade` paths
19
-
* Test lock stake
9
+
* Check code coverage
10
+
* Check contract size
11
+
* Add upgrade path to v2 collector terms
12
+
* It's more like a collect + cancel since the indexer is expected to stop work then and there. When posting a POI that's < N-1 epoch. Answer: Emit signal that the collection is meant to be final.
13
+
* Don't love cancel agreement on stop service / close stale allocation.
14
+
* Place all agreement terms into one struct
20
15
21
16
# Done
22
17
18
+
* DONE: ~~If an indexer closes an allocation, what should happen to the accepeted agreement? Answer: Look into canceling agreement as part of stop service.~~
19
+
* DONE: ~~Switch `duration` for `endsAt`? Answer: Do it.~~
20
+
* DONE: ~~Support a way for gateway to shop an agreement around? Deadline + dedup key? So only one agreement with the dedupe key can be accepted? Answer: No. Agreements will be "signaled" as approved or rejected on the API call that sends the agreement. We'll trust (and verify) that that's the case.~~
21
+
* DONE: ~~Test `upgrade` paths~~
22
+
* DONE: ~~Fix upgrade.t.sol, lots of comments~~
23
+
* DONE: ~~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)? Answer: Signal in the event that the max amount was collected, so that fisherman understand the case.~~
24
+
* DONE: ~~Debate epoch check protocol team. Maybe don't revert but store it in event. Pablo suggest block number instead of epoch.~~
25
+
* DONE: ~~Should we set a different param for initial collection time max? Some subgraphs take a lot to catch up. Answer: Do nothing. Make sure that zero POIs allow to eventually sync~~
26
+
* DONE: ~~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. Answer: Ignore stale allocation~~
27
+
* DONE: ~~If service wants to collect more than collector allows. Collector limits but doesn't tell the service? Currently reverts. Answer: Allow for max allowed~~
28
+
* DONE: ~~What should happen if the escrow doesn't have enough funds? Answer: Reverts~~
29
+
* DONE: ~~Don't pay for entities on initial collection? Where did we land in terms of payment terms? Answer: pay initial~~
30
+
* DONE: ~~Test lock stake~~
23
31
* DONE: ~~Reduce the number of errors declared and returned~~
24
32
* DONE: ~~Support `DisputeManager`~~
25
33
* DONE: ~~Check upgrade conditions. Support indexing agreement upgradability, so that there is a mechanism to adjust the rates without having to cancel and start over.~~
0 commit comments