How we think about Security at Para
Para is a security company. Wallet infrastructure happens to be what we build with that focus in mind. The ordering matters, because it explains a number of decisions that look like over-engineering from the outside.
Four years into building wallets and key management, now supporting 15M+ end users across hundreds of customers, here is what we have chosen to hold on to.
1. A whole private key never exists on Para's infrastructure
Para is non-custodial. Distributed MPC splits key material across parties, so a complete private key is never assembled during signing or recovery — not on our servers, and not on the user's device.
There is no key for us to lose control of, because there is no moment at which a whole one exists on Para's infrastructure. The same guarantee holds whether signing happens on web, mobile, or a server.
The only time a full key materializes is if a user explicitly exports it, and that happens on their device, never on our servers. For a full explainer on MPC, read our blog post.
2. Account data stays inside Para's systems
Anyone signing into an app built on Para does so with an email address or a phone number, and that identifier has to exist somewhere for login, recovery, and support to function.
Para stores this information, and we control how it is exposed. Account-identifying information never leaves our systems for analytics, tracking, or data tools. Anything that crosses that boundary carries a UUID instead, so downstream services get an opaque identifier with no path back to a person.
3. Fewer things in the critical path
The same instinct governs what we are willing to depend on. Every vendor in the critical path is code we do not control, credentials we have to manage, and an organization whose security decisions quietly become ours.
So we keep external dependencies to a minimum, and we build critical components in-house even when integrating a vendor may be faster. That costs engineering time. We pay it because a dependency our customers cannot audit is a risk they cannot measure.
4. Audits that cover time, not moments
Claims like the ones above are only worth what an outside party can verify. Para is SOC 2 Type II compliant, an audit that examines controls operating over a period of time rather than at a single moment, and we put our cryptography and infrastructure through regular independent security audits.
Running a review yourself
None of this is a philosophy we arrived at recently. Before Para, our team built software that banks ran their most sensitive data through, and that work leaves you with defaults that are hard to switch off.
Those defaults are also a reasonable place to start if you are evaluating Para or other wallet infrastructure. The questions worth asking:
- How are private keys reconstructed?
- Where do account identifiers live and who else receives them?
- How many external services sit in the critical path when something goes wrong?
- What has been audited, by whom, and over what period of time?