Sign with multisig
The repeatable multisig release flow: prepare a signing request, collect a quorum of signatures, verify, and commit the production drive.
Once multisig is set up, every production release runs the same four steps:
- Prepare the request
- Sign it with a quorum of signers
- Verify the responses
- Commit the production drive
The request and responses are portable — the commit does not have to run on the machine that prepared the request.
This assumes the multisig drive already exists. If you have not generated signing keys, configured pear.json, and pointed upgrade at the multisig link yet, do Set up multisig first.
Prepare the request
pear multisig request <versioned-provision-link><versioned-provision-link> is the seeded provision link in pear://<fork>.<length>.<key> form — the link from your most recent pear provision. For example:
pear multisig request pear://0.856.q9sopzoqgas9usoiq7uzkkwngm5pzj4zo3n4esjwwbmw6offis8opear multisig request runs safety checks before issuing the request. One of them ensures the source drive is healthily seeded; if it is not, the request is refused — see Troubleshoot multisig. It returns a signing request.
Sign
Each signer confirms the build is the one they intend to release, then signs the request:
pear multisig sign <signing request>and shares the response. pear multisig guards against formal mistakes, but it is up to each signer to verify they are signing the correct build. Once a quorum of responses exists, the build is ready to verify.
Verify
Check for formal mistakes before committing. Run verify first on the request alone, then again with the collected responses appended:
pear multisig verify <source-link> <signing request> [...responses]<source-link> is the provisioned link (a staged link also works). Never sign or commit a request that fails verify.
Commit
Only commit after verifying the request and all responses:
pear multisig commit <source-link> <signing request> [...responses]As with verify, <source-link> is the provisioned (or staged) link. The committer does not have to be a signer — the request and responses are enough to generate the build, which is why pear multisig insists the source drive is well seeded, and why the commit can run on a different machine than the one that prepared the request.
The commit is not safely finished until the new multisig drive's key is seeded by peers. Make sure it is seeding:
pear seed <multisig-link>Once the program detects that at least two seeders have fully downloaded the multisig drive, it is safe to stop it with Ctrl+C.
Do not abort a running commit. An interrupted commit leaves the production build in an intermediate state. See Recover from an interrupted commit before retrying.
To inspect which signing keys and quorum a multisig link enforces:
pear info --multisig <multisig-link>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.