Skip to main content
Traditional embedded wallets force a tradeoff: either prompt users to approve every single action, or give applications blanket signing access with no guardrails. Neither works when wallets are shared across applications or when compliance teams need to audit what an app can do. Para’s policy-based permissions system controls what each application can do with a user’s wallet. Policies are defined per API key, enforced server-side on every transaction, and presented to users as plain-language consent items.
  • Declared up front: every capability needed is specified in a policy before any user interaction
  • User consent is explicit: permissions are grouped into readable scopes that users review and approve during onboarding
  • Server-side enforcement: Para evaluates every transaction against the approved policy before it reaches the MPC signing ceremony. This cannot be bypassed client-side
  • Default deny: any action not explicitly allowed in the policy is blocked

​
How It Works

1

Define a policy for your API key

Each policy declares what your app can do: sign messages, transfer tokens, call specific smart contracts, or deploy contracts. Rules can include constraints like value caps, address allowlists, and per-chain scoping. Policies are configured in the Para Permissions Builder and are immutable once published; changes require a new version.
2

Organize rules into scopes

Permissions are grouped into user-facing consent items called scopes. Each scope has a plain-language name and description (for example, “Automated token swaps” rather than a raw contract address). Scopes can be marked as required or optional.
3

Users review and consent

During onboarding or login, users see the scopes and choose which to approve. Required scopes must be accepted to use the app. Optional scopes can be declined without losing access.
4

Every action is enforced

When the application requests a transaction, Para evaluates it against the user’s approved permissions. If the action falls outside the policy (wrong contract, value too high, unapproved chain), it’s rejected before signing.

​
Permission Configuration Options

Message Signing

Allow or deny the ability to sign arbitrary messages. Useful for login flows, attestations, and off-chain signatures.

Token Transfers

Control who can send native tokens and how much. Set per-chain rules, cap transfer amounts, or restrict destination addresses.

Smart Contract Calls

Lock interactions to specific contracts and functions. For example, allow calling swap on a DEX router but nothing else.

Contract Deployment

Allow or block the ability to deploy new smart contracts entirely.
DENY always overrides ALLOW. Developers can create broad allow rules and add narrow deny exceptions for specific cases. If no rule matches an action, it’s blocked by default.

​
The User Experience

Users see permissions in plain language, not raw technical details. Here’s what the consent flow looks like:
  1. During onboarding, users see the scopes defined in the application’s policy
  2. Required scopes are pre-checked and must be accepted; optional scopes can be toggled
  3. Users approve or decline each optional scope
  4. Para stores consent and enforces only the approved permissions
  5. Any out-of-policy action is rejected before it reaches signing
There is no silent permission creep; policy changes require a new policy version.
Permissions consent UI showing scopes and policy

​
Cross-App Permissions

Permissions become especially important with universal wallets, where a single wallet is used across multiple applications. Each app defines its own policy, and users approve permissions separately for each app. This means:
  • A DeFi app can request swap permissions without gaining access to sign arbitrary messages
  • A portfolio tracker can request read-only message signing without being able to transfer funds
  • Users maintain visibility and control over what each app can do

Permissions Reference

Complete technical reference: full policy schema, permission types, condition system, comparators, and worked examples.

​
Get Started

Permissions policies are configured in the Para Permissions Builder. For help designing a policy that fits a specific use case, reach out at hello@getpara.com.

Transaction Permissions

Implement client-side transaction confirmation dialogs

Universal Wallets

How wallets work across multiple apps

Security

Para’s security and trust model