Our upcoming protocol proposal will introduce native multisig user accounts. These extend all functionalities of user (aka implicit) accounts with enshrined multisig capabilities. As a result, users relying on BLS keys (tz4 addresses) would be able for instance to securely control collective staking positions (signing delegation and staking/unstaking operations), and even managing the staked funds of a Tezos baker and participating in governance. In this post, we give an overview of the proposed feature and the associated API planned for upcoming Octez releases. We also hope this will be the starting point of fruitful discussions which lead to new exciting applications for the Tezos blockchain.
Our protocol proposal S is almost ready! While its features are under stabilization, we want to share one exciting (and much anticipated) feature of the upcoming proposal: native staking multisigs.
In a nutshell, our protocol S proposal takes advantage of the signature aggregation capabilities of BLS signing schemes to introduce native multisig accounts, extending all the functionality of user (aka implicit) accounts with protocol-enshrined multisig capabilities. This includes delegation, staking and managing and operating a baker.
In this post, we provide an overview of the proposed Tezos L1 protocol features and of its Octez interface RPC endpoints and CLI commands. A comprehensive online Appendix documents the spec for the proposed interface and provides complete step-by-step instructions for two selected use-cases: staking and baking multisigs.
This Agora thread is also an opportunity to answer questions regarding the proposed changes, discuss future improvements to UI and the integration of this feature in tooling and applications downstream.
Introducing native multisig accounts
Tezos accounts are defined by a pair of secret and public keys. Users use their secret keys to sign operations (or blocks), and the resulting signature is validated against the account’s public key. While this model is simple and effective, it presents two main challenges:
-
The entire security of the account relies on a single secret key. If this key is compromised, an attacker can gain full control of the account.
-
The model is not well-suited for organizations or shared accounts, as it does not allow for multiple users to manage the account collectively.
Our protocol S proposal addresses these limitations with a cryptographic solution based on BLS multi-signature schemes. BLS signatures are particularly well-suited for this purpose due to their aggregation properties. Tezos already supports BLS signatures, and with the adoption of protocol proposal S, it would adopt a proof-of-possession (PoP) scheme.
As a result, the Tezos protocol would benefit from faster verification of multiple signatures of the same message without breaking compatibility with the existing support for BLS (and tz4 accounts).
Our proposed implementation offers RPCs and client commands to facilitate the signing of operations in a native multisig setup, which are described in Appendix B in this document. As a result, the protocol does not need to differentiate between a tz4 address belonging to a single user account and one associated with a native multisig account.
It should be noted that the API provided to interact with the proposed features, both Octez CLI command and RPC endpoints, is not subject to governance and can indeed be evolved through regular Octez releases based on feedback and requests from users and builders.
Indeed, its current presentation is not intended as a final end-user solution, but rather as the infrastructure upon which multisig applications and solutions can be built.
Enshrined multisig signing scenarios
Our upcoming protocol S proposal supports two different multi-signature schemes, which provide different scenarios based on the requirements for signing an operation:
-
N-of-N scenario (signature aggregation): All members must sign every operation for it to be valid. Here, N represents the total number of participants. In this scenario, users derive a multisig account by aggregating the public keys of their existing tz4 addresses without the need for sharing secrets or trusted parties.
-
M-of-N scenario (threshold signature): A threshold number of participants is required to sign the operation. Here, M denotes the minimum number of signatures required to create a valid signature, out of a total of N members. In this scenario, users generate a new unencrypted secret for the native multisig account, which is then split into secret shares that need to be distributed among the participants along with a public identifier. This entails that all participants must trust the honesty of the party in charge of splitting the secret key and distributing the secrets (more on this below).
The workflow for signing operations is as follows:
- The participants decide a priori which scheme to use: either N-of-N or M-of-N.
- The participants reveal the resulting public key of the native multisig account on-chain.
- The participants inject operations signed with the native multisig accounts’s signature.
For example, a native multisig account can stake 10,000 tez following almost the same process as if it were carried out by a single staker. The only difference is the signing process: signatures (for each operation) must first be collected from the required members, and then aggregated into a single signature based on the chosen scenario. The resulting operation is identical to a staking operation signed by a single implicit tz4 account. For instance, the JSON output of a multisig stake operation would look like:
On sharing secrets. The current implementation of M-of-N Scenario in our S proposal relies on Shamir’s Secret Sharing algorithm to share an unencrypted master secret key between participants — i.e. it returns a public key and unencrypted secret keys for each of the multisig account participants.
We envision implementing support for further key-generation mechanisms in future protocol proposals, notably Distributed Key Generation, if there is sufficient ecosystem interest.
User stories: staking and baking multisigs
We consider two use-cases for native multisig accounts:
- a staking multisig, using a 2-of-3 threshold signature scheme, where 3 users controls collectively an external staking position with a chosen baker, and;
- a baking multisig, using a 3-of-3 signature aggregation scheme, where the users register a baker with a multisig manager (baking) key.
We provide only a summary of the involved steps, highlighting key commands. The full user stories, with step-by-step examples implemented on the Nextnet-20250610 test network, can be found in Appendix A.
We use Octez CLI commands in the sequel, and we store unencrypted keys in Octez’ native wallet (keys are stored in the client’s directory, usually .tezos-client). The complete specification for the proposed CLI commands (and alternative RPC endpoints) associated is given in Appendix B.
Staking multisig with a 2-of-3 threshold signature scheme
Alice, Bob and Charlie want to use the new features to control together their staking position with a chosen baker, Danny. They have decided that they want to use a 2-of-3 threshold scheme, that is 2 out of their 3 signatures are necessary and sufficient to submit an operation on behalf of the multisig account. For this, they need to perform the following steps:
1. Setting up a native multisig account
The first step is to generate a new native multisig account (a fresh tz4 address) and set up the 2-of-3 threshold signature scheme. This step needs to be performed only once, and will determine each participant’s share of the native multisig account.
Let’s assume the new account is tz4SY87c9MTEknnhcmwfu3d7Qu8HqmgwfJkY (we refer to it as multisig_staker next).
Charlie uses a dedicated CLI command (to be included in the next Octez version) to split its secret key:
octez-client share bls secret key BLsk31ui8c4tQxfBEyY2FdbQdW8vmpoU5GUT4BhWPYijfjDqTQ3HVJ between 3 shares with threshold 2
The output results:
{ "public_key":
"BLpk1tvA7VVVtccUz1VpCcvNgysintAReyaTdEzrCU6Ai9gftLMDQQNniKtmH5sMG7BqeR1uN4hy",
"public_key_hash": "tz4SY87c9MTEknnhcmwfu3d7Qu8HqmgwfJkY",
"proof":
"BLsigANFeKUgWe2G7xxvu71q1PbBrC3DpugmcA47hb2qNNc3pXgWwG1wqwEKLycEHRy4uxzr3JxvhTmyBspaZy6fAiSFtxf8c31tejMryhJccxXHeJaHvnKhzueraTx4X2BSu61LVUysJW",
"secret_shares":
[ { "id": 1,
"secret_key":
"BLsk386ezrsNEuGbK9w9X5uNAjvErtxNTZkbKhPH8gueR4D29YbpXR" },
{ "id": 2,
"secret_key":
"BLsk3Ej3deDs94CkwyCCemNvqk7QTdruKnkMBs5WoHCCwoyB37UcGJ" },
{ "id": 3,
"secret_key":
"BLsk3LuzVuKWN5NL1EYxfcdGfTzUBvmBKcByow15JBr9nhPFMcP6dU" } ] }
Charlie keeps the third secret for himself, and distributes the other keys with Alice and Bob offchain. At this point, Charlie should safely dispose of the original secret key.
Note that Alice, Bob and Charlie need to know their (and each other’s) ids in order to threshold-sign operations.
They each import their key share on their own Octez CLI wallets, resulting in the following public keys hashes:
alice: tz4Vie2TsJ3Mam2AokxdFmYiEDJBa3SmdxaR
bob: tz4AwFeLnsKxz6ZjPUTqYLTEgnN8Tsm9bt2d
charlie: tz4KJcmyjKBg9ie853HzhTTiennMgh2Jk9RS
These are the accounts they will use to sign operations in the multisig. Each of them represents uniquely one share of the native multisig account.
Note that their secret keys are unencrypted, so anyone with access to the client directory can obtain them. It is important also to make sure that the unsplit secret key of the multisig_staker account is removed and any copy erased—anyone with access to it can override the multisig.
2. Revealing the native multisig account and delegating to Danny {#2.-revealing-the-native-multisig-account-and-delegating-to-danny}
The second step is to reveal the public key for multisig_staker and to delegate its balance to the chosen baker, Danny. For this, the participants will craft a threshold-signed operation batch, as it would be the case when using the Octez CLI, when submitting an operation for the first time with a fresh user account.
Notably, this step entails having (at least) 2 out of the 3 participants signing the operation with their share of the multisig’s secret key, and distributing the resulting signatures back for their aggregation. The latter action is implemented with a new dedicated command:
octez-client threshold bls signatures '{
"public_key": "BLpk1tvA7VVVtccUz1VpCcvNgysintAReyaTdEzrCU6Ai9gftLMDQQNniKtmH5sMG7BqeR1uN4hy",
"message": "03d174203bbaa2e246b18a28bb000a51c2500c68f519abf31178d07f9b5041d3546b03c050cc1cf74b548e2f4a38601359f9193ad8e0f6df05b436b3190003a27772741a3499ab5314c32ca428bf967bc1af267d02e3e4a71c2beadc599c791ac93ceb38da14f54a858d6d367c6acdff000000609627ef52ed27c15c8f7e52840ec73f9375d6ea4fc2eee9158337698f681b49ac131b937f4ed2557573471c60a70bcf1e174c06914bd2bb25dc4bdbcf934926d9c99cc81e7309e6e0c009ae4bc80b9755124b6e74bdc8f52bc8d517c67e75ab2d6e03c050cc1cf74b548e2f4a38601359f9193ad8e0f6a001b5366400ff0053a5d738895254bc69aa4ca880f5c02e8fdca56d",
"signature_shares": [{ "id": 1, "signature": "BLsigAySmshxmoGafb5XvWypf2zE87Kc9v15bXwFwFqrCHrhMuLPet7fDeMwqZD4TrmTzTaE3TWnY6a4kpEAYMVS9oz9N7xDCxLBeysLwiR6Qc7zXS1cPWGGvbJNr2mn6exJ9wfrjcEjnG" },
{ "id": 2, "signature": "BLsigBDm2PRdzTzYSakH6WvS84miXawojkZ5Bprp3MXAcBUCpMMeDNsfLFPNCwwZr4rhMkMoUbQeMHLyk7BCDNgodrxamZiXksB8ZSk3xcJxR1HNTQXhBWZMTrniFe4hFWoBUbohFo5qHB" } ]}'
Here, the id values are those associated with each share when originally splitting the key: id:1 for Alice and id: 2 for Bob. In a larger setup, users should share their id values publicly. The message value represents the unsigned operation signed by each participant.
The complete instructions for this step are provided in Appendix B.
3. Staking with the chosen baker
Finally, the participants will stake with the chosen Baker. This requires to craft a new threshold-signed operation as in the previous steps – the full steps are provided here.
Alice, Bob and Charlie will need to repeat the last step whenever they are manipulating their joint stake, that is by threshold-signing further stake, unstake, and finalize unstake operations.
Baking key multisig with 3-of-3 signature aggregation scheme
Alice, Bob and Charlie want to set up a Tezos baker. In order to increase the security of the baking (or manager) key, they would like to create a 3-of-3 multisig account to manage staking operations and governance participation for their baker.
They will also set up a separate consensus key, which will take care of the baker’s participation in consensus, signing block and (pre)attestations.
Note that, from the Tezos protocol perspective, nothing prevents using a native multisig account as a consensus key. However: there is no support in the Octez baker to implement the offchain mechanisms required to craft the multisig operation. Moreover, this is also undesirable, as the extra steps would entail slower times to produce and broadcast consensus operations and blocks.
Setting up the baking key involves the four following steps:
1. Deriving the public key of the multisig baking account
In this setup, we assume Alice, Bob, and Charlie each have an existing tz4 account, which has been revealed after the activation of the proposed features. This is because our S protocol proposal introduces a Proof-of-Possession argument to the revelation operation for tz4 accounts, and whose purpose is to provide a witness of the ownership of the underlying secret key to aggregate signatures.
In this step, which has to be performed only once for the duration of the multisig**,** the participants will:
- derive the tz4 address resulting from the aggregation of their public keys, and;
- generate the collective Proof of Possession evidence that will allow the correct operation of the multisig account.
The public keys are aggregated with a dedicated CLI command:
octez-client aggregate bls public keys '[
{ "public_key": "BLpk1qpQmLF7CUzF57KpGvJtkH9N6j1dXr2yFMR62JxRFS7XVbrKZ8kv5b85JAUoQNV5Pk3oyCMw",
"proof": "BLsig9Yvv9bfKyciukcBXdDKtmD184Vz6dLPpM7M5AV1oRZkAhJb2PZMnPDet2TAYGEHZprG87uPqKPsMYWs6Bi8rABYbMwun2u9KivkoZv5tj331k5FvktjAW5xzawFLW1F1kRCtun8Dz"},
{ "public_key": "BLpk1kgqRcUXgMdqjbe1MHweHDQFtUUAjg4GqEhr9MYkZnq7gRCSQJNx8Fr1gAmHP171pyZamUNa",
"proof": "BLsigB8ZzH2NAEFYirvpDweoC9CzHEgh9kVtsFHRnK3FggeirNY9Qud3qoBBtufHztwgrwaUgupLaQNj4z69bHF2o9v3b5Uq78iSwfpj1n7cHbgzxzv9rVTrD4orwE55QgGBHW6W7QemYB"},
{ "public_key": "BLpk1vBvm4odRKoYsVavJ9MbR4JqGfsJ3udrv4a6ji2pnGpMuSXxMjCXfQ88JjmSXiyRZK9joy3b",
"proof": "BLsigBB8Vcv5ZStsxuanMadfeJpu1fM6cKdfgnMPKE4kKuVSUGYRZeCZVdC9rTYgoNqnjSpEgX9YoWE5PskfuWsUenzRfygjCfBBDBjMZEGwUcrXNvPkEA1TM9WotT4GEZ7ebLpYQyA9Zr"} ]'
Where the arguments are the public keys, and the proof of possession argument, of each of Alice, Bob and Charlie. If one of the participants has not revealed their public key before this step, they would have to share their individual POP proof via an offchain channel. The command results in an aggregated tz4 address, whose public key and public key hash are:
{ "public_key":
"BLpk1xq2ihLjsxccmdTsgi1YKWQb1khbwYKx5xhbdNG67HwQJ5nAuyLXBe9pJyjFRWizN7t6EHN4",
"public_key_hash": "tz4WZtJkSbbboha3UrmpPPSkon7aTU82iWK3" }
Thus multisig_baker (tz4WZtJkSbbboha3UrmpPPSkon7aTU82iWK3) is the native multisig account which will be used to register Alice, Bob, and Charlie’s baker.
The PoP proof for multisig_baker is generated with a dedicated command:
octez-client aggregate bls proofs '{
"public_key": "BLpk1xq2ihLjsxccmdTsgi1YKWQb1khbwYKx5xhbdNG67HwQJ5nAuyLXBe9pJyjFRWizN7t6EHN4",
"proofs": ["BLsigAtXFgXig77LPp8gK3JQtL76cGBChTT5X3QoNNZYwNFPa7Es4Q2BZWkXNtg6w423XPi2c3ogb6P5LRsHrxzJJ2pPNNhAcJfEQX4KGptTr6aWoAPTxz5Q6tKyBDPLaw8eefU7Mh2qVx", "BLsig9Zs6DqTNxraNpmMm4zffuY5qMu7LJCDWJAT5p2VSQS9QdGn7uG8abCjLn7XDYoSsb8TPFqPtZqgvgTQc51uzAXTarHvvKVawwbJ2w2VEhzfujbsPHBAt1nxykHVRLkShtydoNJCKz", "BLsig9up2svWi1CJj8xa3QUFRvLeJxLdH4PiVVXKaP572aDdJrFXuhQ3Yd6jppRx4e2SqR7QmhbwKbdRNpyFU1JnbfeLhoxUwHKk3Ugk9HSysPi6cwfNToJPrfjREGmZPmbaJGWAbFwx4V"]}'
Where each of the signatures in the proofs field need to be collected offchain from Alice, Bob and Charlie (see full steps here). The resulting aggregated proof is:
BLsigB5hTBLmpDGjHCuH3Zs9PYEapHBwQ4bhfzAuQ1Vaoszn1Ec3JBdJiMG4FoZ2EwaHyGjHvU8hgtwBTcYntaShV2Kj4uVFbfEoV5wLEQXYXTCeiuYk9DUQtK6a3aY8sHhumXbzHhS8MW
After distributing the aggregated proof back to Alice, Bob and Charlie, they are now ready to start operating with their 3-of-3 native multisig account.
See here for the complete instructions for this step.
2. Revealing the public key of the native multisig account
The process to reveal the public key for multisig_baker is similar to the one above for the threshold signing scheme: the key difference being the use of a different set of signing commands to aggregate signatures.
Again, Alice will start with a suitable JSON encoding of the reveal operation, using the public key and the aggregated proof from the previous step:
{ "branch": "BLWiohjhRT4kBi9b2RQXVixWwZxLWBvirPt72bYau11YaNdJxgi",
"contents":
[ { "kind": "reveal",
"source": "tz4WZtJkSbbboha3UrmpPPSkon7aTU82iWK3", "fee": "734",
"counter": "7650", "gas_limit": "3250", "storage_limit": "0",
"public_key":
"BLpk1xq2ihLjsxccmdTsgi1YKWQb1khbwYKx5xhbdNG67HwQJ5nAuyLXBe9pJyjFRWizN7t6EHN4",
"proof":
"BLsigB5hTBLmpDGjHCuH3Zs9PYEapHBwQ4bhfzAuQ1Vaoszn1Ec3JBdJiMG4FoZ2EwaHyGjHvU8hgtwBTcYntaShV2Kj4uVFbfEoV5wLEQXYXTCeiuYk9DUQtK6a3aY8sHhumXbzHhS8MW" } ] }
Next, Alice will gather the signature shares from all participants, and proceed to aggregate them into a single signature for the multisig account:.
octez-client aggregate bls signatures '{
"public_key": "BLpk1xq2ihLjsxccmdTsgi1YKWQb1khbwYKx5xhbdNG67HwQJ5nAuyLXBe9pJyjFRWizN7t6EHN4",
"message": "0369721d5757159f1c8b31b0bf4321acf250dfcbafc643396277b2dfe48abfd37b6b03ec869b2bf20b048fac696cf8e43b892f68fc06c3de05e23bb2190003b2c32aec20e8dd216d85a8a3a39e3f7228940dcd5f1b08e3c792af78fdfaf400a2e61b42a42d3b3260b557e73adcca2bff00000060a88ad3dc148d9db0e88944f4e5d6bd4668b3ab18e9663036d1c8aad94afcadac23aeff3de8de596d97c5069e1cb718c410093ae86c85553d6eb9bbc967d0d54df5d58769950e26616c77cc0521058be5bf9a58b11fa887ee6ec1e94d311e76b2",
"signature_shares": ["BLsigAsiv2ZStmEnt3xFDE41g8p6aM1M7Lfqh4bicG9d8dUhDqhAfbHwAzftq4yQpX4dPjGfsJwUBJHktkRhqT4x5H6JcgrCpjGSUMSct6YFCXoKXg12kk3E5H4YiB3k4NaVXwcjgKZiQr",
"BLsigAAbmUJnNtLrJU2kfstfSn6WM14efZzd3Pi6rHefJS7pnBYykyNwnq7QxsyrwPsU9yujRwr3tfUFfAvWKc13NQz3P3XGPtKEwcrbhpimKgcbbFeb83c5EdAbYrfeBaRwFdnBhrmJnz",
"BLsigApoZ6XvdVdiVr3U45ThBz1MFNKT63Df7LWhD9v4cd9xW7evzfXqNKqdEm44jLKxTJFYSbn9xFrc49ZHDCxQT1oJHFLpgp4UU5ERasehZ845xv8g9QtQjToqTffsAMT6MFgmbosNZr"]}'
The resulting signature is BLsigBhaSDeJFF3STADKzizRQRp4JXRPH9g43RZDpm8V1sdZ8BRvuJYU8iQRAqr7tq7uPHfdBGDwHxPi8JdMNxSuVBsG6diBscWnEdsX7qWHmTtyE6W1WoYNZC9hLTBRQYVFRcxrk5ti4s. Alice will use this signature to forge and inject the operation for the multisig account.
The complete instructions for this step can be found here.
3. Registering the native multisig account as a baker with a separate consensus key
Having revealed multisig_baker‘s public key, Alice, Bob and Charlie will set up their baker using this key as the baking (manager) key. In this kind of setup, they also want to set up a regular consensus key, stored elsewhere. We assume they have chosen a tz1eQp2xBUykz2CWzq9DfwKW3xiHvdpr4ZN7 as consensus_key.
The participants will repeat the process to forge, sign and inject an operation from the previous step, starting with a valid unsigned JSON encoding for a manager operation batch grouping a delegation and an update_consensus_key operation:
{ "branch": "BMew8CWTj2urtnA12UJzkDtwzMt7Lz6hEBbEDjg4jzoVF5Zkvih",
"contents":
[ { "kind": "delegation",
"source": "tz4WZtJkSbbboha3UrmpPPSkon7aTU82iWK3", "fee": "449",
"counter": "7653", "gas_limit": "1676", "storage_limit": "0",
"delegate": "tz4WZtJkSbbboha3UrmpPPSkon7aTU82iWK3" },
{ "kind": "update_consensus_key",
"source": "tz4WZtJkSbbboha3UrmpPPSkon7aTU82iWK3", "fee": "183",
"counter": "7654", "gas_limit": "200", "storage_limit": "0",
"pk": "edpkvCFH51mtA7aqaoB4DWLqnchQp8m7xdZg7cs58SNqkuEoCuWu1x" } ] }
The complete steps to forge, sign, and inject the operation batch can be found here.
4. Staking with the native multisig account
The last step to successfully setting up the multisig baking account is to make an initial stake with the baking key. Here, Alice, Bob and Charlie will make an initial stake of 35k tez — more than enough to cover the minimum requirement of 6k tez of baking power in order to get consensus rights.
Alice will repeat the process above, starting with the JSON encoding of a stake pseudo-operation (indeed, stake/unstake operations are implemented internally as transfers from the sender to itself using specific entrypoints):
{ "branch": "BL8139at3YrewSZY9JQ4bCXQrUhCTKEyAjneZT4eULdf4hszfxL",
"contents":
[ { "kind": "transaction",
"source": "tz4WZtJkSbbboha3UrmpPPSkon7aTU82iWK3", "fee": "1000",
"counter": "7655", "gas_limit": "5134", "storage_limit": "0",
"amount": "35000000000",
"destination": "tz4WZtJkSbbboha3UrmpPPSkon7aTU82iWK3",
"parameters":
{ "entrypoint": "stake", "value": { "prim": "Unit" } } } ] }
The complete steps to forge, sign and inject the operation can be found here.
Alice, Bob and Charlie must, at this point, make sure their Octez baker (or other alternatives) are properly deployed, and is set to run with the expected consensus key: tz1eQp2xBUykz2CWzq9DfwKW3xiHvdpr4ZN7.
Summary
In this post, we have given an overview of how our upcoming S protocol proposal expands user accounts with native multisig capabilities, unlocking new opportunities to develop exciting applications on Tezos L1.
Indeed, we have provided 2 use-cases which correspond to long-standing requests by different community actors. But we are sure that other applications can, and would likely follow.
We look forward to building them together!
Online Appendix: Native User Multisigs - Appendix
