The Custody Illusion: How MPC Wallets Sell Security Theatre
Multi-Party Computation wallets are marketed on a simple, compelling premise: no single party ever holds the complete private key.
In MPC a private key is split into shares and distributed across independent parties. The underlying cryptographic protocol produces valid signatures without ever reconstructing the original key. The user holds one share. The wallet provider holds another. Neither can sign alone.
The cryptographic protocols behind MPC are real and sound. However in some instances, integrators are engaging with an illusion of security. The problem is not with MPC as a cryptographic primitive - threshold signing schemes are well-studied, formally verified, and do exactly what they claim - the problem is with the assumption that using a secure protocol produces a secure system.
A protocol defines what happens when the inputs are held by the parties the protocol assumes - it says nothing about what happens when those inputs end up somewhere the protocol did not anticipate. And this is concerning because in the fastest-growing segment of MPC wallet usage - server-side signing for AI agents, automated workflows, and non-custodial platforms - credentials and security boundaries are being shifted.
This essay examines how one MPC wallet provider, Para, has structured a product where the cryptographic protocol remains intact, the vendor remains non-custodial, and the integrator unknowingly assumes full custody liability - paying for security properties they do not receive. The argument generalises beyond Para, and the the pattern it represents risks becoming an industry norm.
How MPC Wallets Are Supposed to Work
A 2-of-2 MPC threshold signing scheme splits a private key into two shares at generation time. To produce a valid signature, both shares must participate in an interactive protocol. The full key is never reconstructed - not at creation, not at signing, not at any point in the lifecycle. Each share is useless in isolation. The security guarantee is that no single party can sign unilaterally, because no single party holds sufficient key material.
For this guarantee to hold, the shares must be held by genuinely independent parties with independent security boundaries. In the standard consumer wallet model, this means:
- Share 1 (the “user share”) lives on the end user’s device, inside a hardware secure enclave (Apple Secure Enclave, Android Keystore, TPM), gated by a biometric passkey. The user must physically authenticate to release their share into the signing protocol.
- Share 2 (the “cloud share”) is held by the wallet provider’s infrastructure. The provider contributes their share only when the user initiates a signing request.
Neither the wallet provider nor the application developer can sign without the user’s participation. The user cannot sign without the provider’s infrastructure. This is the model that justifies the “non-custodial” label, and when implemented correctly, it delivers genuine security: even a complete compromise of either party’s infrastructure is insufficient to produce a signature. However a more correct term would be “partial-custody”. “non-custodial” is just the solo perspective of the cloud wallet provider.
The critical observation is that this guarantee is a property of the deployment architecture, not the protocol. The MPC protocol will faithfully execute regardless of who holds the shares. It does not check whether the “user share” is actually held by a user. It does not verify that the two parties are independent. It runs the math. If both shares are present, it signs. The security boundary exists only if the shares are held by parties with genuinely separate infrastructure, separate credentials, and separate incentives. Remove that separation and the protocol still runs - but the security guarantee evaporates.
Para’s Two Modes
Para provides embedded MPC wallets built on a 2-of-2 threshold signing scheme. Their marketing says: “Non-custodial by design: Private keys are split via MPC between the user’s device and Para’s secure infrastructure. Neither Para nor your application ever holds complete keys.”
This claim is accurate - for one of Para’s two advertised modes of operation.
Mode 1: Client-side wallets. The user share lives on the end user’s device in a hardware secure enclave, gated by a passkey. The cloud share is held by Para. Neither the application developer nor Para can sign without the user’s biometric authentication. This is the mode the marketing describes, and it delivers genuine non-custodial security.
Mode 2: Pregenerated wallets. The server creates wallets via Para’s API, retrieves the user share programmatically, encrypts it, and stores it in its own database. At signing time, the server retrieves and decrypts the share, injects it into Para’s SDK, and triggers the MPC signing protocol. Para’s documentation explicitly provides this pattern, complete with a SQLite schema example for a keyShares table and AES-GCM encryption guidance. This mode is designed for server-side operations - AI agent wallets, bulk onboarding, automated workflows - use cases where the end user is not present to authenticate.
The problem is that Mode 2 is custodial by design. The application server holds the user share and the API key that authenticates it to Para’s signing service. Together, these give the application unilateral signing authority - it can trigger the full MPC protocol for any wallet, at any time, without any user interaction. The MPC ceremony still runs. Both shares still participate. The full key is still never reconstructed. But the security boundary that MPC is designed to provide - two independent parties, neither of which can sign alone - is collapsed, because both inputs needed to initiate signing are collocated in the integrator’s infrastructure.
The non-custodial properties that justify MPC’s existence - user-held shares, passkey gating, hardware enclave isolation - do not apply to mode 2. What remains is a remote co-signing service: the integrator sends the user share, Para contributes the cloud share, and the protocol executes. The cryptography is correct. The system is not secure.
In this sense, Para’s claim, and mode 1 acts as misdirection for a violation of the security model in mode 2.
The Collapse
It is worth being precise about what collapses and what does not.
The MPC protocol itself is uncompromised. At no point is the full private key reconstructed. The threshold signing scheme executes correctly. If you are evaluating Para’s cryptographic implementation, there is nothing wrong.
What collapses is the security model that the cryptography is supposed to enforce. In a 2-of-2 scheme, the security guarantee is: two independent parties must cooperate, and neither can act alone. In the pregenerated wallet flow, the integrator holds the user share in its database and the API credential that authenticates it to Para’s cloud share. The “two independent parties” are: the integrator’s application server, and Para’s signing service which the integrator’s application server can invoke at will. The cooperation requirement is met by a single HTTP call from a single environment. The independence assumption is violated by construction.
An attacker who compromises the integrator’s server environment gets three things from the same place: the database credentials (to read encrypted user shares), the encryption key (to decrypt them), and the API key (to authenticate to Para’s signing service). With all three, they can sign arbitrary transactions for every wallet the platform manages. Para’s cloud share completes the MPC protocol automatically on any authenticated API call. There is no second factor, no hardware boundary, no out-of-band approval. The encryption at rest defends only against the narrow scenario where the database is exfiltrated without the application environment - a threat model that rarely reflects how real compromises unfold.
The insider risk is equally stark. Any engineer with shell access to the production environment can reproduce the attack manually. There is no approval workflow, no hardware token, no audit trail of who decrypted which share. The question “did any employee ever sign a transaction they shouldn’t have?” is unanswerable from first-party logs.
The custody architecture also creates secondary attack surfaces that would not exist if the application did not hold key material. Because the user share is stored server-side and can be overwritten through the application’s own API, any vulnerability elsewhere in the application - a CSRF bug, a session-fixation flaw, an XSS exploit - becomes a primitive for wallet takeover. An attacker does not need to steal the share; they can replace it. If the application provides an endpoint for share rotation or refresh (as Para’s documentation pattern implies), and that endpoint relies on session authentication without proof-of-possession or step-up verification, then the share can be silently overwritten through any session compromise. The attacker writes their own share into the database, signs transactions using the standard flow, and the platform’s logs show a routine signing operation with no indication that the underlying key material was swapped.
There is a further consequence that is easy to overlook: the blast radius is not confined to the application that faces users. In any architecture where server-side signing is distributed across multiple services - a web application, a background executor, a workflow engine - every service that touches the decryption path carries the same exposure. If the executor service reads the same encryption key and API credentials as the main application, a compromise of the executor is equivalent to a compromise of the application. The custody liability propagates across every service boundary that the share crosses, and in practice, the share crosses many.
The absence of a signing audit trail compounds all of these risks. If the platform cannot reconstruct from its own logs which agent, which workflow, or which operator caused a given on-chain transaction - only that a transaction occurred - then it cannot distinguish authorised signing from unauthorised signing after the fact. For platforms whose product premise is autonomous agent execution, this is not a future concern. It is a gap that determines whether a breach can even be detected, scoped, and disclosed accurately.
A common tell that an integrator has absorbed the vendor’s framing without examining the deployment reality: documentation that describes server-side share storage as a security feature rather than what it is. Statements like “the user share is never transmitted to the browser” sound like a security property. In context, they are an admission that the end user never holds their own key. The framing positions server-side custody as protection - the share is safe because it never leaves the server - when the actual implication is that the user has no custody at all. This inversion of meaning is easy to miss, and it propagates through internal specs, compliance documents, and customer-facing materials if no one stops to ask what the statement actually describes.
The MPC adds latency, complexity, and a runtime dependency on Para’s servers to every signing operation. But it provides no security value that a simpler custodial signing service would not also provide. The integrator is paying for the ceremony without receiving the guarantee.
The Custody Externalization Model
Para’s product is structured so that Para is non-custodial in every configuration, by construction - this is the business model.
The MPC protocol guarantees that Para only ever holds the cloud share. Whether the user share lives on an end user’s device (mode 1) or on the integrator’s server (mode 2), Para’s custody posture does not change. They never hold both shares - so the custody liability is structurally externalised to the integrator.
Para documents the pregenerated wallet for server-side signing pattern, providing examples of the SDK methods to retrieve the user share and database schema for storing it. They walk integrators through encryption guidance. All of this, to make it as frictionless as possible for the integrator to become custodial. Then they market the product as non-custodial - which is true about Para - just not it’s dependants.
This creates several dynamics worth examining:
Para captures revenue from both modes with zero custody risk. They sell the same MPC infrastructure regardless of whether the end result is genuinely non-custodial (client-side) or custodial (pregenerated). Their cost structure and liability profile are identical either way. The integrator’s custody posture is the integrator’s problem.
The marketing creates a halo effect. An integrator using Para’s pregenerated wallets is using a “non-custodial wallet provider.” That phrase appears in the pitch, the docs, the sales conversations. The integrator absorbs that framing and may repeat it to their own customers without realising the non-custodial claim describes Para’s position, not the integrator’s. The engineering team reads the SDK docs. The compliance team reads the marketing page. They come away with different understandings of the same product, and neither is wrong about the part they read.
Para has no incentive to flag the distinction. The pregenerated flow is the easier sell for server-side use cases - AI agents, batch operations, automated workflows. Telling a prospect “this mode makes you the custodian and you will carry the regulatory and liability burden” is a harder conversation than “here’s how to do server-side signing with our non-custodial wallet infrastructure.” The pregenerated wallet documentation describes the mechanics of storing shares. It does not discuss the custody implications of doing so.
If something goes wrong, the blast radius is the integrator’s. A breach that drains wallets is the integrator’s problem. Para’s cloud share was used in the MPC ceremony, but Para did not initiate it - the integrator did, using the user share they stored and the API key they authenticated with. Para’s legal and reputational exposure is minimal. The integrator carries the liability, the disclosure obligations, and the customer trust damage.
None of this is deceptive in a legal sense. Para’s claims are technically accurate. The documentation is there if you read it carefully and understand which party each statement applies to. But the product positioning, the marketing language, and the low-friction pregenerated SDK flow create a path of least resistance that leads integrators into custody without the word “custody” appearing anywhere in the conversation.
The Same Shape in a TEE - Turnkey
The argument so far has used MPC as the primitive. The pattern is not specific to threshold signing. The cleanest demonstration is Turnkey, which uses a different cryptographic primitive - hardware-attested execution - and arrives at the same failure when deployed with default settings.
Turnkey is not MPC. There are no shares. A single private key is generated and stored encrypted inside an AWS Nitro Enclave, and signing happens entirely inside the TEE. The enclave is the trust root. The non-custodial claim therefore cannot rest on “neither party holds the full key” - Turnkey’s infrastructure does, just behind attestation.
The claim rests instead on who can authenticate to the enclave. Authentication is a “stamp”: a signature over the request body, attached as X-Stamp. The marketing model assumes the end user holds their own credential - a passkey in their device’s secure enclave, or an API key they generated client-side. The API-key path is where the failure lives. An API-key stamp is a bare P-256 signature: no origin binding, no domain ACL, no second factor outside the signature itself. Passkey stamps do carry origin binding via WebAuthn, but it is the API key the integrator holds.
When the integrator holds the user’s private API key on the server, three things are true:
- The stamp authenticates as that user. The enclave cannot distinguish a stamp produced by the user’s device from one produced by the integrator’s server. Cryptographically they are identical.
- Every signing activity runs through the Policy Engine. This is enforced architecturally, not optionally - signing is an Activity, and Activities are evaluated in-enclave before any signature is produced.
- The default policy on a freshly created sub-organization is permissive. The sub-org has one root user - whichever entity the integrator designated - a root quorum of 1, and no policies attached. Root users bypass the policy engine when root quorum is met. Under the default configuration, “policy engine runs” reduces to “policy engine evaluates an empty rule set against a root user and approves.”
The net result: a server holding the private API key for a user who is the sole root of their sub-org has unilateral signing authority. The enclave runs and the attestation is valid. The security boundary the architecture is designed to provide - only the user can authorise - is collapsed, because the credential the enclave checks for is sitting in the integrator’s database.
This is the same shape as Para’s mode 2. Different primitive, same failure: the property a reader hears in “non-custodial” - that the user holds the credential authorising signing - is violated, while the narrower guarantee Turnkey literally claims, that the key never leaves the attested enclave, remains intact. The label survives because the marketing claim and the property the integrator thinks they bought are not the same statement.
There is a real difference between the two cases worth naming. Turnkey’s Policy Engine can meaningfully constrain a server-held API key. The integrator can set spending limits, address allowlists, require co-signature from a Turnkey-side approver, or move the API-key user out of the root quorum so policies actually bind it. Para’s mode 2 has no equivalent - once the server holds both the share and the API key, there is no programmable layer between intent and signature. The failure mode is the same. The recovery path is not. Turnkey’s architecture admits a configuration that genuinely binds a server-held credential. Para’s does not.
That distinction matters for what good architecture looks like later in this essay. It does not change what is true in default deployment: an integrator who creates sub-orgs the way the quickstart shows, holds the user’s API key server-side, and ships gets a custodial system marketed as non-custodial. The policy engine being available is not the same as it being applied.
The General Pattern
Para and Turnkey use different cryptographic primitives - threshold signing and hardware-attested enclaves - and arrive at the same custody failure when deployed for server-side signing. The pattern is not a property of MPC, or of TEEs. It is a property of how cryptographic wallet products are being sold to the server-side signing market.
The pattern works like this:
-
A wallet vendor builds a product around a cryptographic primitive that, in its consumer-facing deployment, justifies a non-custodial claim. The user holds a credential - a share, a passkey, an API key - and the vendor’s infrastructure holds the rest. Neither party can sign alone.
-
The vendor identifies a growing market segment - AI agents, automated workflows, server-side operations - where the end user is not present to authenticate. This segment cannot use the consumer flow because it requires a user-held credential.
-
The vendor creates a server-side mode where the application stores or controls the user’s credential, enabling signing without user participation. The vendor documents this mode, provides SDK methods for it, and sells it to the server-side market.
-
The vendor’s marketing continues to emphasise non-custodial properties. This is technically accurate about the vendor - the cryptographic primitive still does what it claims (no party reconstructs the full key, the key never leaves the enclave). The custody implications for the integrator are documented in the SDK reference but absent from the product positioning.
-
The integrator builds on the server-side mode, absorbs the “non-custodial wallet provider” framing, and may repeat it to their own customers. The cryptographic ceremony or attestation runs on every signing operation, adding cost and complexity. The custody liability sits entirely with the integrator. The vendor collects revenue with no custody risk.
The result is a market where integrators pay for non-custodial infrastructure, receive custodial liability, and may not discover the gap until an auditor, a regulator, or an attacker forces the question.
The cryptographic primitive is doing its job. The marketing claim is technically defensible. The deployment configuration is the part that voids the property the integrator thought they bought, and the deployment configuration is exactly what the vendor’s documentation makes the path of least resistance.
Protocol Security Is Not System Security
The deeper lesson is not about Para specifically. It is about a category error that runs through how cryptographic products are evaluated.
A cryptographic protocol defines a set of guarantees given a set of assumptions. MPC threshold signing guarantees that no single party can produce a valid signature, given the assumption that the shares are held by independent parties with independent security boundaries. The protocol is correct. The guarantees hold. And the guarantees are irrelevant if the assumptions are not met.
The pregenerated wallet pattern violates the independence assumption by construction. The integrator holds the user share and the credential to invoke the cloud share. The two “parties” to the MPC protocol are the integrator’s application server and the vendor’s API, which the application server calls programmatically. The threshold scheme executes correctly over a topology that has collapsed into a single trust domain.
The gap between protocol security and system security is well-established. But it is persistently under-appreciated in product evaluation, because the cryptographic properties are easier to verify than the deployment properties. You can audit the MPC implementation - you can formally verify the threshold scheme and that the full key is never reconstructed. However, none of that tells you whether the system is actually secure - because the system’s security depends on who holds the shares and what credentials they have - questions the protocol does not answer.
The practical consequence for integrators, developers, and their customers: when evaluating an MPC wallet product, the protocol is the least important thing to audit. The questions that determine actual security are:
- Who holds each share, and what infrastructure boundary separates them?
- Can the application server unilaterally initiate signing, or does signing require an out-of-band authorisation that the server cannot forge?
- If the application environment is fully compromised, what can the attacker sign? Everything? Nothing? Something bounded by a policy enforced outside the compromised environment?
- Where does the custody liability actually sit, and does the vendor’s marketing match the integrator’s legal reality?
- Can the end user exit the system - export their key, move to another wallet - without exposing platform-wide credentials?
If the answers to these questions describe a custodial system, then the system is custodial - regardless of whether the cryptographic protocol running underneath is non-custodial by design. The protocol does not override the architecture. The architecture is the security model. The protocol is just the math.
What Secure Server-Side Signing Actually Looks Like
If the problem is that server-side signing collapses the security boundary by default, the question is whether any architecture preserves genuine non-custody while supporting signing without user interaction.
The answer is yes, and the key mechanism is hardware-attested policy enforcement - applied, not merely available.
Hardware-attested execution (AWS Nitro Enclaves, similar TEEs) puts the private key inside an enclave and never lets it leave. The integrator’s application server sends signing requests to the enclave but never holds key material. Even a full compromise of the application environment gives the attacker only the ability to request signatures - bounded by whatever policy is configured inside the enclave.
The critical word is configured. The policy is enforced by the same hardware that holds the key, not by the application that requests the signature. The integrator can define rules - transaction value limits, contract allow-lists, rate limits, time-of-day restrictions - and those rules execute inside the attested enclave. The application server cannot bypass them because the application server does not have access to the key. The enclave’s attestation is cryptographically verifiable: customers and auditors can confirm exactly which code is running inside the signing environment.
This architecture gives server-side signing without custody, if two conditions hold:
- The policy bound to the user’s signing key is non-trivial - not a permissive default, not bypassed by a root user the integrator controls. The policy has to actually constrain what a compromised application server can sign.
- The credential authenticating to the enclave is not held exclusively by the integrator. Either the user holds it (passkey on their device, client-generated API key), or the policy itself requires a co-signature from a party the integrator cannot impersonate.
Turnkey’s architecture supports both conditions. Para’s mode 2 supports neither - the user share and API key are collocated in the integrator’s environment, and there is no policy layer between them and a valid signature.
The point is that the tradeoff between server-side signing and non-custodial security is a solved problem in principle, but only when the deployment is configured to deliver it. Hardware-attested policy enforcement is the building block.
Conclusion
MPC wallet vendors that promote server-side signing without enclaves have - in a sense - found a way to sell custody liability as a service while marketing it as the opposite. The cryptographic protocol is real, and the non-custodial claim is accurate - with regards to the vendor. And the integrator walks away carrying full custody risk, paying for infrastructure they do not meaningfully benefit from.
The gap persists because the people evaluating wallet products are often not the same people who understand the deployment implications. The marketing says “non-custodial.” The SDK docs say “store the user share in your database.” Both statements are present in the same product. The first appears on the landing page. The second appears in a tutorial for pregenerated wallets. The compliance team reads one, and the engineering team reads the other.
For integrators building on MPC wallet products: the protocol is the least important thing to evaluate. You can get to answers you need in a fail-fast manner by auditing the deployment topology first. Identify who holds what, and what a full compromise of your environment actually permits. If the answer is “everything” - if a compromised server can sign arbitrary transactions for every wallet on the platform - then you are custodial, and the MPC ceremony running underneath is security theatre.
For consumers and end users: “non-custodial” is not a binary property of a wallet product. It is a property of a specific deployment and underlying protocol. The same product can be non-custodial in one mode and fully custodial in another. Ask not whether the wallet provider is non-custodial. Ask whether you hold your own key. If you do not - if the platform holds it “on your behalf,” encrypted in their database, signed with their credentials - then the platform is your custodian regardless of what protocol they use to sign your transactions.