Probably it is possible to update_multisig_params, but order will not be invalidated

[SubFactorial]

If it is possible to update_multisig_params such way that change params one time to some other signers list and after that change params again and set the old signers list (probably, it is possible to set reference to old cell with signers dictionary somehow with low-level code) then order will not be invalidated, because signers list the same, although it should be invalidated.

And if it is possible to update_multisig_params such way that signers list is not changed (by giving the same reference to dictionary), then it is possible to change threshold value. In mutisig.func in line 166 it is checked only that hash of signers cell the same, but it is not checked that threshold might be changed.

[nns2009]

I see you are new to FunC, but you made some good guesses in your issues. This one is the closest to be real.

probably, it is possible to set reference to old cell with signers

For your information, there is no "referential equality" in TON. Everything is compared "by value". In this case it's this part: signers_hash == signers.cell_hash() which compares hashes (which is equivalent to comparison "by value"). So...

change params one time to some other signers list and after that change params again and set the old signers list ... then order will not be invalidated

yes: re-setting the old list of signers will indeed not invalidate corresponding orders. But that seems intended as per description:

More strictly, Order is only valid when current signers are equal to signers at the time Order was created.

and I also don't see a problem with such behavior.

then it is possible to change threshold value

For a moment I thought this part is an actual flaw. But it in fact won't weaken security. In case of:

• threshold increase: throw_unless(error::singers_outdated, (signers_hash == signers.cell_hash()) & (approvals_num >= threshold)); of multisig.func won't pass
• threshold decrease. 'order.func' won't send execute message until the old threshold is reached:

  () try_execute(int query_id) impure inline_ref {
  if (approvals_num == threshold) {
      send_message_with_only_body(

  so (approvals_num >= threshold) check in multisig.func with new (lower) threshold will pass, but order.func guarantees that the old (higher) threshold was also satisfied.

[Mayowaking]

GOOD great and superb

[Mayowaking]

GOOD great and superb

[EmelyanenkoK]

As Nns2009 wrote above, indeed, setting new signers set will invalidate old orders, but setting old signers set back will restore validity (where applicable). This behavior is considered as part of documented behavior of contract.

The same stands for changing threshold: if threshold is lowered on multisig, old order will be executed but only when it gets older (higher) number of approvals. If threshold is increased on multisig, old order can not be executed due to check on multisig (that is actually why we need to send approvals_num from order to multisig), at least until threshold is not lowered back.

[SubFactorial]

"old order will be executed but only when it gets older (higher) number of approvals" Probably, it will start executing when threshold is equal to approvals_num. But if consider long lasting orders, which might call execute_internal operation or create new orders. I think that in these cases threshold might be decreased (if other order lowered threshold and set the same signers list) and initial order or some tail of initial order (execute_internal) might be executed when approvals_num != threshold, because in condition is approvals_num >= threshold: In multisig.func line 166 throw_unless(error::singers_outdated, (signers_hash == signers.cell_hash()) & (approvals_num >= threshold));

[SubFactorial]

"This behavior is considered as part of documented behavior of contract."

It is more safely to implement more strict condition: everything or nothing. That if some option is changed then it will invalidate orders which were approved with this options. It will give simpler reasoning rules. Otherwise it would be necessary to imagine tricky situations like:

• order approved, but haven't yet executed;
• threshold increased, so order is not executed, while new approver will approve it;
• new approver approve order, but at this time (earlier or later) threshold decreased;
• so order is not executed again because approvals_num is not equal to threshold.

[tolya-yanot]

@nns2009 and @EmelyanenkoK are right. No problem here