Skip to main content
Para Permissions lets you control which transactions wallets can sign. You configure policies in the Developer Portal, test them against a Development API key, and work with Para to publish the production configuration. App-owned wallets can sign by default unless a Guardrail blocks the transaction. User-owned wallets require review unless the user has granted a matching Request.
Permissions supports EVM, Solana, Cosmos, Stellar, and Sui signing routes. The Developer Portal forms cover a subset of policy shapes; use JSON authoring or work with Para for other supported configurations. Select the wallet type and signing route explicitly, and check the policy reference for the facts supported by each request.

​
Choose a policy type

Permissions separates two different wallet experiences: Requests always require user consent. Guardrails do not show a consent request because the application owns the wallet.
Developer Portal Permissions page with Guardrails and Requests tabs

​
Configure a Development policy

Start with a Development API key. Policies created for one API key do not affect another key.
1

Open Permissions

Select your project and Development API key in the Developer Portal, then open Permissions from the sidebar. Choose Guardrails or Requests based on the wallet ownership model above.
2

Describe the policy

Select Add. For a Request, enter the plain-language text users will see when deciding whether to grant access. Select one or more networks and, if needed, an optional start and end time for the policy.
Create Request Policy form with consent language, network selector, and optional policy window
3

Define the transaction logic

Add the actions the app needs and narrow each action with an available condition. For example, allow native transfers on Ethereum up to a fixed amount, or limit a contract call to a particular function and argument.
Request Logic step showing a transaction action, network, conditions, and required consent
4

Review and save a draft

Select Review to inspect the server-normalized policy and any warning about broad access. Select Save Draft only when the summary matches your intent. A draft is inert and does not change signing behavior.
Review step summarizing the policy and warning that no conditions were configured
5

Activate and test

Activate the draft when you are ready to use it on the Development key. The first active policy automatically enables Permissions for that key. A policy affects signing only while it is active and within its time window. Test at least one transaction that should match and one that should not before requesting production review.
Saving and activating are separate actions. Save Draft does not enforce the policy. After permissions have been enabled, deactivating every policy does not remove the ownership-based signing defaults.

​
Actions and conditions

The current Portal flow supports these transaction actions:
  • Transfer ETH
  • Transfer tokens
  • Call a contract
  • Execute a Safe transaction
  • Deploy a contract
Depending on the action, you can set per-transaction or cumulative spending limits for native and ERC-20 transfers, restrict recipients, or require a specific contract, function, or argument. An optional policy window controls when the policy applies. The available controls are described in the Permissions Reference.
The Portal covers common policy shapes. For several conditions on one action, nested logic, other supported wallet types, or multiple rules that work together, use JSON authoring with the CLI or contact Para for assistance.

​
Selectors and versions

The policy type and complete network selection identify the policy you are editing. Network order does not matter, so Ethereum + Base is the same selector as Base + Ethereum. Base only is a different selector and creates an independent policy. Editing an existing selector creates the next version of that policy. Changes to an active policy replace the active version when saved, while changes to a draft remain in draft. Resolve the current draft by activating or discarding it before creating another draft.
Editing an active policy and selecting Save changes replaces the active version immediately. Test active-policy changes on the Development key before requesting a Production update.

​
Production

Development and Production API keys are independent. Creating a Production key does not copy the Development policy, activate Permissions, or change the Production key’s existing signing behavior. After you have validated the active Development policy:
  1. Create the Production API key.
  2. Open the Production key and select Request production review. This action appears when Development has an active policy and the Production key is still awaiting permissions setup.
  3. Para reviews the active Development policy and independently publishes the approved policy for the Production key.
  4. Verify the published Production policy in the Portal before sending production traffic.
The Production Permissions page is read-only. It can appear empty until Para publishes the approved policy.

​
Integration guides

React Requests

Handle consent and transaction review for user-owned wallets on the web.

React Native Requests

Open transaction review URLs from a native application.

REST Guardrails

Restrict signing for app-owned wallets used through the REST API.

Permissions Reference

Explore the full policy JSON language, selectors, conditions, and approval requirements.