Hey everyone, as discussed yesterday several members of The Graph Council, as well as several other individuals from the community, met this morning to walk through the code changes contained in GIP-0004 and provide input on the scope of the changes from a smart contract security risk perspective and also on the viability of the mechanism as an alternative to GIP-0002.
During the discussion, the following points were raised with respect to GIP-0004.
Pros
- Targets the specific problem laid out in GIP-0002 without introducing any “side-effects” to the economics of the rest of the system.
Cons
- The implementation uses stake-weighted thawing periods to compress multiple reward withdrawals into a single balance, similar to what is done other places in the protocol, however, for a continuous rewards stream, this actually extends the effective thawing period for allocations that are shorter in duration than the thawing period.
- Related to the previous point, rewards from allocations created at the beginning of April would potentially not be withdrawable until towards the end of May. This would deprive Indexers of the ability to cover operational expenses during the critical subgraph migration period.
- Introduces new code paths and value flows for the rewards pool rather than re-using existing ones, for reasons that are completely idiosyncratic to the Token Lock Wallet. This code bloat also required a refactor of other parts of the smart contract in order to avoid exceeding the maximum smart contract storage size.
- As a result of the previous bullet, the scope of changes are larger than the smart contract experts on the Council would feel comfortable signing off on in the absence of an external audit, which currently could be scheduled for May at the earliest.
For the above reasons we’ve decided to initiate a governance vote on whether to deploy the upgrade described by GIP-0002 at the earliest convenience. The governance proposal is live on Snapshot here.
I’d like to add some color to why I will be voting “yes” on this proposal:
While it is a governing principle of The Graph Council to avoid zero-sum games, all other things being equal, in this case, all other things were not equal, for the reasons described above, along with others that have been pointed out in this thread.
It is also a governing principle of The Graph Council that it should maximize value for all stakeholders. In this case, a lack of timely action would not only imply a downside for the affected Indexers but also their Delegators, as well as Subgraph Developers, Dapp Developers, and their end-users who are counting on a stable service during the subgraph migration.
Furthermore, it’s unlikely that all proposals will benefit all stakeholders equally. For example, as we move past this proposal, we (E&N) can turn some of our attention to researching solutions to some of the issues outlined in this thread, which primarily impact Delegators. The outcome of such research may be proposals that disproportionately benefit Delegators, relative to Curators, Indexers, etc. So it’s important to not take too narrow a view of the principles outlined in The Graph Council’s mandate on any single proposal.
Finally, I would like to comment that while we may all play different roles in this protocol, we’re on a shared journey here. I encourage Delegators to consider how supporting the grassroots community of independent Indexers is of vital importance to the long-term success and decentralization of the network. Similarly, I hope Indexers understand why to some of us, it felt important to make sure that Delegators (and some Indexers) felt heard in their feedback by exploring all possible alternatives, even if we had the majority support to follow the more expedient path.