Summary
docs/src/DEPLOYMENT.md already covers parameter selection (now backed by real analysis in V1_MAINNET_PARAMETERS.md, #190), the deploy sequence, and an admin runbook (key rotation, pausing, resolver rotation). All of it is written testnet-first: every CLI example uses --network testnet, the only worked example uses throwaway resolver1/resolver2/resolver3 test identities, and the doc's own opening line is "this is testnet-only until audited."
What's still missing is the mainnet-specific operational layer: how do you actually run this with real value at stake, not just how do the contract calls work.
Scope
- Key custody guidance for the admin and resolver roles specifically for a mainnet deployment: hardware wallet or multisig expectations, who holds keys, what happens if one is lost or compromised, cross-referencing
V1_MAINNET_PARAMETERS.md's existing "reachability and independence" resolver-composition guidance rather than duplicating it.
- A concrete go/no-go launch sequence that ties the existing "Mainnet readiness checklist" items together into an actual procedure: what order to do things in, who signs off, what the rollback plan is if something goes wrong in the first hours/days after launch.
- Incident escalation specifics for a mainnet context: who gets paged, how fast, and what the decision tree looks like for choosing between
set_paused and a resolver-committee rotation versus doing nothing and waiting for the normal dispute flow to work.
- This should be additive to
DEPLOYMENT.md (a new section, or a linked mainnet-specific companion doc, the assignee's call), not a rewrite of the existing testnet-focused content, which stays correct and useful as-is.
Proposed approach
Not prescribed. This is explicitly prep work written ahead of the actual audit clearing (the hard blocker per SECURITY.md), the same way V1_MAINNET_PARAMETERS.md was written ahead of live testnet data being available: useful to have ready rather than written under time pressure once the audit finishes. It should say so explicitly wherever it lives, so nobody mistakes its existence for a signal that mainnet deployment is currently authorized.
Summary
docs/src/DEPLOYMENT.mdalready covers parameter selection (now backed by real analysis inV1_MAINNET_PARAMETERS.md, #190), the deploy sequence, and an admin runbook (key rotation, pausing, resolver rotation). All of it is written testnet-first: every CLI example uses--network testnet, the only worked example uses throwawayresolver1/resolver2/resolver3test identities, and the doc's own opening line is "this is testnet-only until audited."What's still missing is the mainnet-specific operational layer: how do you actually run this with real value at stake, not just how do the contract calls work.
Scope
V1_MAINNET_PARAMETERS.md's existing "reachability and independence" resolver-composition guidance rather than duplicating it.set_pausedand a resolver-committee rotation versus doing nothing and waiting for the normal dispute flow to work.DEPLOYMENT.md(a new section, or a linked mainnet-specific companion doc, the assignee's call), not a rewrite of the existing testnet-focused content, which stays correct and useful as-is.Proposed approach
Not prescribed. This is explicitly prep work written ahead of the actual audit clearing (the hard blocker per
SECURITY.md), the same wayV1_MAINNET_PARAMETERS.mdwas written ahead of live testnet data being available: useful to have ready rather than written under time pressure once the audit finishes. It should say so explicitly wherever it lives, so nobody mistakes its existence for a signal that mainnet deployment is currently authorized.