Disaster recovery

Guides

Disaster recovery

Use the client-controlled Share B + Share C quorum to recover one native TRX or standard TRC-20 transfer without BroSettlement participation when the normal A+B signing path is unavailable.

Recovery model

BroSettlement MPC uses a 2-of-3 threshold:

ShareNormal locationRole
Share ABroSettlement infrastructureParticipates in normal A+B transaction signing
Share BClient Co-SignerThe client share used in normal signing
Share CSeparate client-controlled offline custodyRecovery share; it must not remain on the active Co-Signer

Normal signing uses A+B. Disaster recovery temporarily combines B+C, which can create a valid threshold signature without Share A or any BroSettlement API.

Never store B and C in the same host, filesystem, disk, vault, cloud account, backup set, recovery medium, or administrative domain outside the short recovery ceremony. Never provide either share to a third party.

Supported recovery scope

The public brosettlement-disaster-recovery skill currently supports:

  • exactly one native TRX or standard TRC-20 transfer per invocation;
  • TRON Nile testnet or TRON mainnet;
  • exact source-address discovery in the bounded m/44'/195'/0'/0/index range;
  • authenticated Share B + Share C artifacts produced by the same MPC/DKG session;
  • public TRON RPC transaction creation, local threshold signing, mode-600 signed JSON output, signature verification, and immediate broadcast.

The optional token-contract address selects TRC-20; when omitted, the transfer uses native TRX. The skill does not support arbitrary smart-contract calls, other chains, routine withdrawals, or sign-only/offline output. It does not call BroSettlement API or Console and does not require API credentials.

Prerequisites

Prepare an authorized operator, an approved recovery procedure, a clean client-controlled host with Go 1.24 or later, and an encrypted temporary workspace outside cloud-sync folders.

You also need the immutable Share B .primary.json artifact, matching Share C .recovery.json artifact, original 32-byte share-encryption key, source and destination TRON addresses, exact amount, selected network, and a new absolute output path. For TRC-20, also provide the token smart-contract address and an explicit maximum TRX fee limit.

Share B, Share C, and the encryption-key file must be distinct regular files with mode 600. Do not paste their contents into an AI chat, command argument, log, ticket, email, or shared drive. Give the agent only their absolute local paths.

Recovery procedure

  1. Install all three Agent Skills and activate $brosettlement-disaster-recovery.
  2. Confirm that this is an intentional recovery operation because normal A+B signing is unavailable or unsuitable.
  3. Keep B and C with separate custodians or in separate trust domains until the final execution window. Disable screen sharing, session recording, shell tracing, cloud sync, and third-party access.
  4. Provide only the non-secret transaction values and absolute local paths. The skill verifies the pinned Go module, builds a private temporary binary, checks file metadata, and confirms that the output path does not exist.
  5. Review a final summary with the network, source, destination, exact amount, and output path. Explicitly confirm that exact transfer. For mainnet, this moves real funds and the broadcast cannot be undone.
  6. The CLI runs exactly once. It authenticates both artifacts, proves that B+C belong to one quorum, derives and matches the source address, creates and validates the transaction, threshold-signs it, independently verifies the signature, saves the signed JSON, and broadcasts it.
  7. Accept success only after BROADCAST_ACCEPTED, all validation flags are true, and a public txId is returned. Preserve the signed JSON for audit evidence, then close the ceremony and separate B and C.

Any change to the network, source, destination, amount, or output path requires a new explicit confirmation.

Source-only CLI

The skill bundles recovery-tron-sign.go, go.mod, and go.sum:

bash
go run ./recovery-tron-sign.go \
  --network <nile|mainnet> \
  --source <SOURCE_ADDRESS> \
  --to <DESTINATION_ADDRESS> \
  --amount <TRX_AMOUNT> \
  --output </ABSOLUTE/PATH/TO/NEW-SIGNED-TRANSACTION.json> \
  --share-b </ABSOLUTE/PATH/TO/SHARE-B.primary.json> \
  --share-c </ABSOLUTE/PATH/TO/SHARE-C.recovery.json> \
  --encryption-key </ABSOLUTE/PATH/TO/share-encryption.key>

For a TRC-20 transfer, add:

bash
  --token-contract <TRC20_CONTRACT_ADDRESS> \
  --fee-limit-trx <MAXIMUM_TRX_FEE>

--token-contract is optional. Without it, the CLI transfers native TRX. With it, the CLI reads the standard token's public decimals() and balance, simulates the exact transfer(address,uint256) call, and constructs it through the selected public TRON RPC.

The CLI rejects relative protected-input paths, symlinks, non-600 inputs, mismatched artifacts, a source-address mismatch, an existing output file, malformed amounts, insufficient native TRX or token balance, an invalid RPC transaction, or a failed signature.

Success and failure handling

A successful result contains status: BROADCAST_ACCEPTED, derivedAddressMatch: true, artifactsMatch: true, signatureVerified: true, broadcastPerformed: true, broadcastAccepted: true, the expected transaction fields, and a non-empty txId.

The signed JSON is written before broadcast. If execution fails after that file appears, do not rerun blindly. Preserve it, inspect only its public transaction fields, and check the txID on the matching TRON explorer. Every retry needs a new output path and a new transaction-specific confirmation.

Close the ceremony

  1. Stop all recovery processes and remove the temporary binary.
  2. Remove or unmount each local share from the recovery host without deleting the authoritative backups.
  3. Return B and C to separate trust and administrative domains.
  4. Destroy the encrypted temporary workspace key or ephemeral environment under the client's approved procedure. Do not rely on secure-deletion claims for SSD media.
  5. Confirm that B and C are no longer co-located and that no third party retains access.

Do not weaken a cryptographic, artifact-binding, address-binding, or signature check to complete a recovery.