Explicit freeze/unfreeze entrypoints

[pasqu4le]

Clarification and motivation

Note: this feature request only targets the LIGO version of the contract, not the Lorentz one.

We need to add explicit entrypoints for freeze and unfreeze. These should be however aware of the current proposal stage, in other words it should not be possible to use them when voting or proposing is going on.

Acceptance criteria

The contract has the freeze and unfreeze entrypoints.

[gromakovsky]

@obstropolos currently we don't have a notion of "the current proposal stage", everyone can propose and vote any time. Voting on each proposal starts as soon as it's proposed and ends after votingPeriod seconds. Does this issue imply that we should add explicit proposal stages? I envision 4 stages (though we can have 3 or 5 as well): freezing stage (only freeze and unfreeze are possible), proposal stage (only propose is possible), voting stage (only vote is possible), execution stage (only flush is possible). Does it sound right?

[michaeljklein]

@gromakovsky yes, two explicit proposal stages are required: an approximate diagram is included here https://tqtezos.medium.com/daos-on-tezos-announcing-homebase-80bbecbb9bfe

• freezing is possible in both stages
• frozen tokens may only be used in a later stage

[pasqu4le]

@michaeljklein this:

freezing is possible in both stages

makes storing and handling a lot more complex and expensive.

Supporting freeze in both stages would mean storing not only the amount of frozen token at any given time but also the stage they can be used in (and/or the one in which they were frozen). This would also need to be accounted for in the contract logic, which would mainly add a lot of calculations moving between stages.

Would it be ok to support this (as unfreeze) only in the "Proposal Period" and not in the "Voting Period"? AFAIU it would not really hinder the functionality for the contract users.

[michaeljklein]

@pasqu4le: This feature requires storing both the amount of frozen tokens and information regarding which stage they were frozen in. I recommend using a pair of balances: one for tokens frozen in voting stage and one for tokens frozen in proposal stage. These balances may then be resolved lazily in later stages.

[pasqu4le]

@michaeljklein Ok, I see, but than I have a question about unfreezing: is that also callable in any stage and from which of the two "kind" of frozen tokens does it take from?

Example: The setting is this:

• The contract is now in the "proposal" stage
• I have 20 frozen tokens from the "voting" stage immediately preceding. Which means I can use these in the current stage to make a proposal AFAIU.

At this point:

1. I freeze 10 more tokens. So I have 20 "from voting stage" frozen tokens and 10 "from proposal stage" frozen tokens.
2. I unfreeze 20 tokens.

What do I end up with?

1. A failure, because I can only unfreeze tokens "from proposal stage" in the proposal stage
2. 10 "from proposal stage" tokens, because it takes only from the tokens "from voting stage"
3. 10 "from voting stage" frozen tokens, because it takes the ones from the current stage first and from the previous stage after

One more question, just so it's clear to us, about:

frozen tokens may only be used in a later stage

This means that they can be used in any following stage and not only the one immediately after, right? In other words, is it correct that if I freeze tokens in a proposal stage I cannot use them in this one, but I can use them in any other proposal stage that comes up in the future?

[michaeljklein]

Yes, it is callable from any stage and only takes from tokens frozen in a strictly previous stage.

You should end up with a failure since the tokens frozen in the current stage are locked.

In other words, is it correct that if I freeze tokens in a proposal stage I cannot use them in this one, but I can use them in any other proposal stage that comes up in the future?

Yes, they may be used in any subsequent stage.

[pasqu4le]

Thanks for the clarification.

You should end up with a failure

Well, in the example above I should get back all 20 tokens from previous stages AFAIU, since there are enough. (aka result n.2) But I got your point :ok_hand: