Everything that decides a transfer sits outside the threshold scheme.

A t-of-n threshold signature scheme protects against key extraction and signature forgery by fewer than t corrupted participants, under its security assumptions. That sentence is the whole guarantee. It says nothing about availability, and it enforces no business policy at all.

It is also conditional on the implementation holding up its end. The 2023 BitForge disclosures showed inadequate Paillier-modulus validation in GG18 and GG20, and incorrect abort handling in Lindell17, either of which could enable key extraction. So ask the provider for its protocol, its implementation version, its security reviews and its remediation status, by name. Those answers tell you whether the floor holds. Everything that decides where a transfer actually lands is built on top of it.

Policy has to bind to the transaction

Every permitted signing quorum needs an independent policy check bound to the exact transaction or message being signed. A policy-checking co-signer protects nothing if some other quorum can go around it.

On Ethereum the check has to understand what it is looking at, and the shapes differ:

• An ERC-20 transfer in a direct call puts the token contract in transaction.to. The recipient and the amount are in calldata.
• approve takes a token, a spender and an allowance. Once it lands, that spender moves tokens with no further MPC signature from the owner, so one approval signs away every transfer inside that allowance.
• transferFrom takes a token, a source, a recipient and an amount. The spender is the caller in the token's execution context, and never an argument you can read off the calldata.
• A contract call may not reveal its outcome from calldata at all. That needs contract-specific controls and, where it is warranted, execution simulation that accounts for proxies and state changes.
• An EIP-2612 permit authorizes an allowance through a signature, with no transaction from the owner, and anyone can submit it afterwards. Validate the domain, owner, spender, value, nonce and deadline.

Allow-list activation delays run through that same policy check, and a signing request whose meaning cannot be validated safely is refused.

Rotation that does not revoke

Refresh replaces the shares and keeps the key. Resharing redistributes the same key among a different set of participants, possibly at a different threshold, without ever reconstructing it.

Neither revokes a sufficient compatible set of old shares. Proactive protection needs fresh randomness, secure erasure, and the attacker's access actually removed. Update and verify the backups against the recovery design before retiring the obsolete copies.

Where an attacker may already hold enough compatible shares to recover the key, rotation is the wrong operation. Generate a new key and migrate the assets.

A child key can expose its parents

On secp256k1, hardened BIP32 derivation is possible inside MPC, though not every implementation offers it. With non-hardened derivation, a child private key together with the parent xpub and the child index yields the parent private key. An ancestor xpub extends the same exposure along a fully non-hardened path, so exporting one child key can expose a whole subtree above it.

On Ed25519, SLIP-0010 supports hardened derivation only, and MPC implementations differ in how they honor it.

The provider is inside the regulatory perimeter

Under DORA the thing to classify is the contracted service. The provider's own status does not settle it. Standalone MPC infrastructure may qualify as an ICT service; regulated custody with an ICT component inside it may need different treatment.

Applicable ICT arrangements go in the register of information. Where they support a critical or important function, DORA requires documented exit plans that are sufficiently tested and periodically reviewed.

The recovery test

Use a small test vault on an independent root key. Keep a sufficient recovery set, the decryption credentials, the derivation metadata and signing tools that are compatible with the format.

Recovery may hand back a signing scalar where the tooling expects an RFC 8032 seed, and a scalar cannot be imported through a seed-based interface. Recovery tooling has to support the format the key is actually in, and generate nonces safely for it.

Then recover without touching the provider's platform: verify the addresses that come out, and put a transaction through on each supported chain type. If the recovery reconstructs a production private key, that key is now potentially exposed, and the assets move to a fresh one.