Allow multiple undelegation request from a delegator

Governance & GIPs Graph Improvement Proposals (GIP)
1

Problem:
Currently, If a delegator triggers undelegate request it takes 28 days to withdraw rewards. During these 28 days of withdrawal time if delegator triggers a new undelegate request with same Indexer it will reset the withdrawal time and delegator again needs to wait for 28 days to withdraw rewards.

This results in poor delegation experience for delegator.

Additionally, due to this behaviour of protocol, It’s also challenging to build a DeFi layer above Graph Staking which can pool delegators funds and stake it to Graph Protocol. As this DeFI layer/pool will act as delegator for Graph Protocol and can only have one undelegate request for one indexer at a time.

Proposal: To improve delegation experience and smooth out integration of GRT Staking with DeFi protocol, I propose to introduce nonce parameter with each undelegation request.

Nonce is basically a number, which can be used to identify unique undelegation request between an Indexer and a Delegator. Nonce can be incremented with each undelegation request between an indexer and delegator. This will allow more than one undelegations.

Similar logic is also implemented by other POS protocol like Matic Protocol, where they have introduced a new function sellVoucher_new which manages unbondNonce for each undelegation request.

4 Likes
2

There are some separate ideas which would allow for undelegation to be instant. For example, taking the time-in-allocation into account when distributing rewards would remove the delegator frontrunning attack and the need for the thawing period. Once we have migrated the protocol to an L2 we should have a better idea how feasible a calculation like that would be.

5 Likes
3

There is this proposal that tries to accomplish the same goal but in a different way https://github.com/graphprotocol/contracts/pull/492 by average weighting the remaining days to undelegated tokens. This doesn’t need to use a nonce and works similarly to the indexer thawing period.

As Zac mentions, if we could calculate the “pending” rewards efficiently for a particular indexer across all allocations it would be safer to allow redelegation by repricing the bought shares to not include any pending reward.

Another idea is to turn delegation to give ERC20 tradeable shares that anyone can sell in a secondary market that could give liquidity even with the locked tokens.

3 Likes
4

Creating a secondary token that’s useable while the GRT is locked would open up a world of possibilities. I’d love to see this explored further!

4 Likes
5

RocketPool is doing interesting things with their rETH, you can use rETH in DeFi applications for example.

1 Like
7

This proposal has become even more important for Liquid Staked Token (LST) protocols, such as Tenderize.

To ensure that LST protocols maintain a consistent user experience when unstaking GRT and that the process always takes 26 days (since ETH POS), an upgrade to the smart contract is required to facilitate parallel unstakes.

The current issue that needs to be addressed by this GIP is as follows:

Problem
Only one address can perform an unstake at a time. The Graph views LST protocol contracts as a single address, representing all users. In native unstaking, each user has their own address.

Solution
The proposed solution is to allow LST protocol contracts to have parallel unstaking. As the contract represents all users utilizing a LST protocol, the Graph should permit multiple unstaking transactions to be executed simultaneously.

2 Likes