Permissions

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.

​

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