You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's a small thing and subject to discussion but currently if nobody advances the round, it eats into the possible time of the next round. This could lead to a situation where one round of a 7-round-ROSCA lasts for 8 days, but the next round only lasts 6.
I understand the way around it now is to allow anyone to advance the round, but we've only opened this up to the foreperson on the FE.
To attempt to avoid throwing if startRound is called too early, we could store the nextRoundStartTime in a variable, and look it up before the user is able to call startRound from the FE.
The text was updated successfully, but these errors were encountered:
That's a good point.
I would suggest we fix that by making the startRound implied in any other action, so anyone who bids/contributes will also advance the round if needed.
It sounds to me a bit "unfair" that only the foreperson can advance the round.
Wouldn't that create a very large gas differential between a 'normal' action and an action which also needed to advance the round? IIRC startRound is the most gas-heavy function we have.
Additionally, would the round be advanced before or after the 'normal' action?
It would create a "gas burden" - but that could be fixed by Metropolis's "collect call" feature.
I would imagine that if the end time of this round has passed, the round would be advanced before handling this call.
It's a small thing and subject to discussion but currently if nobody advances the round, it eats into the possible time of the next round. This could lead to a situation where one round of a 7-round-ROSCA lasts for 8 days, but the next round only lasts 6.
I understand the way around it now is to allow anyone to advance the round, but we've only opened this up to the foreperson on the FE.
To attempt to avoid throwing if startRound is called too early, we could store the
nextRoundStartTime
in a variable, and look it up before the user is able to call startRound from the FE.The text was updated successfully, but these errors were encountered: