28 days is unreasonably long. Either do away with it altogether or reduce it to 7 days OR add in a re-delegation function so that delegators can more flexibly move their stakes.
I can go on about how it’d promote decentralization and gives flexibility and how other chains are like that, blah blah, but basically there’s no good reason not to do so.
Hi PepperbenzMcSpicy,
I think it’s important to keep in mind that shortening the 28 day period could effectively double the minimum amount of gas an Indexer may spend per month. This is because Indexers would be required to close their allocations more often than every 28 days. As a result, Indexers may pass on these costs to their Delegators, which would make delegating less profitable for Delegators.
The challenge is to find a way to shorten the unbonding period without introducing economic attack vectors, as Brandon Ramirez stated:
“In general, I think shorter unbonding periods make for a more dynamic/efficient market, because it frees up Delegators to respond in real-time to behaviors of Indexers. Finding a way to shorten/remove the unbonding period w/o introducing other economic attack vectors or short comings is the challenge.”
Here is a detailed explanation of the purpose behind the 28 day unbonding period:
I’m unclear on the specific technical implementation but I don’t see why double-counting and front-running are necessary problems, as in why must tokens be allocated for 28 days even after undelegating? The blockchain snapshot at the very end of an epoch should only record each delegated token once, no? (As in each unit in a blockchain is only at one unique address at a time, less a double-spend attack. This can be extrapolated to the delegation tracking system.)
It seems there’s some obfuscated system in which GRT counts delegated tokens and distribute validator rewards which should be improved. What I basically hear is that we can’t workaround this because of imprecise counting issue, but I don’t think/can’t see why that’s true. Surely the unthawing period can be scraped, the token un-allocated immediately on undelegation, and reward calculated precisely pro rata by time. Will it take a bit more code/logic? Yes. Does it sound impossible or even difficult? I say no.
@pepperbenzMcSpicy Rewards aren’t payed or calculated at the end of an epoch, but rather when each specific allocation is closed.
If you undelegate and immediately have the funds available to redelegate your GRT could be potentially be in 2 (or more, depending on the circumstances) allocations at the same time, if the indexer from whom you undelegated still has his allocations up, and the new indexer that you will delegate to will open his allocation just after your delegation.
This means that your GRT is being counted twice on the reward calculation, which shouldn’t happen since you are basically being counted twice for reward payment and generation (diluting everyone else’s rewards, and getting a bigger share of them than you should be able to).
Front-running is also an important issue, since you would be able to jump from indexer to indexer just before they close big allocations, and get all the rewards that you would get if you’ve been delegating to them for the whole allocation period, while diluting everyone else’s rewards.
The system might not be perfect, but the reward distribution logic can’t be tied to epochs ending, since the calculations needed to distribute all rewards to everyone would be extremely expensive (and also should be triggered by someone externally, who would have to pay for all the gas fees of this extremely heavy computational logic). I’m guessing that’s the reason the system is designed the way it is (although if anyone knows better, feel free to correct me)