Supra Multisig Guide
The Supra Multisig module control to Multisig accounts unlike traditional Multisig systems that require users to specify public keys, this Module only requires addresses as owners.
This module also supports updating owners without having to change the auth key. It offers two options for storing transaction payloads: either a full on-chain payload (providing full decentralization and transparency) or a lightweight payload hash (saving gas without sacrificing security during execution).
Key Benefits
Dynamic Owner Management: Easily add or remove owners without resetting the auth key.
Flexible Transaction Storage:
Full Payload: Maximum transparency and resilience.
Hash-only: Saves gas while retaining verification ability.
Nonce-Based Order Enforcement: Transactions execute in order, ensuring predictable behavior.
Simple Onboarding: Create Multisig accounts with a default owner and extend as needed.
Interacting with Multisig via Supra CLI
Supra offers intuitive CLI commands to interact with multisig accounts. Here’s guide for CLI Commands:
Create a new multisig account on-chain:
Approve a pending multisig transaction:
Propose a new multisig transaction:
Execute a multisig transaction that has its full payload stored on-chain:
Removes a proposed multisig transaction (finalizes a rejection):
Execute a multisig transaction where only a payload hash was stored on-chain:
Reject a multisig transaction:
Verify that the entry function matches the on-chain transaction proposal (serialization check)
Verify that the proposed transaction (its entry function and parameters) matches the on-chain proposal:
Transaction Flow Overview
The typical workflow when interacting with a multisig account is as follows:
Creation of the Multisig Account:
create: Instantiates a multisig account with a single default owner.
Transaction Creation:
create_transaction: An owner can initiate a multisig transaction by providing the entire transaction payload.A unique transaction Sequence ID is assigned to every newly proposed transaction.
Transaction Voting (Approval/Rejection):
approve: Other owners can approve the pending transaction by submitting their approval with the transaction ID.reject: Conversely, owners can reject a transaction if they do not agree with its content.
Transaction Execution:
executeorexecute_with_payload:If enough approvals have accumulated, any owner can execute the transaction.
Depending on whether the full payload or just a hash is stored, the appropriate execute function is called.
Execution Details:
The multisig module first verifies that the payload has received the required number of signatures.
The executing owner pays for the gas fee.
Finalizing Rejected Transactions:
execute_reject:Once a transaction accumulates enough rejections, any owner can finalize the rejection of that transaction.
Practical Tips
Transaction Proposals: Depending on your cost and transparency preferences, choose between storing the full payload or just the payload hash when using
create-transaction.Voting and Execution: Utilize the
approveorrejectsub-command with the appropriate sequence numbers. When ready, execute the transaction using eitherexecute(if the full payload is on-chain) orexecute-with-payload(if you stored only a hash).Verification: Always verify the proposal details with
serialize-proposalorverify-proposalprior to voting, ensuring the on-chain data aligns with your expected parameters.
Link to Module & Repository Docs:
Last updated