Skip to main content 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.
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
The user sees clear, human-readable consent scopes
They approve or decline each scope
Para enforces only the approved permissions
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 [email protected] 
