Multi-sig accounts

A multi-sig account acts only when enough of its keys sign. HyperCore builds this into the account model: you convert an existing account, with no contract to deploy.

Converting names the signers and the threshold

ConvertToMultiSigUser names the authorised users (existing Hyperliquid users) and the threshold that must sign each action. From then on every action must arrive through multi-sig; the original key can’t act alone. Sent again through multi-sig, the same action changes the set or threshold, or with an empty set converts the account back.

Every action needs a quorum and a leader

Say you and two partners convert an account to 2-of-3, and you will submit.

1. You and one partner each sign the same payload and nonce: the inner action, the multi-sig account, and you as the submitting authorised user (the leader).
2. You submit one MultiSig action wrapping the inner action and both signatures.
3. HyperCore checks them against the set and threshold, then executes the inner action as the account.

The leader must be an authorised user or its API wallet, never the multi-sig account. Signing detail is on multi-sig actions.

A quorum can send any action

MultiSig can wrap any normal action. Measured on testnet, a 2-of-2 quorum could stake HYPE (cDeposit), activate a HIP-4 outcome deployer, withdraw stake into the unstaking queue (cWithdraw) and grant named deployer actions to one operator key (setSubDeployers). A user can be a multi-sig account and an authorised user of others at once.

What this means for you. A signature round per action suits custody, not active trading. Deployers delegate daily work to one key through narrow permissions: for HIP-4, setSubDeployers, tested end to end on testnet (outcome deployer). A quorum’s grant, such as a sub-deployer permission, is revoked only by another quorum, never by one signer.

What you give up: CoreWriter and the HyperEVM side

• No CoreWriter. No HyperEVM contract, vault or token can act for the account, sign for it, or hold, stake or reclaim anything in it. Rules that need code must be enforced by the signers off chain. A design needing both code and shared custody puts custody in HyperCore signers and the code elsewhere, as in collateral underwriting.
• The HyperEVM side keeps the original key. The same address on the HyperEVM stays under the original wallet; the docs advise multi-sig users to avoid the HyperEVM entirely, before and after conversion.

The numbers

Parameter	Value
Authorised users per multi-sig account	at most 10
Nonce checked	the leader’s only (or its API wallet’s)
Signatures per action	at least the threshold, all over the same nonce and leader
Mainnet HIP-3 and HIP-4 deployer accounts that are multi-sig, 2026-09-20	8 of 12, thresholds from 2-of-3 to 4-of-8

Reading signers and decoding errors

An info request absent from the official docs returns any account’s signers:

{ "type": "userToMultiSigSigners", "user": "0x..." }

A multi-sig account returns {"authorizedUsers": [...], "threshold": n}. On the wire convertToMultiSigUser.signers is a JSON string; the string "null" converts back.

Error	Meaning
“Multi-sig required”	the account is multi-sig and the action came from a single key, such as its original one
“Multi-sig threshold not met”	too few authorised signatures
“Invalid multi-sig outer signer”	the leader’s signature does not match the submitted payload, usually an encoding error
“Invalid multi-sig inner signer”	an inner signature does not recover to an authorised user, for example one made with the wrong signing scheme

Both “invalid signer” errors are usually encoding bugs, not permission problems (fixes). Measured after converting to 2-of-2, the original key’s cWithdraw got “Multi-sig required”; one authorised key alone got “Multi-sig threshold not met”.

For a trading key that cannot withdraw, see API wallets and agents. For the path multi-sig cannot use, see CoreWriter.