Sign with multisig

Once multisig is set up, every production release runs the same four steps: prepare a request, sign it with a quorum of signers, verify the responses, and commit the production drive. The request and responses are portable — the commit does not have to run on the machine that prepared the request.

Prepare the request

hyper-multisig request <length>

<length> is the current length of the provision Hypercore (from the most recent pear stage output). hyper-multisig refuses to issue a request if the source drive is not healthily seeded — see Troubleshoot multisig if it does.

Sign

Each signer runs:

hypercore-sign <signing request>

and shares the response. Once a quorum of responses exists, the build is ready to verify.

Verify

hyper-multisig verify [--first-commit] <signing request> <response-1> <response-2> ...

--first-commit is required only the first time you commit to a fresh multisig drive. Never commit a request that fails verify.

Commit

hyper-multisig commit [--first-commit] <signing request> <response-1> <response-2> ...

The commit waits for at least two seeders to fully download the multisig drive before signalling success. Watch the output:

Committing the core...
Committed the core (key <target key>)
Waiting for remote seeders to pick up the changes...
Please add this key to the seeders now. The logs here will notify you when it is picked up by them. Do not shut down until that happens.

Once two seeders confirm, it is safe to Ctrl+C.

See also

• Set up multisig — the one-time setup this flow depends on.
• Troubleshoot multisig — request refused, interrupted commits, and INCOMPATIBLE_SOURCE_AND_TARGET.
• Deploy your application — the full eight-step release flow.
• Release pipeline — conceptual diagrams for stage, provision, and multisig.