Signing a Transaction
Signing flow
In order to execute a transaction in the multisig safe it is necessary to reach the confirmation threshold for the created transaction. Confirmation threshold is a number of signatures of safe owners required for authorizing the transaction.
Taking into account that the Asigna multisig app applies native Stacks approach, owners of Assigna multisig safes have to sign transactions only in the order their public keys were added to the multisig safe. This issue required from the Asigna team the implementation of signing flow procedure. We tried to make our best to help users to go through the signing flow procedure smoothly.
However, we want to inform our users that currently use Stacks blockchain has issues with the signing flow. We understand the importance of flexible transaction processing for multisig solutions, and we are actively addressing this issue. The Asigna team, has prepared an SIP proposal to expedite the process.
While the Asigna team works diligently on workarounds and strives to implement improvements even before this SIP is accepted. We appreciate any feedback and attention from our valued users as we navigate through this situation.
Signing flow implies that a transaction can only collect signatures in a certain order, established when the safe was created. This signing order (flow) will be applied to each transaction in the safe. Successful passing of the signing flow is equated with reaching confirmation threshold.
Safe owners, signing flow and the confirmation threshold cannot be changed after the safe is created.
Signer roles
Signatures are cryptographic proofs that an owner approves a specific transaction. Signatures are generated using the owners's private key and combined with the transaction data. The resulting signed transaction can be verified using the owner's public key.
Owners are responsible for:
Initiating transactions
Signing transactions using their private keys
Approving transactions proposed by other owners
With signing flow owner roles become more specified.
Multisig safe creation
For example, we want to create a multisig safe with 4 owners and confirmation threshold = 2.
At the moment we define the confirmation threshold = 2, we can observe changes in the Can sign first column: the safe creator (You), Seamons and Gerard get green "Yes" labels. And the last one, Ernesto, gets grey "No" label.
Can sign first: the user is able to initiate a transaction and put the first signature (launch the signing flow).
Cannot sign first: the user is able to initiate a transaction, but not able to put the first signature (launch the signing flow).
Explanation: at the moment an owner puts the first signature to the transaction, he automatically launches the signing flow. Given that confirmation threshold = 2 and owners of the safe have to sign transactions only in the order their public keys were added to the multisig safe. Ernesto, the last added owner, is not able to sing the transaction first, as there is no any owner after him to sign the transaction and reach the confirmation threshold = 2.
If confirmation threshold would be 3, Ernesto and Gerard both are not able to sing the transaction first, as there should be 2 owners after them to sign the transaction and reach the confirmation threshold = 3. Ernesto has none, and Gerard has only one owner after him.
It is possible to change the signing order of the added owners during Add owners stage by using Drag&Drop within the list.
Creating transaction
Once we created the multisig safe with 4 owners and confirmation threshold = 3, we can create a transaction and see how owner's position in signing flow order influences his signature status and ability to create an additional signing flow.
A transaction in the multisig safe can be created by any owner. Nevertheless, not all the owners will be able to launch the signing flow to push this transaction further:
Can sign first: At the moment an owner who can sign first creates the transaction, he launches the signing flow and automatically signs this transaction.
Moreover, an owner who can sign first is able to launch a new signing flow to the existing transaction (with button +Create new). Even if this transaction has been created by another owner.
Cannot sign first: At the moment an owner who cannot sign first creates the transaction, he doesn't launch the signing flow, as he cannot automatically sign this transaction. That means, he can only put a new transaction to the Queue and wait till any owner who can sign first will launch the signing flow.
Thus, an owner who cannot sign first either isn't able to launch a new signing flow to the existing transaction.
In this case, participation of the owner who can sign first is required to launch the signing process of the transaction with zero confirmations.
Signing transaction
The signing flow is considered to be launched as an authorized owner puts the first signature. The first signature is put at the moment the owner who can sign first creates a transaction or launches a new signing flow for the existing transaction.
Once the first signature is put, we can observe how the owner roles are distributed according to their position in the signing order.
Sign - your turn to sing the transaction
Signed - you/the owner has already signed the transaction
Eligible to sign - the owner's turn to sing the transaction
Queuing - you/the owner should wait for signatures of higher ordered owners
Unable to sign - you/the owner is not able to sign in this flow, as lower ordered owners have already signed
Executing transaction
Once one of the signing flows gathers all the required signatures and reaches the confirmation threshold, the transaction is ready to be executed. It can be executed by any safe owner, without regard to his signing flow status.
At the same time, other signing flows are marked as failed and not able to gather signatures anymore.
Along with that, the owners are not able anymore to create a new signing flow.
Last updated
