Query fee rebate claiming: clarifying current behaviour

Hey friends,

I’ve set my query fee rebate claim threshold high to prevent my indexer-agent from spending lots of gas on claiming an insignificant amount of query fees.

My hope was that query fee rebates accumulate in the rebate pool, and all rebates can be claimed once the sum breaks the claim threshold. Is this the case, or are rebates lost if not claimed within a certain number of epochs?

1 Like

Hey, the way it works is that query fees accumulate on a per-epoch rebate pool in which your allocation was closed, this means:

  • Any new allocation that collect new query fees will be assigned to a new rebate pool for the epoch when it is closed along with the other allocations and fees collected from other indexers.
  • You can claim finalized allocations any time, there is no limit of time currently imposed in the protocol, though we might introduce one in the future.
  • The only factor that I can think will make the query fee rebate claimable economically is that the gas cost is lower.

One way to reduce gas cost of claiming multiple allocations is using the contracts claimMany() function, still not implemented in the indexer-agent but planning to do in the future.

5 Likes

Awesome, thanks for the response @ari! I might try calling claimMany manually :slight_smile: Presumably I can query the mainnet network subgraph to get a list of allocation IDs. I guess I’ll need to figure out which allocation IDs are for epochs that are finalized.

1 Like

I’ve just paid around $100 to claim $50 worth of fees, I’m wondering if this was pushed into the indexer now so that we can set a higher limit?

Also wondering if those fees sit in escrow, or if someone can burn them once the epoch is finished if we don’t claim them?

Hey @javery,

You can control rebate claims and voucher redemptions with these flags to indexer-agent:

  --rebate-claim-threshold              Minimum value of rebate for a single
                                        allocation (in GRT) in order for it to
                                        be included in a batch rebate claim
                                        on-chain       [string] [default: "200"]
  --rebate-claim-batch-threshold        Minimum total value of all rebates in an
                                        batch (in GRT) before the batch is
                                        claimed on-chain
                                                      [string] [default: "2000"]
  --rebate-claim-max-batch-size         Maximum number of rebates inside a
                                        batch. Upper bound is constrained by
                                        available system memory, and by the
                                        block gas limit  [number] [default: 100]
  --voucher-redemption-threshold        Minimum value of rebate for a single
                                        allocation (in GRT) in order for it to
                                        be included in a batch rebate claim
                                        on-chain       [string] [default: "200"]
  --voucher-redemption-batch-threshold  Minimum total value of all rebates in an
                                        batch (in GRT) before the batch is
                                        claimed on-chain
                                                      [string] [default: "2000"]
  --voucher-redemption-max-batch-size   Maximum number of rebates inside a
                                        batch. Upper bound is constrained by
                                        available system memory, and by the
                                        block gas limit  [number] [default: 100]

Hope that helps!

To follow up on your second question:

First, vouchers must be redeemed. Vouchers that are not redeemed within 7 days of issue do expire and those query fees are lost. Separately to voucher redemption, 7 days after an allocation is closed, you can claim an additional query fee rebate from the protocol. Rebate claims do not expire, so you can wait for a very large batch before claiming.

1 Like