Para’s No-Exit Problem
This is a follow-up to The Custody Illusion, which argues that Para’s pregenerated wallet mode is custodial by design despite being marketed as non-custodial. That essay covered the architectural failure. This post covers a separate problem that compounds it: the architecture has no clean path back to user custody, which makes the integrator’s custodial position permanent.
There is a structural reason the custody problem is sticky, and it goes beyond the initial integration decision.
For an end user to claim true custody of a pregenerated wallet - to export their private key, import it into a standard wallet, and leave the platform - they would need to interact with Para’s client-side key reconstruction flow. That flow requires the Para API key to be exposed in the browser as a public environment variable. The same API key authenticates signing for every wallet on the platform. Exposing it client-side leaks it to anyone who opens browser developer tools.
There is no server-side-only path in Para’s SDK to reconstruct and hand over a standard private key from a pregenerated wallet without this client-side credential exposure. The pregenerated architecture has no clean exit path back to user custody. Users who enter the system through pregenerated wallets are structurally locked in.
This matters for the custody question because it means the integrator is not just custodial today - they are custodial permanently, with no technical path to transition users to self-custody without either exposing platform-wide credentials or migrating to a different wallet provider entirely. The decision to use pregenerated wallets is, in practice, irreversible within Para’s architecture.
The architectural contrast with enclave-based providers is sharp. An enclave-based provider can offer a server-side key export flow - an OTP sent to the user’s email, verified with expiry and attempt limits, returning a standard private key. The entire flow happens server-side with no platform credential exposure. The architecture that claims to be non-custodial has no clean path to return custody to the user. The architecture that can be genuinely non-custodial does.
The lock-in changes the shape of the integrator’s decision. A custody architecture that could be unwound at any time is a tactical choice. A custody architecture that cannot be unwound is a strategic commitment to remaining a custodian - and to carrying every regulatory, liability, and trust implication that follows - for as long as the platform continues to serve those users.