GIP-0014: Batch GNS transactions

Limiting the self-signal would only serve bots looking to be the second curator on the bonding curve.

A developer would be able to curate with a higher amount right after deployment. (If a limit is put on the deploying address, another address would be used)


Developers themselves having a large self-signal can be very healthy for the network

Curators

  • Limits the impact of bots - A large self-stake limits the impact of malicious actors that signal early.
  • Less volatile curation markets - If the developers intend to keep their curation shares, this would push the bonding curve into an area of less relative steepness.
  • More data - A subgraph with self-stake can indicate an intent to query the subgraph

Developers

  • More Predictable service - Indexers allocate resources according to the signal on a subgraph. A subgraph with volatile signal will also receive varying service. Developers that hold a significant self-signal would receive a more predictable service;
    • No matter the market conditions, the developers can ensure a “base amount” of signal
    • Subsequent curators are pushed into a “less volatile” area of the bonding curve.

Indexers and Delegators

  • More predictable signal - For the reasons mentioned above, the indexers will also see a more predictable signal, allowing them to better optimize their allocations, tune their infrastructure, write good cost models and more. This would in turn lead to higher indexing rewards, which benefits both indexers and their delegators.

It is also important to realize that The Graph is not a zero-sum game. Every stakeholder group is better off when working together to deliver a great service.


I am heavily in favor of batch transactions.

4 Likes