MPC Threshold Signing

SohoPay agent wallets are not controlled by a single private key. Signatures are produced by multi-party computation (MPC): the key exists as separate shares held by separate parties, and a valid signature requires a threshold of shares to cooperate. This page explains why, how the 2-of-3 scheme works, and what — very little — you need to do about it. It assumes Ethereum key basics but no MPC background.

​

Why MPC

Agents are the most exposed component in the system. They run in cloud environments, hold credentials in memory, and execute code that operators iterate on quickly. If an agent held a complete private key, one compromised container would mean an attacker with full spending power up to the credit limit — or worse, a key exfiltrated and reused later. MPC changes the failure mode:

• No single key holder. The full private key never exists anywhere — not at generation, not during signing. Each party computes over its own share; only the signature is ever assembled.
• Agent compromise ≠ funds loss. An attacker with the agent’s key share can produce nothing on their own. Every signature also requires the Policy Service, which independently checks the allowlist, credit, rate limits, and AML before contributing its share.
• Policy is cryptographically enforced. Rules aren’t a middleware layer an attacker can route around — a payment that fails policy simply never becomes a valid signature.

​

The 2-of-3 threshold scheme

Each agent wallet’s key is split into three shares; any two are needed to sign:

​

Fail-closed design

The scheme is deliberately fail-closed: if the Policy Service is unavailable, no settlements happen. There is no bypass path, no degraded mode where the agent share signs alone. Payments submitted during an outage queue and settle when the service recovers — funds can be delayed, never moved outside policy. Availability is therefore treated as payments-grade infrastructure; see Policy Service and the SLA.

​

Current implementation and roadmap

Today: key shares are protected by AWS KMS — each share is generated and used inside KMS-backed key management, never exported in plaintext. Approved signing operations are recorded in a voucher store, giving an auditable trail of every co-signature the Policy Service issued and the policy decision behind it. Roadmap: migration toward OpenSigner with Shamir’s Secret Sharing–based share management, reducing reliance on any single cloud KMS and enabling the independent third-party share holder.

​

How a signature is created

The lifecycle of one payment signature: The combined result is an ordinary secp256k1 signature — the USDC contract on Base verifies it with standard ecrecover (see EIP-712) and has no idea MPC was involved. No custom contracts, no on-chain multisig overhead.

​

Developer takeaway: you don’t manage MPC

None of this surfaces in your integration. There is no share to store, no signing ceremony to orchestrate, no MPC library to install:

• Creating an agent (POST /agents) provisions the wallet and shares inside SohoPay’s infrastructure — see the Quickstart.
• Paying is a normal API call; in the sandbox you can even pass "signature": "sandbox_auto" and skip signing entirely.
• Rotating a compromised or aging agent key is one API call, covered in Key Management — you’ll receive an agent.key_rotated webhook when it completes.

If you take one thing from this page: the security model above is the reason the API can be this simple, not a burden you inherit. You call the API; the threshold cryptography is SohoPay’s job.

​

Next steps