Cowrie Research

para

4 min read

Para

  • Name: Para
  • URL: https://www.getpara.com/
  • Category: wallet-infrastructure company / embedded-wallet and auth operator / hosted policy-and-money-movement platform
  • Tags: ethereum-ecosystem solana-ecosystem cosmos-ecosystem
  • Summary: Para belongs in companies/ because the useful question is not only how does a 2-of-2 MPC wallet work? but which named operator issues the API keys, configures the developer-portal project, enforces server-side wallet permissions, decides supported network and origin settings, packages recovery around its HSM-held share, and now bundles money-movement rails into the same app-owned wallet shell? The practical leverage lives in the hosted auth, policy, and workflow boundary above the wallets rather than in any standalone account primitive.
  • What it does:
    • Provides embedded-wallet SDKs and APIs across web, mobile, server, and CLI-oriented environments
    • Uses a 2-of-2 MPC design in which the user share stays on-device while the Para share sits in Para-managed cloud HSMs and participates in signing and recovery
    • Combines wallet creation with email, phone, social, passkey, and wallet-based authentication flows
    • Exposes project and API-key workflow through a developer portal that controls environments, supported networks, allowed origins, email behavior, and adjacent security settings
    • Enforces app-specific wallet permissions server-side, with policy versions scoped per API key and expressed to users as readable consent scopes
    • Packages money-movement surfaces such as onramp, offramp, send, bridge, and swap flows alongside the wallet and auth stack
  • Key claims:
    • The current homepage markets Para as The Complete Wallet-As-A-Service Platform and says teams can build with embedded wallets, authentication, and money movement rather than only a narrow signing SDK
    • The current docs welcome page says Para is the most comprehensive wallet and authentication suite for crypto and fintech developers, highlights 100+ teams and 15M+ users, and routes builders through a project-and-API-key setup path in the Developer Portal
    • The developer-portal setup docs say every integration starts with a Para project and API key, then exposes controls for environments, supported networks, allowed origins, email behavior, and security settings, which makes the operator boundary unusually legible in first-party materials
    • The permissions docs say policies are defined per API key, enforced server-side on every transaction, presented to users as plain-language scopes, immutable once published, and default-deny when no rule matches; that is much more than generic MPC wallet marketing
    • The key-management docs say Para uses a 2-of-2 MPC architecture with a user share on-device and a Para share in cloud HSMs, plus DKLS19-based distributed key generation and signing that never reconstructs the key in one place
    • The docs and homepage now explicitly bundle money movement, policy controls, and app-level configuration into the same product, which is exactly why the company boundary does more analytical work than a preserved project note
  • Whitepaper: No classic whitepaper is the point here. The strongest current primary-source packet for the entity split is ../whitepapers/para-company-primary-sources-2026-08-10.md, together with the earlier product snapshot in ../whitepapers/para-primary-sources-2026-04-25.md.
  • Sources:

Internal linkages

  • Project-layer alias: para.
  • Best adjacent company reads: privy, turnkey, crossmint, and openfort.
  • Useful product and substrate contrast: safe and erc-4337.
  • Reusable lens: when an embedded wallet vendor also controls API-key issuance, project configuration, policy publication, recovery workflow, and money-movement packaging, the company boundary often matters more than the signer primitive.

Protocol / company boundary

  • There is not a particularly useful standalone Para protocol boundary doing the analytical work.
  • The reusable lower-layer ingredients are MPC signing, passkey-backed authentication, SDK integration paths, and onchain account systems like Safe or ERC-4337 smart accounts.
  • The thing developers and users actually inherit from Para is the company-run shell around those pieces: project creation, API credentials, permissions, HSM-backed recovery participation, supported-network exposure, origin restrictions, email and session workflow, and the adjacent movement rails Para chooses to bundle.
  • That is why this note belongs in companies/: the key question is who controls the app-owned wallet workflow and policy surface, not whether Para invented a new account primitive.

Control surface

  • Practical leverage sits in project and API-key issuance, developer-portal configuration, supported-network requirements, allowed-origin policy, email and onboarding workflow, and the server-side permission engine that evaluates every transaction before it reaches the MPC signing ceremony.

  • Additional leverage sits in Para’s HSM-held share and recovery path, because a non-custodial claim here still depends on a named operator participating in signing and recovery workflow rather than disappearing entirely from the trust picture.

  • The bundled onramp / offramp / send / bridge / swap surfaces matter because they extend dependency beyond wallet creation into route selection, partner packaging, compliance handling, and default movement rails.

  • Read Para as a company-run signer, auth, and policy control plane, not as the durable account substrate itself.

  • Last reviewed: 2026-08-10 UTC

Graph View

Backlinks