How to determine sequence no for pre-authorised transaction with time bound validity without blocking other new possible transactions

Question

If a pre-authorised transaction is created for time bound validity after 50 days and submitted to the network, does this mean another transaction before 50 days cannot happen as the sequence number would be greater than the pre-authorised one?

Answer 1

The pre-signed transaction will be invalidated if someone submits a transaction against the same account. This is possible because the account is not locked and therefore someone with the secret key is able to submit transactions against the account.

Any new transaction submitted against the account would increase the sequence_number on the account which would make the sequence_number used in the pre-signed transaction invalid, effectively invalidating the whole pre-signed transaction.

---

Pre-signed transactions are special in that:

1. they are bound to a specific account
2. they are bound to a specific sequence number
3. they are (optionally) bound to a specific time period
4. they are signed by a specific signer

The account still functions like normal even if you have made public any pre-signed transactions. Therefore, the best approach when working with pre-signed transactions is to create a separate escrow account that is locked, only allowing your pre-authorized transaction to execute.

---

Here are the steps to create pre-authorized transactions on the Stellar network using an escrow account that is locked:

1. Create a new account. This is the escrow account.

2. Fund it with the assets that you need (including the minimum account reserves and the expected transaction fees).

3. Assuming the sequence_number on the escrow account is currently 100, create a time-locked transaction with the sequence_number=102 (yes, we intentionally skipped 101, we are saving it up for step 6). This is the pre-authorized transaction that you will distribute.

   Note that this transaction is not signed and should not be submitted to the network yet.

4. Create a second time-locked transaction with the same sequence_number=102. The startTime should be after the maxTime of your pre-authorized transaction (say, 1 day). This is your abort transaction.

   Note that this transaction is not signed and should only be submitted to the network to recover the funds in the case that your pre-authorized transaction is never submitted (which is why it shares the same sequence_number).

5. Create a third time-locked transaction with the sequence_number=103. The startTime should be after the startTime of your abort transaction (say, 1 day). This is your merge transaction.

   Note that this transaction is not signed and should only be submitted to the network after either the pre-authorized transaction or the abort transaction is submitted so the sequence_number on the account is at 102 before this transaction is submitted. This transaction allows you to recover the min-reserve on the account by merging the escrow account into your original account using the Merge Account operation.

6. Now that we have our 3 transactions (pre-authorized, abort, and merge) we need to set the correct signers on the escrow account to allow these transactions to function as expected. You will need to create a transaction with sequence_number=101 (this is where we use the saved up sequence number). This transaction should have the following operations and should be submitted to the network:

   a. add the hash of the pre-authorized transaction as a signer

   b. add the hash of the abort transaction as a signer

   c. add the hash of the merge transaction as a signer

   d. sets the master-key weight to 0. This is very important to lock the account and must be the last operation in this transaction.

7. You will end up with an escrow account that is locked which only allows 2 of the 3 transactions to be executed. You should distribute the pre-authorized transaction to the concerned party and keep the abort and merge transactions with you.

   Note that these transactions can only be submitted in the order of pre-authorized followed by merge OR abort followed by merge. If they are submitted in any other order they will not have any effect and will not bump the sequence_number.

This is now a Stellar Smart Contract.

Answer 2

Correct, but keep in mind that pre-authorized transactions are not valid until a matching transaction is sent. That means that you could create a new transaction with the same sequence number as that of the pre-authorized transaction and send it to the network.

The network will accept this new transaction, and when the 50 days are due and you send the pre-authorized transaction the network will reject it (because the sequence number has been used).

A safer approach might be to create a separate account for all these pre-authorized transactions