# Architecture Overview Source: https://docs.getpara.com/v2/concepts/architecture An introduction to Para's architecture and core components Para provides a robust and secure architecture for creating and managing universal embedded wallets across various blockchain ecosystems. This overview introduces the key components and features of Para's design, setting the stage for a deeper dive into its technical aspects. ## Core Concepts Para's architecture leverages several key concepts: 1. **Multi-Party Computation (MPC) Key Management**: Para uses a 2-of-2 MPC system for secure key management, comprising a User Share and a Cloud Key. 2. **Passkey**: This separate key leverages hardware secure enclaves while maintaining blockchain compatibility. 3. **Distributed Key Generation (DKG)**: Ensures that the full private key is never assembled in a single location. 4. **Passkeys and WebAuthn**: Implements the WebAuthn standard for enhanced security. 5. **Permissions Framework**: Allows granular control over transaction signing across multiple applications. These components work together to provide a secure, flexible, and user-friendly wallet solution that can be embedded in various applications across different platforms and blockchain ecosystems. ## Explore Para's Architecture Dive deeper into specific aspects of Para's architecture and functionality: Learn about Para's innovative approach to key management using MPC and hardware secure enclaves. Explore the various security features that protect user assets and data in Para wallets. Understand how Para enables secure wallet recovery in case of device loss or other issues. Learn about Para's approach to universal embedded wallets and cross-application experiences. Find answers to common technical questions about Para's architecture and functionality. By leveraging these architectural components and features, Para provides a comprehensive solution for developers to implement secure, user-friendly universal embedded wallets in their applications across various platforms and blockchain ecosystems. # Key Management System Source: https://docs.getpara.com/v2/concepts/key-management An in-depth look at Para's innovative approach to secure key management using MPC and hardware secure enclaves Para's Key Management System forms the core of its security architecture, employing advanced cryptographic techniques to safeguard user assets while ensuring usability across various platforms and blockchain ecosystems. At its heart is a distributed (MPC) system that leverages (DKG) and distributed signing. This innovative approach ensures that user keys are never stored in a single vulnerable location, and neither applications nor Para itself can access users' private keys, providing a robust foundation for secure, non-custodial wallet management. ## Key Components Para's key management system relies on a 2-of-2 MPC system comprised of three main components: 1. MPC Key 1: User Share 2. MPC Key 2: Para Share 3. Passkey ### User Share The User Share is custodied by the user and acts like a hot wallet. It is accessible in the browser or on the user's device, providing immediate control over assets while interacting with crypto applications. ### Cloud Share The Cloud Share is managed by Para and stored securely in cloud hardware-security modules (HSMs). This setup provides a secure off-device backup of the user's key, safeguarding the assets even in the event of device loss or compromise. ### Passkey The Passkey is a unique feature of Para's system, designed to bridge the gap between device security capabilities and blockchain requirements. Most modern smartphones come with hardware secure enclaves, which are dedicated areas within the device's main processor used for storing and protecting sensitive data. However, these enclaves primarily support the secp256r1 elliptic curve, which differs from the secp256k1 curve used by most modern blockchains. To address this, Para generates a separate Passkey. This key is used to authorize access to the Cloud Share, enabling biometric authentication and signing on the secp256k1 curve. This process ensures users can leverage their device's hardware security features while interacting seamlessly with blockchain networks. ## Key Generation and Management Process 1. **Distributed Key Generation**: When a user creates a wallet, Para initiates a DKG process. This generates the User Share and Cloud Share without ever assembling the full private key in one place. 2. **Passkey Creation**: Simultaneously, an Passkey is generated and stored in the device's secure enclave. 3. **Cloud Share Storage**: The Cloud Share is securely stored in Para's HSMs. 4. **User Share Protection**: The User Share is protected by the user's authentication method (e.g., passkey, biometrics) and stored securely on the device. ## Security Benefits This key management system offers several security advantages: * **No Single Point of Failure**: Since the private key is never fully assembled, there's no single point of vulnerability. * **Phishing Resistance**: Even if a user's email or social login is compromised, an attacker would still need physical access to the user's device to initiate transactions. * **Device Loss Protection**: If a user loses their device, they can still recover their wallet using the Cloud Share and proper authentication. * **Censorship Resistance**: Users have the option to export their Cloud Share, ensuring they maintain control over their assets . ## Flexible Backup Mechanisms Para supports flexible backup mechanisms and a key-based permissions system, allowing for customized security setups based on specific application needs. These can be configured in the By leveraging this advanced key management system, Para provides a secure, flexible, and user-friendly solution for embedded wallets, balancing robust security with seamless user experience across various blockchain ecosystems. # Permissions Source: https://docs.getpara.com/v2/concepts/permissions Fine-grained, enforceable control over what applications can do with a user's wallet Para's permissions system gives developers fine-grained, enforceable control over what their application can do with a user's wallet, all while keeping user consent clear, understandable, and revocable. Instead of asking users to grant blanket wallet access, Para enables **policy-based permissions** that are: * Explicit * Scoped * Conditional * Cryptographically enforced server-side This allows teams to ship powerful wallet experiences without compromising on security or UX. ## Why Permissions Matter Traditional wallet models force a tradeoff: * Either prompt users for every action, or * Grant broad signing power with little transparency Para replaces this with a system where: * Apps request only what they need * Users clearly understand what they're approving * Every action is checked against an approved policy before it is signed The result is safer wallets, higher trust, and better conversion. Permissions consent UI showing scopes and policy ## Core Concepts ### Policy A **policy** defines the full set of actions your app may ever request from a user's wallet. Think of this as your app's permissions contract with users. If something is not included in the policy, it cannot happen. Policies are: * App-specific * Explicit * Immutable (changes require an updated policy version) ### Scopes Policies are broken down into **scopes**, which are the user-facing consent items. Each scope: * Appears as a checkbox during onboarding or login * Groups related actions together * Can be required or optional Example scopes: * "Basic wallet actions" (required) * "Automated transfers" (optional) Scopes allow teams to progressively request access as users adopt more features. ### Permissions Behind each scope are one or more **permissions** that describe the exact actions the app can perform, such as: * Signing messages * Transferring value * Calling smart contracts * Deploying contracts Permissions are structured in JSON format, and are only activated if the user approves the parent scope they belong to. ### Conditions Permissions can be constrained with **conditions** that define when an action is allowed. Examples: * Transfers only below a certain value * Contract calls only to allow-listed addresses * Actions limited to specific chains Every request is evaluated against these conditions at runtime. Any permission that evaluates to **False** causes the transaction to be rejected. ## How To Configure Policies in Para ### Step 1: Define Your Policy You start by declaring the full universe of actions your app may need: * Supported blockchains * Types of wallet actions * Any global time bounds (optional) This policy sets the outer boundary of what your app can ever do. ### Step 2: Define Scopes Next, you decide how permissions are grouped and presented to users. For each scope, you define: * A short, user-friendly name * A plain-language description * Whether it is required or optional Scopes should map cleanly to product features, not technical operations. ### Step 3: Attach Permissions to Scopes Within each scope, you specify the concrete actions that scope enables: * Message signing * Transfers * Contract interactions * Deployment Each permission is explicit and narrow by default. ### Step 4: Add Conditions (Optional) You can further restrict permissions with conditions such as: * Value limits * Address allow-lists * Function-level contract restrictions If a request violates a condition, Para blocks it automatically. ## What Users Experience 1. The user sees clear, human-readable consent scopes 2. They approve or decline each scope 3. Para enforces only the approved permissions 4. Any out-of-policy action is rejected before signing There is no silent permission creep. ## Summary Para Permissions enable the following capabilities: * You define intent once * Users give informed consent * Para enforces permissions every transaction * Powerful wallet UX, without third-party control over keys ## Get Started To learn more about permissions or get set up, get in touch with our team at [hello@getpara.com](mailto:hello@getpara.com) # Wallet Recovery Process Source: https://docs.getpara.com/v2/concepts/recovery A guide to Para's secure wallet recovery mechanism Para employs a robust recovery mechanism to ensure that wallet access remains resilient to events such as device loss or phishing attempts. This document outlines the recovery process implemented in Para's infrastructure. ## How Para Enables Recovery Para's recovery mechanism is designed to maintain user access to funds even if they lose access to their primary device. This is achieved through a combination of recovery secrets, backup devices, and multi-factor authentication. The recovery flow is managed through Para's web application, the Para Portal, eliminating the need for individual app developers to implement their own recovery mechanisms. When setting up a Para wallet, two key elements are generated: 1. **A unique recovery secret**: This is shared with the user client-side. The application has the option to store this secret. It's important to note that this secret is not related to the 2-of-2 MPC scheme and is solely used for restoring wallet access in case of device loss or theft. Para does not have access to this secret. 2. **A copy of the Cloud Share**: This is shared with the user in the Para Backup Kit. The Cloud Share is part of Para's two-key scheme, providing strong censorship resistance and protection against downtime. In the event of a lost or stolen device, recovery is possible through two main methods: 1. **Keychain backup**: If enabled, the key (k1) from the old device can be recovered on a new device. Using this key and the recovery secret, the user can add a new Passkey (r1) to Para's allow list. 2. **Recovery secret**: If the user has their recovery secret, they can initiate a recovery attempt via the Para Portal. After successfully adding a new Passkey, Para prompts the user to perform a key rotation. This process generates an entirely new set of keys, enhancing the security of the user's account and protecting against potential unauthorized access to the old keys. Users have the option to add backup devices (such as a laptop or smartwatch) during the wallet setup process. If a primary device is lost, the user can log in from one of these backup devices. From there, they can add new devices and remove lost ones, ensuring uninterrupted access to their wallet. If the user cannot recover their User Share from their KeyChain backup or a secondary device, they can initiate a key rotation using the recovery key. This process includes: 1. Two-factor authentication (2FA) with their phone number or another multi-factor authentication (MFA) method. 2. This additional step ensures the integrity of the recovery process and protects against impersonation attempts. ## Security Measures The recovery process requires multiple forms of verification, including the recovery secret and optional 2FA, enhancing security against unauthorized access attempts. After recovery, a full key rotation ensures that potentially compromised keys are invalidated, providing an additional layer of security. The option to add multiple backup devices provides redundancy and increases the likelihood of successful recovery in various scenarios. ## Best Practices for Users Store the recovery secret in a secure, offline location. Never share this secret with anyone, including Para. Activate two-factor authentication for an additional layer of security during the recovery process. Add multiple backup devices when possible to increase recovery options. Periodically verify the ability to access the account from backup devices to ensure they remain functional. By implementing this comprehensive recovery process, Para ensures that users have a secure and reliable method to regain access to their wallets, balancing strong security measures with user-friendly processes. # Security Mechanisms Source: https://docs.getpara.com/v2/concepts/security An in-depth exploration of Para's robust security features designed to protect user assets and data Para employs a multi-layered approach to security, incorporating various mechanisms to protect user assets and data. This document outlines the key security features implemented in Para's architecture. ## Multi-Party Computation (MPC) At the core of Para's security is its use of Multi-Party Computation ([MPC](https://blog.getpara.com/what-is-mpc/)) for key management. MPC enhances security by: * Preventing the entire private key from being in one location * Eliminating single points of failure * Enabling secure key generation and transaction signing without exposing the full private key ## Hardware Secure Enclaves Para leverages hardware secure enclaves available in modern devices for additional security. These enclaves offer: * A dedicated, isolated environment for sensitive operations * Hardware-level protection for cryptographic keys * Secure biometric authentication capabilities ## Passkeys and WebAuthn Instead of traditional password-based authentication, Para implements the WebAuthn standard to create passkeys. This approach: * Eliminates risks associated with password-based authentication * Leverages device-specific security features * Provides phishing-resistant authentication ## Distributed Key Generation (DKG) Para uses Distributed Key Generation to create key shares without ever assembling the full private key. DKG: * Ensures no single party has access to the complete private key * Provides protection against key theft during the generation process * Allows for secure key refresh and rotation ## Permissions Framework Para implements a sophisticated permissions system to control transaction signing across multiple applications. This framework: * Allows granular control over what actions applications can perform * Mitigates risks associated with compromised applications * Enables users to manage their wallet's exposure across different apps ## Two-Factor Authentication (2FA) Para supports 2FA for additional account security, particularly during the wallet recovery process. The 2FA implementation: * Is an optional feature that can be enabled by users * Utilizes time-based one-time passwords (TOTP) * Adds an extra layer of security for critical operations ## Secure Backup and Recovery Para provides robust mechanisms for wallet backup and recovery, including: * Recovery secrets generated during wallet setup * Support for multiple backup devices * 48-hour delay for recovery attempts to prevent unauthorized access * Para Backup Kit for censorship resistance ## Encryption and Secure Communication All communication between the user's device, Para's servers, and connected applications is encrypted. This includes: * Use of TLS for all network communications * End-to-end encryption for sensitive data * Secure storage of user data with encryption at rest ## Regular Security Audits Para is committed to maintaining the highest security standards through regular third-party audits. The audit process includes: * Periodic audits by reputable security firms * Comprehensive review of cryptographic implementations * Continuous monitoring and improvement of security measures ## Censorship Resistance Para's design ensures that [users maintain control over their assets](https://blog.getpara.com/censorship-resistance-why-its-critical-and-how-were-tackling-it/) even in the event of service disruptions. Measures include: * Option for users to export their Cloud Share * Ability to sign transactions independently if Para services are unavailable * Decentralized nature of key management prevents single points of failure By implementing these comprehensive security mechanisms, Para provides a robust framework for protecting user assets and data. This multi-layered approach ensures that Para-powered wallets remain secure against a wide range of potential threats while maintaining a seamless user experience. # Technical FAQ Source: https://docs.getpara.com/v2/concepts/technical-faq Frequently asked technical questions about implementing and using Para for developers As you integrate Para into your applications, you may encounter various technical questions. This FAQ aims to address the most common inquiries from developers, covering aspects of implementation, security, architecture, and integration. If you don't find the answer you're looking for, our comprehensive documentation and support team are available to assist you further. Para uses the DKLS19 MPC algorithm and leverages an for core functions like distributed key generation, signing ceremonies, and non-custodial wallet generation. This ensures a robust and auditable foundation for Para's key management system. Para uses the EIP712-specified transaction signature interface. Additionally, Para publishes an EIP-1193 Provider, which is most commonly used via the Wagmi Connector. This ensures compatibility with a wide range of Ethereum-based applications and tools. Para uses sessions as a security measure when signing transactions. By default, session length is 90 minutes. Developers can implement session refresh logic in their applications to maintain longer sessions if required. While Para primarily uses MPC for key management, it is designed to work with ERC-4337 (Account Abstraction) out of the box. This allows developers to leverage Para's security features while also taking advantage of AA capabilities if desired. As long as the Cloud Share sent during onboarding is not deleted by the user, they can always refresh keys, export, or sign transactions independently. This design ensures that Para cannot censor transactions and provides a robust fallback mechanism. Read our blog post on [censorship resistance](https://blog.getpara.com/censorship-resistance-why-its-critical-and-how-were-tackling-it/) for more details. Para offers SDKs for: - TypeScript/React for web developers - React Native for mobile developers - Flutter for cross-platform mobile development These SDKs provide a consistent interface for wallet management and transaction signing across different platforms. The biometric key is stored on-device in a secure enclave. For Ethereum-based transactions, Para uses secp256k1 curve signatures. However, the secure enclave supports the secp256r1 curve. Para generates a secp256r1 key, which is used to authorize a secp256k1 curve signature for ECDSA signatures, bridging this compatibility gap securely. All UI elements and copy in the Para flow are fully configurable. Developers can whitelabel the product to match their application's look and feel. While Para aims for a somewhat consistent user experience, copy, colors, and sizes are fully customizable. Refer to the for detailed configuration options. Para supports sign-in via Google, Apple, Twitter/X, Discord, and Facebook. This allows developers to offer a range of authentication options to their users, potentially increasing adoption and ease of use. Para's multi-app architecture allows the same wallet to be used across different applications while maintaining security. It uses a permissions scheme that specifies what types of transactions an application can perform and which ones require user approval. This is implemented through encrypted User Shares specific to each application and an allow-list mechanism managed by Para. Para implements a robust recovery mechanism involving: 1. A recovery secret generated during wallet setup 2. Option to add backup devices 3. Two-factor authentication for additional security 4. A key rotation process after recovery to ensure security The recovery process is managed through the Para Portal, reducing the implementation burden on individual developers. Para's architecture is designed to be blockchain-agnostic. It offers native support for: - All EVM-compatible chains - Cosmos ecosystem - Solana Developers can integrate Para with popular libraries like ethers.js, viem, and CosmJS for interacting with these networks. For full chain support please see our [chain support documentation](https://docs.getpara.com/v2/react/guides/custom-chains#additional-chains). Universal embedded wallets in Para is achieved through: 1. Associating wallets with user identities (typically email addresses) rather than individual applications 2. Using MPC for secure key sharing across applications 3. Implementing a permissions framework for granular access control 4. Providing seamless authentication when users access new applications Developers can leverage these features through Para's SDKs and APIs to enable users to access their wallets across different applications seamlessly. Yes, users can export their private keys with Para. While we don't see many users export their private keys given Para wallets are universal and usable across apps and chains, users are able to do so in [Para Connect](https://connect.getpara.com/). Multi-sigs require separate private keys to approve a transaction. MPC splits a single private key across multiple parties and parites jointly sign without ever reconstructing the key. For further technical details or questions not covered here, please refer to our documentation or reach out to our developer support team at . # Universal Embedded Wallets Source: https://docs.getpara.com/v2/concepts/universal-embedded-wallets Exploring Para's approach to universal embedded wallets: portability and seamlessly cross-app Para [universal embedded wallets](https://blog.getpara.com/universal-embedded-wallets/) allow users to seamlessly use their wallet across different applications and platforms, providing a more fluid and user-friendly experience in the crypto ecosystem. ## Overview In the crypto ecosystem, users often need to access the same wallet across various applications. However, this convenience can pose security risks if not managed properly. Para's multi-app architecture addresses these challenges by implementing a sophisticated permissions scheme that balances accessibility with security. Universal embedded wallet functionality is not about transferring assets between wallets, but rather accessing the same wallet from different applications and platforms. ## Key Components Para's approach to universal embedded wallet portability leverages its unique architecture and security features: Para associates wallets with user identities (typically email addresses) rather than individual applications A granular permissions system ensures that applications only have the access they need, enhancing security in a multi-app context Users can log in to new applications using their Para credentials, automatically gaining access to their existing universal embedded wallet Para's MPC-based key management allows for secure key sharing across applications without exposing the full private key. This implementation ensures that users can easily and securely use their Para universal embedded wallets across multiple applications while maintaining strong security and privacy controls. ## Benefits 1. * Access the same wallet across multiple applications without complex key exports 2. * No need to manage multiple wallets or perform 3. * Consistent user experience across different platforms 4. * Permissions for transparent security and granular access confrol 1. * Easier onboarding of users who already have a Para universal embedded wallet 2. * Access to richer transaction history and liquidity from shared wallets 3. * Easily craft multi-app experiences and build an ecosystem 4. * request specific permissions based on the application's needs. ## Universal Embedded Wallets vs. Traditional Approaches To understand the advantages of Para's wallet portability, let's compare it with traditional approaches: | Feature | Third-Party Wallets | Traditional Embedded Wallets | Universal Embedded Wallets | | ---------------------------------- | :-----------------: | :--------------------------: | :------------------------: | | Portable across apps | ✔️ | | ✔️ | | Smooth in-app UX | | ✔️ | ✔️ | | Integrated with app functionality | | ✔️ | ✔️ | | No browser extensions required | | ✔️ | ✔️ | | Granular permissions per app | | | ✔️ | | No manual key management for users | | | ✔️ | This comparison highlights how Para Universal Embedded Wallets combine the best features of both third-party and traditional embedded wallets, while also offering unique advantages such as granular permissions and simplified key management. ## Security Features Each application can be granted specific permissions, limiting potential damage if one app is compromised. The User Share is encrypted specifically for each application, preventing unauthorized access. Each key sharing process includes a signature verification step to ensure authenticity. Thanks to MPC, the full private key is never exposed to any single application or stored in one place. ## How Wallet Portability Works When a user creates a Para universal embedded wallet in one application, it's associated with their identity (e.g., email). When the user wants to use their wallet in a new application: - They log in with their Para credentials - The new application requests specific permissions - Upon approval, the application gains access to the user's wallet Para securely shares the necessary key information with the new application, without exposing the full private key. The user can now seamlessly use their wallet across all connected applications, with each app respecting its granted permissions. ## Example Use Cases 1. **DeFi Dashboard**: An app that aggregates data from multiple DeFi protocols could request read-only permissions across various chains. 2. **NFT Marketplace**: Could request permissions specifically for NFT-related transactions on relevant chains. 3. **Cross-Chain DEX**: Might request permissions for swap transactions across multiple chains. ## Preview: Upcoming Enhancements Para is continuously working on enhancing universal embedded wallet experiences. Future developments may include: * More granular permission controls * Enhanced analytics and insights for users across their entire wallet usage * More seamless cross-chain experiences By providing true universal embedded wallet portability, Para aims to make the crypto experience more user-friendly and secure, paving the way for broader adoption and more innovative multi-app ecosystems. # Account Abstraction Source: https://docs.getpara.com/v2/general/account-abstraction Explore account abstraction integration options with Para across different platforms Account Abstraction (AA) enables a more intuitive and flexible blockchain experience by allowing for programmable accounts with features like gasless transactions, batched operations, and custom authorization logic. Para serves as the Signer and EOA (Externally Owned Account) for smart wallets and is not a smart wallet itself. Para does not provide gas sponsorship, but you can use any of the supported providers to implement smart wallet functionality for your users. ## Choose Your Platform Note that client-side support for account abstraction is not currently available for Swift and Flutter platforms. If you need account abstraction functionality in Flutter or Swift applications, it's recommended to use server-side account abstraction integration. ## Supported Providers Para integrates with several leading Account Abstraction providers: * * * * * * * * # Go Live Checklist Source: https://docs.getpara.com/v2/general/checklist A checklist to help you go live with the Para SDK. Before going live, ensure you've completed the following steps: * [x] 🔑 Create a account to manage your integration * [x] Create and configure a `BETA` API Key for testing the integration * [x] : Get the SDK or Modal Up and Running * [x] Check out the or sections for help! * [ ] ⛓ Get signing & on-chain connectivity set up and make sure you're able to sign transactions * [ ] **\[EVM]** * [ ] **\[Cosmos]** : Add on the `cosm.js` signer or plug in one of our wallet adapters for popular libraries * [ ] : Decide if you'll be using Account Abstraction with Para * [ ] : Connect Para users to your existing infrastructure * [ ] 🔒 Ensure Security and Session Management works for your app * [ ] : Decide what login methods you'd like to use * [ ] Implement Logic * [ ] Decide if you want to enable * [ ] 🎨 Make Para your own with by adding the visual finishing touches * [ ] : Configure Branding, UI and more * [ ] 🚀 Test and go live! * [ ] Make a `PRODUCTION` API Key (Note: you'll need to set up billing first) * [ ] Walk through the * [ ] Ping us if you'd like help testing anything ## Para Environments: `BETA` vs `PRODUCTION` Para has two different environments. **NOTE: Wallets are not shared across environments** `BETA` is intended for you to develop and test against, **not for production builds or real users and funds** * `BETA` can be used with any plan, including the free tier * This is the correct environment to use for local or staging builds * `BETA` users can be deleted for your convenience while testing, and is limited to *50 max users per project* `PRODUCTION` is intended for any real users/funds * This is the correct environment to use for release or production builds * `PRODUCTION` users can NOT be deleted, and have no per-project limit # Glossary Source: https://docs.getpara.com/v2/general/glossary Glossary of key terms. ### Identity and Wallets **Embedded wallet** – A non-custodial wallet built into an app, often invisible to users. Enables users to control assets without managing keys or apps. **Passkey** – A device-native authentication method [(based on WebAuthn)](https://docs.getpara.com/v2/concepts/key-management#passkey) used as a more secure and user-friendly alternative to passwords and private keys. **Private key** – Cryptographic secret that grants control over a wallet. In [MPC setups](https://blog.getpara.com/what-is-mpc/), it’s never reconstructed or stored in full; access is managed through secure, distributed shares. **Recovery (or Key Recovery)** – The process for regaining access to a wallet, typically complex and manual in crypto. [Solutions like social recovery and embedded wallet recovery with Para simplify this for mainstream users.](https://docs.getpara.com/v2/concepts/recovery) **Seed phrase** – A series of words that encode a wallet’s private keys. Often used for wallet backup, but vulnerable to phishing and user error. [(Increasingly replaced by passkeys or MPC.)](https://blog.getpara.com/what-is-mpc/) **Session key** – A short-lived key used to sign actions during an app session without requiring full wallet access. **Signer** – An entity (user, server, agent) that can authorize transactions for a wallet. **Wallet address** – A unique identifier for a wallet, similar to a bank account number users can share to receive funds. ### App Infrastructure **EVM / Solana / Cosmos** – refer to [different blockchains](https://docs.getpara.com/introduction/chain-support), each with its own ecosystem of developer tools, standards, and communities. **Gas** – The fee paid to execute transactions on a blockchain (like network fees in fintech). In modern apps, gas can be abstracted away from users for smoother UX. **Onchain / Offchain** – Indicates whether an action occurs on the blockchain or off of it. Onchain means the operation is happening directly on the blockchain, while offchain references to actions that take place on traditional servers or outside the blockchain. **RPC (Remote Procedure Call)** – The bridge between an app and the blockchain, used to read/write onchain data. **Rollup** – A type of scaling solution (e.g., [Optimism](https://www.optimism.io/), [Arbitrum](https://arbitrum.io/)) that processes transactions off the main chain and posts a summary onchain. Speeds things up and reduces gas costs. **Smart contract** – Self-executing code on a blockchain that defines how an app behaves. ### Security and Privacy **Custody** – Defines who controls the private keys, and therefore access to the funds in a wallet setup. In crypto, custody determines who has actual control. Wallets can either be custodial or non-custodial. **Custodial** – A third party holds wallet keys or crypto assets on behalf of a user. **Distributed MPC (Multi-Party Computation)** – A cryptographic method where multiple parties collaboratively compute a result, like signing a transaction, without ever revealing or reconstructing the full private key. It’s typically used alongside [Distributed Key Generation (DKG)](https://docs.getpara.com/concepts/key-management) for securely creating the key shares, and then applied during key signing. Enables secure, non-custodial access. **Hardware wallet** – A physical device for storing crypto private keys offline. **Non-custodial** – A setup where users retain full control of their wallet and assets. No third party can access their funds or sign on their behalf. **Shamir Secret Sharing** – A cryptographic technique for splitting a secret (like a private key) into [multiple pieces](https://blog.getpara.com/what-is-mpc/#:~:text=number%20of%20shares.-,Shamir%20Secret%20Sharing,-2/2%20Shamir). A minimum number of these pieces must be recombined to form the original private key to sign transactins and messages. Less dynamic than MPC. ### Ecosystems & Fintech **Liquidity** – How easily assets can be bought or sold without affecting price. Critical for user experience in swaps or trading. **Stablecoin** – A token designed to maintain a stable value (often pegged to the US dollar). Widely used in fintech apps for payments. **Token** – A digital asset, which can represent anything from currency to ownership in a protocol. **USDC (USD Coin)** – A dollar-pegged stablecoin issued by [Circle](https://www.circle.com/usdc), backed 1:1 by cash and short-term U.S. government bonds. Widely used in crypto apps and exchanges. **USDT (Tether)** – Another popular dollar-pegged stablecoin. Issued by [Tether](https://tether.to/), but with less transparency than USDC around its reserves. # iOS App Store Submission Source: https://docs.getpara.com/v2/general/ios-app-store-submission A friendly checklist to get your Para-powered iOS app through App Review without surprises. Use this guide to cover the App Review items Apple most often flags for Para integrations. *** ## 1. Sign-in options If your app includes any third-party logins (like Google or Facebook), Apple also expects a privacy-preserving option such as **Sign in with Apple**. This ensures users can sign in without sharing personal data or tracking identifiers. **Actions:** * Add **Sign in with Apple** anywhere other providers appear. * Test it in a **release build** before submission. If your app only uses first-party sign-ins (email, phone, or passkeys), Apple doesn’t require Sign in with Apple. *** ## 2. Reviewer login flow Make it effortless for reviewers to log in—especially if your app also supports external wallets. **Actions:** * Show standard sign-in options (email, phone, or Apple) first. * Add a line in onboarding: *“No external wallet required — continue with email, phone, or Apple.”* * In your **Reviewer Notes**, list exact steps to log in without a wallet. **Reviewer Notes example:** ```text theme={null} Use email or phone (OTP), or Sign in with Apple, to log in. No external wallet (e.g., MetaMask) is required to access the app. ``` *** ## 3. Wallet-only positioning If your app is a **non-custodial wallet** and **not an exchange**, make that clear. Reviewers often check for exchange or on-ramp features. **Add to Reviewer Notes:** ```text theme={null} The app is a non-custodial wallet using the Para SDK. It does not include exchange, swap, bridge, or on/off-ramp services. No tokens are sold or issued. Features: - Creates/imports non-custodial wallets via passkeys or MPC. - Displays addresses and signs user transactions. - Uses public RPC endpoints only. Exclusions: - No buy/sell/swap/bridge flows. - No fiat or crypto on-/off-ramp. - No KYC/AML required (wallet-only app). Para SDK: - Handles authentication and signing only. - Private keys never leave the user’s device. Request: - Review under Guideline 3.1.5(i) as a wallet-only app. ``` *** ## 4. Account deletion If users can sign up, Apple requires an **in-app account deletion option** (not just deactivation). Keep it simple: * Provide a Delete Account action somewhere obvious (Settings is fine). * If you need Para to remove the user record as well, reach out to support after you handle your own data. **Reviewer Notes example:** ```text theme={null} In-app account deletion is available at Settings → Account → Delete Account. Para is an SDK provider and does not host user accounts. Contact us if Para-level deletion is required. ``` *** ## 5. Passkeys & entitlements If you’re using passkeys or autofill, set up **Associated Domains** in Xcode and host an AASA file. **Checklist:** * Add **Associated Domains** capability. * Include `webcredentials:your.domain`. * Host `https://your.domain/.well-known/apple-app-site-association`. This enables secure credential sharing and Apple’s passkey autofill. *** ## 6. Reviewer Notes checklist Paste these details into **App Store Connect → Reviewer Notes**: * Login path (e.g., *Continue → Sign in with Apple → Approve prompt*) * Test credentials or OTP instructions * Note that the app is wallet-only, not an exchange * Location of Delete Account in settings * Any feature flags or regional settings * Confirmation that backend services are live *** ## 7. Privacy & SDK compliance Apple now enforces privacy manifest rules for all third-party SDKs. **Before you submit:** * Include privacy manifests for every SDK. * Ensure binary SDKs have valid signatures. * Declare reasons for any required-reason APIs. * Update your App Privacy answers to reflect data use accurately. *** ## 8. Export compliance Para SDK uses standard encryption (TLS, secure enclave, etc.). Answer **Yes** to App Store Connect’s encryption question and select the “standard algorithms” exemption. If your app uses custom cryptography, you may need to upload documentation. *** ## 9. Final pre-submission checklist ### Sign-in & onboarding * Sign in with Apple (if you offer other OAuth logins) * Onboarding text: *No external wallet required* * Associated Domains configured for passkeys ### Privacy & compliance * In-app Delete Account button visible * Privacy manifests complete & signed * App Privacy details updated * Export compliance questions answered ### Reviewer experience * Reviewer Notes completed (using template) * Test credentials provided * Backend services online * Privacy policy link included *** ## Related resources * [Production Deployment](/v2/general/production-deployment) * [Launch Checklist](/v2/general/checklist) * [React Native iOS setup](/v2/react-native/setup/react-native#ios) · [Expo iOS](/v2/react-native/setup/expo#ios) * [Swift setup](/v2/swift/setup#ios) · [Flutter iOS setup](/v2/flutter/setup#ios) # Migrating from Capsule to Para Source: https://docs.getpara.com/v2/general/migration-from-capsule Guide for migrating from @usecapsule/* packages to @getpara/* packages ## Overview This guide covers the migration process from Capsule to Para SDKs. The migration includes package namespace changes, method signature updates to use object parameters, and introduces new React hooks for state management. ## Package Changes All packages have been migrated from the `@usecapsule` namespace to `@getpara`. Update your dependencies by replacing `@usecapsule` with `@getpara` in your package.json: ```diff theme={null} { "dependencies": { - "@usecapsule/react-sdk": "^3.0.0", - "@usecapsule/evm-wallet-connectors": "^3.0.0" + "@getpara/react-sdk": "^1.0.0", + "@getpara/evm-wallet-connectors": "^1.0.0" } } ``` All packages have been reset to version 1.0.0 under the new namespace. The functionality and package names remain the same - only the organization prefix has changed from `@usecapsule` to `@getpara`. ```bash npm theme={null} npm install @getpara/[package-name] --save-exact ``` ```bash yarn theme={null} yarn add @getpara/[package-name] --exact ``` ```bash pnpm theme={null} pnpm add @getpara/[package-name] --save-exact ``` ## Mobile SDK Updates ### Flutter The Flutter package has moved from `capsule` to `para` on pub.dev: ```diff theme={null} dependencies: - capsule: 0.7.0 + para: ^1.0.0 ``` Create instances using `Para()` instead of `Capsule()`. All method signatures remain unchanged. ### Swift The Swift SDK package is now available at `github.com/getpara/swift-sdk`. The main class has been renamed from `CapsuleManager` to `ParaManager`, while maintaining the same method signatures: ```diff theme={null} - let manager = CapsuleManager() + let manager = ParaManager() ``` Method signatures and functionality remain identical for both mobile SDKs - only the package names and main class names have changed. ## Breaking Changes ### Method Updates All methods have been updated to use object parameters instead of multiple arguments. This change improves extensibility, type safety, and reflects our commitment to consistent API design. ```typescript theme={null} // Old createUser(email: string) // New createUser({ email: string }) ``` ```typescript theme={null} // Old createUserByPhone(phone: string, countryCode: string) // New createUserByPhone({ phone: string, countryCode: string }) ``` ```typescript theme={null} // Old externalWalletLogin(address: string, type: string, provider?: string, addressBech32?: string) // New externalWalletLogin({ address: string, type: string, provider?: string, addressBech32?: string }) ``` ```typescript theme={null} // Old createWallet(type: WalletType, skipDistribute?: boolean) // New createWallet({ type: WalletType, skipDistribute?: boolean = false }) ``` ```typescript theme={null} // Old createWalletPerType(skipDistribute?: boolean, types?: WalletType[]) // New. Note: Function name changed, default value added, and types is now required createWalletPerType({ skipDistribute?: boolean = false, types: WalletType[] }) ``` ```typescript theme={null} // Old distributeNewWalletShare( walletId: string, userShare?: string, skipBiometricShareCreation?: boolean, forceRefreshRecovery?: boolean ) // New distributeNewWalletShare({ walletId: string, userShare?: string, skipBiometricShareCreation?: boolean = false, forceRefresh?: boolean = false }) ``` ```typescript theme={null} // Old createWalletPreGen( type: WalletType, pregenIdentifier: string, pregenIdentifierType?: PregenIdentifierType ) // New createPregenWallet({ type: WalletType, pregenIdentifier: string, pregenIdentifierType?: PregenIdentifierType }) ``` ```typescript theme={null} // Old - Note: Function name changed updateWalletIdentifierPreGen( newIdentifier: string, walletId: string, newType?: PregenIdentifierType ) // New updatePregenWalletIdentifier({ walletId: string, newPregenIdentifier: string, newPregenIdentifierType?: PregenIdentifierType }) ``` ```typescript theme={null} // Old signMessage( walletId: string, messageBase64: string, timeoutMs?: number, cosmosSignDocBase64?: string ) // New signMessage({ walletId: string, messageBase64: string, timeoutMs?: number, cosmosSignDocBase64?: string }) ``` ```typescript theme={null} // Old signTransaction( walletId: string, rlpEncodedTxBase64: string, timeoutMs?: number, chainId: string ) // New signTransaction({ walletId: string, rlpEncodedTxBase64: string, timeoutMs?: number, chainId: string }) ``` All methods now use object parameters with optional properties defaulting to reasonable values. This change makes the SDK more maintainable and easier to extend in the future. ## New Features: React Hooks Para now includes React hooks for easier state management and SDK interaction. Here's a basic setup: ```typescript theme={null} import { ParaProvider, ParaModal } from "@getpara/react-sdk"; function App() { return ( ); } ``` ### Available Hooks Access current account state and connection status Get current wallet information and state Create a new Para user account Check if a user exists by email Start the login process Handle user logout Maintain active user session Create wallet after passkey verification Sign messages with connected wallet Sign transactions with connected wallet Handle login flow and initial setup Monitor account creation process Access Para client instance Control Para modal visibility Manage wallet state ## Next Steps 1. Update your package dependencies to use `@getpara/*` packages 2. Migrate method calls to use new object parameters 3. Consider implementing React hooks for simpler state management 4. Review framework-specific integration guides for detailed setup instructions # Integrate Para Docs MCP with AI Tools Source: https://docs.getpara.com/v2/general/para-docs-mcp Connect the Para Docs Mintlify MCP server to AI tools for direct documentation access and enhanced coding assistance Connect the Para Docs MCP server to AI tools for seamless access to documentation, code examples, and guides. This integration enables AI assistants to search Para Docs directly via the Model Context Protocol. ## Prerequisites * Active accounts for target AI tools * Para Docs MCP server URL: `http://docs.getpara.com/mcp` * AI tool with remote MCP connection support (may be in beta) ## Installation and Setup Set up connections by adding the MCP server as a custom connector in each tool's settings. ### Configure ChatGPT Connection 1. Open ChatGPT settings from your avatar menu 2. Select **Connectors** in the sidebar 3. Click **Create** to open the New Connector dialog 4. Enter the MCP server URL: `http://docs.getpara.com/mcp` 5. Configure authentication if required (Para Docs MCP uses no security by default) 6. Save and test the connection ### Configure Claude Desktop 1. Navigate to **Settings > Extensions** in Claude Desktop 2. Click **Advanced settings** and locate the Extension Developer section 3. Add a custom connector with the remote MCP URL: `http://docs.getpara.com/mcp` 4. Note: Remote support is in beta; use local STDIO if preferred 5. Verify the connection in Claude's interface ### Configure Claude Code 1. Run the CLI command: `claude mcp add` 2. Follow the wizard to input the MCP server URL: `http://docs.getpara.com/mcp` 3. Select remote MCP support 4. Integrate tools like search and fetch for Para Docs access 5. Restart Claude Code to apply changes ### Configure Cursor 1. Open Cursor settings and navigate to **Models** or **API Keys** 2. Disable unnecessary models if needed 3. Add a custom model or provider, overriding the base URL to `http://docs.getpara.com/mcp` 4. Use agent mode for MCP interactions (similar to VS Code Copilot) 5. Verify by testing a documentation query in the editor ## Usage Query the MCP server via your AI tool's interface after setup. Provide search terms to the "SearchParaDocs" tool for relevant results. Ask your AI: "Search Para Docs for \[topic]" The tool returns titles, snippets, and links to relevant documentation. Review returned contextual content and follow links for full details. Check for connection issues and retry if the server is unreachable. ## Example ### Query Example ```text theme={null} Search Para Docs for how to sign a basic message ``` ### Expected Response The MCP server returns structured results: ```json Response theme={null} { "results": [ { "title": "Sign Messages with Para", "snippet": "Learn how to sign messages using Para's wallet integration...", "link": "https://docs.getpara.com/v2/react/guides/web3-operations/sign-with-para" }, { "title": "Web3 Operations Guide", "snippet": "Complete guide for signing transactions and messages...", "link": "https://docs.getpara.com/v2/react/guides/web3-operations" } ] } ``` # Wallet Pregeneration Source: https://docs.getpara.com/v2/general/pregen Overview of generating pregenerated wallets for Para Wallet pregeneration allows you to create wallets in advance of user interactions, which can significantly improve user onboarding speeds and overall experience in your application. With pregeneration, you can create a wallet for any identifier (email, phone number, username, etc.), executing Para's 2-of-2 MPC protocol where your application initially maintains ownership over the user's share of the MPC. The pregenerated wallet can later be claimed by the user associated with that identifier, transferring ownership of their share to them – if your application permits this option. This flexibility opens up numerous possibilities for streamlining user experiences and creating innovative onboarding flows. ## Choose Your Platform Para supports wallet pregeneration across all supported platforms. Select your development platform to view platform-specific implementation details: ## Innovative Use Cases Pregeneration enables powerful new ways to incorporate blockchain into your application: * **Mass User Onboarding**: Create wallets for your existing user base or email lists instantly * **Social Integration**: Generate wallets based on social identifiers like Twitter followers * **Agent-Owned Wallets**: Allow AI agents or bots to create and manage wallets for specific functions * **Server-Side Operations**: Create app-managed wallets to perform operations on behalf of users * **Airdrops and Rewards**: Preload funds or NFTs into wallets that users can claim later * **Staged Onboarding**: Let users experience your application before formally creating their wallet These use cases represent just a few of the possibilities enabled by wallet pregeneration. The platform-specific guides provide detailed implementation instructions for your chosen environment. # Deploy Para Integration to Production Source: https://docs.getpara.com/v2/general/production-deployment Transition your Para integration from development to production with updated configurations and security settings Deploy your Para integration to production by updating configurations and ensuring secure settings for real users. ## Prerequisites You need these components before deploying to production: * A working Para integration in development/beta environment * Production API credentials from the [Para Developer Portal](https://developer.getpara.com/) * Production domain with HTTPS enabled * Latest Para SDK version installed ## Deployment Steps Update your Para SDK to the latest version before going live. Use the newest v2.0 release for all projects to benefit from improvements and fixes. Check your @getpara/\* package versions and update to the latest stable release. Latest SDK versions resolve many integration issues. Align your project with the [current Para release](https://www.npmjs.com/package/@getpara/react-sdk?activeTab=versions)to access recent features and security patches for real users. Create a production API key in the Para Developer Portal for your live environment. Replace development credentials with production values in your environment variables. Update all secrets and URLs in your .env file for production, including callback URLs and API endpoints. Configure your integration to use the production environment instead of beta/development. Para provides two hosted environments: BETA for testing and PROD for live use. Update your initialization from: ```javascript Development theme={null} const para = new ParaWeb(Environment.BETA, PARA_API_KEY); ``` To: ```javascript Production theme={null} const para = new ParaWeb(Environment.PROD, PARA_API_KEY); ``` Para's Beta and Production are separate environments. Wallets and users are not shared between them. Your production environment starts with no users, and requires a distinct production API key. Update allowed origin settings in the Para developer portal to include your production domain. This Domain Security setting restricts API usage to specified origins. Add entries like `https://yourapp.com` and production subdomains to the Allowed Origins list. Remove development URLs like `http://localhost:3000` if no longer needed. HTTPS is required in production. Configuring allowed origins prevents unauthorized domains from using your Para integration. Allowed Origins are only supported for web integrations, not server or mobile. Review your Para integration settings for production, especially user communications and UI: ### Verification Redirect URL Set the verification redirect URL to point to your production application's confirmation page. This URL appears in verification emails Para sends to users. Update from localhost URLs to your live domain. ### Email Notification Preferences Choose appropriate email settings for production. Para can send welcome emails and optional backup kit instructions to new users. Configure email templates and branding (logo, app name) for real user emails based on your user experience strategy. ### Branding and UI Configuration Customize the Para modal or widget to match your production app's branding (colors, fonts, icons). Configure theme options through the Para SDK or developer portal's branding section. Deploy your updated application with production settings and perform end-to-end testing with real scenarios: ### Test User Sign-Up/Login Create a new user account using a real email address or phone number. Ensure OTP codes are delivered and users can complete verification and wallet creation. Test emails like [dev@test.getpara.com](mailto:dev@test.getpara.com) and dummy phone numbers will not work in production. Production requires real contact information and OTP verification. Ensure you are signing transactions on the [appropriate network](https://docs.getpara.com/v2/introduction/chain-support). ### Functionality Check Verify wallet operations work with production settings. Test retrieving wallet addresses or making test transactions on mainnet to confirm Para's production environment interacts correctly. Verify session management and security features (persistent login/logout) behave as expected. ### Monitor and Review Watch browser console and backend logs for errors like misconfigured API keys or CORS issues. If you encounter CORS or CSP errors, verify the origin matches your deployed URL exactly. ## Pricing Information With [Para Free Tier](https://www.getpara.com/pricing) your first 1,200 monthly active users are free. Paid plans require billing information to upgrade. ## Next Steps # Telegram Bots & Mini-Apps Source: https://docs.getpara.com/v2/general/telegram A user-friendly guide to quickly integrate Telegram Apps For signing in to Para with Telegram, refer to . Para supports both Telegram Bots and Mini-Apps. are a way to program logic natively into the Telegram App interface via text-based prompts and commands. Telegram Bots feel native to the UX of Telegram, but are limited to the UX and functionality of text-based options and menus. are an easy way to serve hosted web applications from within Telegram. Given Mini-Apps are added functionality to an existing web app, they are much more flexible but have a UX pattern that deviates from the native Telegram experience. ## Telegram Bot The most popular way to use Para in a Telegram Bot is to leverage with the . You have the option of allowing your users to their pregenerated wallets, which can happen directly within Telegram or in a standalone app. ## Mini-App You can build Mini-Apps two ways: 1. Use the with the password option. 2. Use with the web SDK in a web framework of your choice. Once you have a web example working, use Telegram to create an interface for getting and setting data, like in . 3. You'll need to decide where and how you want users to claim their pregenerated wallets. This can happen within Telegram Mini-Apps or in a standalone app. Telegram Storage APIs have some limitations on data size. You may need to implement chunking to work around this. See this for more info. # Troubleshooting Source: https://docs.getpara.com/v2/general/troubleshooting Something not working quite right? This is the section for you! Having trouble with your Para integration? You're in the right place. This section contains platform-specific troubleshooting guides to help you resolve common issues across different frameworks and environments. Using an LLM (ChatGPT, Claude) or Coding Assistant (Cursor, Github Copilot)? Here are a few tips: 1. Include the for the most up-to-date help 2. Check out the for an interactive LLM using Para Examples Hub ## Choose Your Platform ### Web ### Mobile ## Popular Web Frameworks If we're missing a troubleshooting guide for a framework you're using, please get in touch! We're constantly expanding our documentation to cover more environments. ### Integration Support If you're experiencing issues that aren't resolved by our troubleshooting resources, please [contact our team](https://join.slack.com/t/para-community/shared_invite/zt-304keeulc-Oqs4eusCUAJEpE9DBwAqrg) for assistance. To help us resolve your issue quickly, please include the following information in your request:
  1. 1

    A detailed description of the problem you're encountering.

  2. 2

    Any relevant error messages or logs.

  3. 3

    Steps to reproduce the issue.

  4. 4

    Details about your system or environment (e.g., device, operating system, software version).

Providing this information will enable our team to address your concerns more efficiently. # User Data Management Source: https://docs.getpara.com/v2/general/user-data A comprehensive guide to managing user data when integrating Para into your application Effective user data management is crucial when integrating Para into your application. This guide covers best practices for handling user information, including storage, retrieval, and privacy considerations. ## User Data in Para Para's approach to user data is designed with privacy and security in mind. Here's what you need to know: Para only collects essential information required for account identification and recovery, typically just the user's email address. User data is securely stored and encrypted on Para's servers. However, the most sensitive information - the user's private keys - are never fully stored in one place due to Para's MPC technology. As a developer, you have limited direct access to user data stored by Para. This is by design to ensure user privacy and security. ## Managing User Data in Your Application While Para handles the core wallet functionality, you may need to manage additional user data in your application. Here are some best practices: ### Storing User Information When storing additional user information in your application: 1. Only store what's necessary for your application's functionality. 2. Use secure, encrypted storage methods. 3. Consider using Para's wallet ID as a unique identifier for your users. Example of storing user data: ```typescript theme={null} type UserData = { paraWalletId: string; username: string; preferences: Record; }; // Assume you're using a secure database async function storeUserData(userData: UserData) { await database.users.insert(userData); } // Usage const wallets = await para.getWallets(); const walletId = Object.values(wallets)[0].id; await storeUserData({ paraWalletId: walletId, username: "user123", preferences: { theme: "dark" }, }); ``` ### Retrieving User Information To retrieve user information: 1. Use Para's methods to get wallet-related information. 2. Fetch additional data from your own storage using the Para wallet ID as a reference. Example: ```typescript theme={null} async function getUserData(email: string) { const wallets = await para.getWallets(); const walletId = Object.values(wallets)[0].id; // Fetch additional data from your storage const userData = await database.users.findOne({ paraWalletId: walletId }); return { walletId, ...userData, }; } ``` ### Updating User Data When updating user data: 1. Use Para's methods for updating wallet-related information. 2. Update additional data in your own storage. ```typescript theme={null} async function updateUserPreferences(walletId: string, newPreferences: Record) { // Update in your storage await database.users.update({ paraWalletId: walletId }, { $set: { preferences: newPreferences } }); } ``` ## Privacy and Security Considerations When managing user data, always prioritize privacy and security: Only collect and store data that is absolutely necessary for your application's functionality. Always encrypt sensitive data, both in transit and at rest. Implement strict access controls to ensure that only authorized personnel can access user data. Conduct regular audits of your data management practices to ensure compliance with privacy regulations. ## Compliance with Regulations Ensure your user data management practices comply with relevant regulations such as GDPR, CCPA, or other applicable laws. This may include: * Providing users with the ability to request their data * Allowing users to delete their data * Implementing data portability features Example of a data deletion function: ```typescript theme={null} async function deleteUserData(walletId: string) { // Delete from your storage await database.users.delete({ paraWalletId: walletId }); // Note: Para wallet data cannot be deleted directly through the SDK // Advise the user to contact Para support for complete account deletion } ``` Remember that while you can delete user data from your own storage, Para wallet data is managed separately for security reasons. Users should be directed to Para's official channels for complete account deletion requests. ## Best Practices for User Data Management 1. **Separation of Concerns**: Keep Para-related data separate from your application-specific user data. 2. **Regular Backups**: Implement a robust backup strategy for user data stored in your application. 3. **Transparent Policies**: Clearly communicate your data handling practices to users through privacy policies and terms of service. 4. **Secure Transmission**: Always use secure, encrypted channels when transmitting user data. 5. **Data Validation**: Implement thorough input validation to prevent injection attacks and ensure data integrity. ## Troubleshooting If you encounter issues with user data management: 1. Ensure you're using the latest version of the Para SDK. 2. Verify that you're correctly handling asynchronous operations when interacting with Para and your own data storage. 3. Double-check that you're using the correct wallet IDs and other identifiers. 4. Review your error handling to ensure you're catching and addressing all potential exceptions. # Para Video Resources Source: https://docs.getpara.com/v2/general/webinars Check out talks by the Para team about our roadmap, MPC, and in-depth looks at Para's architecture and use cases. Founder/CEO Nitya Subramanian covers how multi-party computation can enable flexible and programmable transactions at zkParis 2023