How to reserve a transaction sequence number?

Question

I have a multisig account and need to initiate a transaction for set option operation. So prepared a transaction which will be expired in 7 days and within this time all (3 out 3 signers) has to sign transaction.

How i can reserve this transaction sequence so another transaction can't use this sequence ? can't use Bump Sequence as document says. also try to use future sequence number which also don't work.

This operation invalidates any transactions with a smaller sequence number, and is often utilized in complex contracting scenarios.

how can i do this ?

Example:

Master account signing weight : 0
low Threshold : 1
Medium Threshold : 2
High Threshold : 3

Signer 1 weight: 1
Signer 2 weight: 1
Signer 3 weight: 1

Initiated a set options transaction with master account public key with expiration of 7 days, let's suppose current sequence is 56545222. Here i have build the transaction envelope with sequence 56545222 but this need to sign by all 3 signers within 7 days to submit this to network.

meanwhile within this time duration master account may require to submit some other transactions like any low threshold transaction, so the aim to reserve 56545222 sequence number and the new low threshold transaction may use sequence 56545223. and this should not invalidate transaction with sequence 56545222.

or is there any other way to achieve it ?

Answer 1

Sequence number management is "low" threshold, so if you want to ensure that this specific pre-signed transaction cannot be invalidated by a subset of signers, you will have to set thresholds to 0:3:3:3. That said, it sounds like you want to allow this account to do some other thing in the interim.

An alternative is to use a different account "B" with the same signers, and threshold 0:3:3:3 that will be used exclusively by those pre-signed transactions.

Account B @ seqNum 1234

tx: {
   sourceAcccount: B,
   seq: 1234,
   timebound: ct > some_date,
   ops: [
    {
       sourceAccount: A,  ### this operation will target account A
       setOptions ... 
    }
   ]
}

Here tx does what you wanted to do: it changes signers from account A but consumes a sequence number from account B so there is no chance of conflict between use cases.

This account B can actually have many more presigned transactions after that, that could even be shared ahead of time.