Plan MPC wallet authority, signing, and recovery

Before you start.

Set up your workspace

Start with the public MPC wallet explorer and an existing record when available. Use the exact operational-readiness operation for that wallet. For the import-network read below, use a principal with wallets:read; its output answers import choices only.

Examples are illustrative test plans, not customer results. Use only agreed access and non-production material.

Make the first read, then interpret it.

GET /api/v2/wallets/token-import-networks

Use a trusted terminal and a scoped, non-production read credential supplied by your approved credential manager. The command sends the authorization header through standard input, not a literal token in the command. Do not enable shell tracing or paste the response into a public report; returned metadata may be private.

# Your approved credential manager must set HC_GUIDE_TOKEN first.
: "${HC_GUIDE_TOKEN:?Set a scoped test credential in this trusted terminal}"
printf 'Authorization: Bearer %s\n' "$HC_GUIDE_TOKEN" | \
  curl --fail-with-body --silent --show-error --header @- \
  'https://api.hybrid-chain.com/api/v2/wallets/token-import-networks'

Read the response deliberately

• Record the intended network independently of import eligibility.
• Use a real returned public wallet identifier for the operational-readiness evidence route, not an address guessed from a screenshot.
• Keep enrollment, readiness, approval, signature, broadcast and settlement as distinct worksheet columns.

Request paths, authentication modes and named response fields were checked against the published OpenAPI contract. Values are deliberately not filled with a fake live response. Follow the operation links for current schemas and errors.

The workflow at a glance.

Work through one useful case.

A treasury team wants to evaluate a wallet for supplier payments. Before a funded test, it must explain who can propose, who can authorize, which participants sign, and what happens if a required participant is unavailable.

Keep one working record throughout

Choose one proposed test-network treasury transfer. Create an authority table with requester, business approver, policy administrator, signing participant, recovery owner and evidence reviewer as separate rows. The table describes responsibilities—not a prescribed threshold or a signing topology.

1. 01

   Draw the authority map before choosing a threshold

   List who can request an action, change a policy, approve it, participate in signing, and initiate recovery. Record the separation between customer authority and infrastructure operation. Use the actual configured threshold; a conceptual diagram is not evidence of a particular signing topology.

   Do this

   1. Fill the six authority rows with accountable roles or mark them unassigned.
   2. Add who can replace each role and which recovery procedure changes the trust boundary.
   3. Have an operator and reviewer independently explain the path from a request to a signature using the actual deployment.

   Expected result

   The map separates business approval, administration and signing participation before any threshold discussion.

   If your result is different

   If every row says administrator, ask which exact authority each role exercises. A shared label cannot establish separation of duties.

   Result: Each decision has a named owner and there is no implied single role with unlimited authority.

2. 02

   Pin the wallet, network, and intended operation

   Confirm the wallet identifier and deployment with the team. The token-import-network read is useful for its stated purpose—supported import choices—but must not be used as a list of withdrawal-enabled networks. Never infer a chain from an address alone.

   Do this

   1. Write the wallet generation, network, asset and intended operation at the top of the worksheet.
   2. Inspect the import-network read only for its stated purpose and retain that distinction in your notes.
   3. Open /explorer/mpc-wallets, select an available record and use the documented readiness route for the exact wallet.

   Expected result

   You can identify the precise workflow being reviewed without implying the wallet is active on every compatible chain.

   If your result is different

   If the explorer is empty or a record is unavailable, record that limitation and obtain an authorized test reference; do not manufacture a readiness result.

   Result: The evaluation is scoped to one network and operation, not a generic claim that the wallet is active everywhere.

3. 03

   Review readiness evidence for that exact workflow

   Use the current wallet module and relevant public evidence alongside authorized workspace checks. Distinguish registration, operational readiness, approval, signing, broadcast, and settlement. A public record is inspectable evidence, not a credential that lets the reader perform the action.

   Do this

   1. Record the actual readiness stage and every unmet condition visible to the authorized reviewer.
   2. Put public evidence references beside separately verified workspace authority; do not turn a public URL into a credential.
   3. Assign each missing participant, operation or network prerequisite to its owner.

   Expected result

   The review can say what is inspectable now and what still prevents the intended action.

   If your result is different

   If an active-looking badge conflicts with detailed readiness, retain the detailed evidence and investigate rather than treating the badge as authority.

   Result: The team knows which stages are available and which still require provisioning, participants, or partner controls.

4. 04

   Agree signing and recovery tests before execution

   Define denied-authority cases, unavailable participants, policy changes during review, and recovery after a lost response. Rehearse only through the enabled test workflow. Keep recovery material out of tickets, screenshots, analytics, and public proof records.

   Do this

   1. Write acceptance cases for an ineligible actor, unavailable participant and changed policy.
   2. Agree a test environment and explicit authority before any signing or recovery rehearsal.
   3. Record observed outcomes, including NOT RUN where the stage is unavailable, and reconcile lost responses before any retry.

   Expected result

   The result is a usable authority/recovery test plan with observed evidence where available—not a claimed signing ceremony from documentation alone.

   If your result is different

   Never test recovery by exposing or deleting live key material. Work with the recovery owner using the agreed non-production procedure.

   Result: The acceptance report states observed results and unresolved dependencies without treating wallet discovery as a successful signing ceremony.

Test where the workflow stops.

A useful pilot explains failure as clearly as success. Record what you observed rather than presenting these expected checks as completed results.

Wallet exists but the intended operation is not enabled

Show the unavailable stage explicitly; do not render a misleading transfer action.

A required participant is unavailable

Verify the deployment's documented behavior; do not assume a specific fallback or threshold.

Policy changes while a request is under review

Recheck authoritative state at the relevant boundary; an old approval is not blanket future authority.

A response is lost during an authorized test

Reconcile the authoritative operation state before retrying; avoid guessing whether a transaction occurred.

Your acceptance checklist.

Retain the environment, contract version, test time, redacted observations, unresolved dependencies, and responsible reviewer in your private evaluation report.

Keep the contract close.

These links point to documented operations, not executable controls. Check the current request schema, scopes, errors, and implementation status before using them. No credentials or live customer responses are embedded in this guide.

Read the published OpenAPI definition

Choose your next step.

Keep your worksheet and error notes. Continue with the next technical exercise using the same reference trail, and mark any stage that remains untested rather than treating the checklist as a completed deployment.

Need help with access or an unavailable integration? Contact the team with a redacted error and the guide step. Never send credentials or private records.