Multi-Sig

Advanced Feature (Testnet-only)

The Hyperliquid L1 supports native multi-sig actions in addition to normal L1 actions. The main use case for multi-sig is user-based actions, e.g. treasuries, additional security for funds, and/or any other situation where extra security is desired.

A MultiSig action wraps around any normal action and includes the minimum required number of signatures from authorized users. An authorized user is a normal user who can sign for these multi-sig actions, in addition to using all other features of the L1. Any user can be a multi-sig user and an authorized user for another multi-sig user at the same time. A user may be an authorized user for multiple multi-sig users. The maximum allowed number of authorized users for a given multi-sig user is 10.

The multi-sig workflow is described below:

• To convert a user to a multi-sig user, the desired multi-sig user, which is not already a multi-sig user, needs to send a ConvertToMultiSigUser action with the authorized users and the minimum required number of authorized users needed to sign. Authorized users must be normal users and cannot be agents or a random address. Once a user has been converted into a multi-sig user, all actions must be done through multi-sig. The only exception is if the multi-sig user serves as an authorized user for another multi-sig user; in this case, the multi-sig user may submit a multi-sig transaction if it has been designated as the authorized user who will ultimately send that transaction to the L1.

• Each authorized user must sign a payload to produce a signature. The payload should consist of the desired action to sign off on, the target multi-sig user, and the authorized user who will ultimately send the transaction to the L1. The authorized user who will relay the message must be specified in each authorized user's payload to sign. The combination of these variables ensures that the multi-sig flow is safe and that no replay attacks can occur.

  • When a multi-sig action is sent, only the nonce set of the authorized user who sent the transaction is validated against and updated.

  • In certain scenarios, the same authorized user may be designated to send a multi-sig action from different processes. In order to avoid nonce collisions, different agents of the authorized user may be designated as the multi-sig action sender and the nonce set of a particular agent is validated against and updated. In this case, the payload should also specify the exact agent address instead of the authorized user. This use case may apply to trading or other workflows where load balancing sending actions might make more sense.

• A multi-sig user's set of authorized users and/or the threshold may be updated by having enough authorized users sign and send a ConvertToMultiSigUser action with the new state.

• Finally, a multi-sig user can be converted back to a normal user by sending a ConvertToMultiSigUser via multi-sig. In this case, the set of authorized users can be set to empty and conversion to normal user will be performed.

See the Python SDK for code examples.