According to this thread accounting for the time that a delegation was made when closing an allocation would allow other related changes:
This would not allow “double counting” of delegation, which has the immediate impact of removing the need for a 28 day undelegation thawing period
No “Delegator Front Running”, which has the immediate impact of being able to remove the delegation tax.
More dynamic delegation market has implications for overdelegation, as savvy delegators can easily reallocate their resources without heavy taxes and waiting periods.
It seems to me that this would be more clean, fair, and dynamic design. The downside of course is gas efficiency. I think it would be worth exploring in this thread what that cost is and how it may be mitigated.
I think this sounds reasonable for redelegation - reduce stickiness and consolidation, but could instantly exiting the protocol without thawing and instantly entering the protocol without a tax have undesired repercussions for economic security?
Is there a reason for why delegations don’t follow the same flow as indexer stake?
Right now we have the following:
indexers have to stake in protocol, then allocate towards subgraphs
delegators are delegating their tokens straight from the wallets to individual indexers
I think it would be better, if the OP idea is implemented, to also make delegations protocol wide and allocate towards indexers from inside the protocol, like we do with the subgraphs.
You will still have a thawing period for exiting the protocol, but you will have more freedom to move your delegation between the indexers.
Oh yeah, and maybe L2 migration because of the gas costs, would help tremendously, especially when we have to allocate against 100 subgraphs ( currently, at $50 per allocation close and reopen that means we’d be paying $50 x 2 parallelAllocations x 100 subgraphs = $10,000 a month in gas costs)
In general, from a smart contracts perspective, it is very expensive to do any individual tracking of the delegation pool. To the point where I am about 95% sure we should not implement it on L1 Ethereum. Meaning this conversation would almost certainly be ported into Delegation 2.0
With Delegation we have two upgrades planned, which we are currently calling Delegation 1.x and Delegation 2.0.
Delegation 2.0 , has good chances to be on an L2. Therefore I think this thread is great for discussion on how to improve delegation, but keep in mind implementation is probably far away.
To answer paynes question, the answer is that the 0.5% fee mainly exists to prevent the delegation front running. There could be lots of front running if you could just move around stake when inside the protocol in the current implementation. And it will be unlikely that the implementation can get changed enough in 1.x.
The broader question of your point - would it be technically possible to allow delegations to move around more freely? Yes, if we were able to record more data about them cheaply (i.e. use L2). I think your point is worth exploring for Delegation V2.
This sounds very interesting. One argument i saw against this kind of thing long ago, was worries about indexer uncertainty, if delegators can move ‘around’ instantly. But as we now know from mainnet, you can no longer reallocate funds that are undelegated anyway. So IMO, this change would make delegators act more dynamically and be less fearful of locking up in the first place (from observations in Discord).
Thank you, Dave!