Skip to main content
Your backend signs with app-owned wallets through the REST API, so the policies you build here are Guardrails, created on the Guardrails tab. Build a policy with the Developer Portal forms, save it as a draft and activate it on a Development key. When a policy needs more than the forms offer, the same flow hands off to a JSON editor.
Author and test policies on a Development key, which uses Para’s beta environment. Production keys are read-only in the Developer Portal. Para publishes production policies after a production review.

​
Open Permissions

Each API key has its own policies. Select your project, pick a Development key in the key switcher, then open Permissions under Configuration in the sidebar. The page has two tabs, and the tab you start from sets the policy type. There is no separate type picker. Each row shows its Status: Active, Expired, Draft or Off. Only active policies inside their time window affect signing. A draft can be activated only while its time window is open. Outside it, selecting Activate shows the error policy record activation window is not active.
Developer Portal Permissions page on the Guardrails tab, listing an active, an off and a draft Guardrail

​
Create a policy

A policy is built in three screens: the policy details, the logic and a review. Saving creates a draft, and nothing is enforced until you activate it.
1

Start from the right tab

Select Guardrails or Requests. Select Add for your first policy, or New Guardrail or New Request once the tab has policies.
2

Describe the policy and pick networks

Fill in the first screen:
  • Guardrail Policy Name names a Guardrail in the list.
  • User consent request language is the text users read on the consent screen, after your app’s name and “would like to”. Write it as an action, such as “send up to 0.2 ETH a day”.
  • Networks opens a checklist grouped by wallet type: EVM, Solana, Cosmos, Stellar and Sui. Check a group to cover every network of that type, or check individual networks. A policy covers one wallet type.
  • Policy Time Window (Optional) limits when the policy applies. Leave From and To empty to apply it as soon as it is active.
Select Continue.
Create Request Policy screen with consent language entered and the Networks checklist open on the EVM group
3

Add actions and conditions

On the Guardrail Logic or Request Logic step, choose an action under Select Action, fill in its target fields, then select Add Condition to narrow it. Select Add Action to cover another action in the same policy.The two types read conditions differently:
  • In a Guardrail, the target and condition describe what that action may do. Para blocks requests of that action outside the boundary. An action with no condition blocks every request of that action outside its target fields. For actions with no target fields, such as Transfer ETH, Deploy a contract and Native transfer, that means every request of that action on the selected networks.
  • In a Request, the target and conditions describe what the user grants. All conditions on an action must hold. User consent is always Required.
Guardrail Logic step with Transfer ETH and a Transaction amount condition limited per 24-hour window
4

Review and save a draft

Select Review. Para validates the policy and shows the server-normalized version, a warning when no action has a condition, and an Overlaps with active policies list when other active policies cover the same requests. Every overlapping policy applies, and a block in any overlapping Guardrail wins.Select Save Draft when the summary matches your intent.
Review step summarizing the policy and warning that no conditions were configured
5

Activate

In the list, select Activate on the draft row. The policy now applies to signing on this key, and the first active policy turns Permissions on for the key. Test it before you build on it.
Permissions enforces policies for a key only while at least one active policy is inside its time window. When the last one is turned off or its window ends, Para stops checking policies on REST and SDK signing. App-owned wallets then sign without checks. User-owned wallets show the same review pop-ups as a key without Permissions, such as those the Transaction Pop-ups setting turns on.
You can keep one draft per policy type. Activate or delete it before you start another.

​
What the forms support

The forms cover common transfer, contract and Safe policies. The actions available depend on the wallet type of the networks you picked.
Enter EVM addresses in lowercase. Native amounts accept ETH or wei. Token amounts use the token’s base units.Execute a Safe transaction takes no conditions in the form. To limit the payment a Safe transaction makes, such as its recipient, amount, asset or Safe spend over a time window, write the rule as JSON with the Safe payment facts.
Recipient and contract argument conditions compare with equals, does not equal or is one of, which takes comma-separated values. Transaction amount compares with equals, does not equal, is greater than, is at least, is less than or is at most. A Transaction amount set per time window offers only the last four. Each action has a condition limit: one condition per Guardrail action and up to eight per Request action. Add Condition turns off when an action reaches its limit. On transfer actions, a Transaction amount can apply per transaction or per time window. A time window counts spend across requests over a number of hours, days or weeks.
Native limits count positive native value: on EVM from any transaction, contract calls included, and on Solana, Cosmos, Stellar and Sui from native transfers. Token limits count ERC-20 transfer calls on EVM, including ERC-20 transfers sent through Para gas sponsorship, and token transfers on Solana, Cosmos and Stellar. Sui has no token limits. Gas and fees never count. Apart from those sponsored transfers, smart account user operations do not count toward EVM limits. A token limit that names an asset counts only that asset. Each network, asset and window has its own budget, so a limit of 1 ETH per day on Ethereum and Base allows 1 ETH per day on each network. Payments a Safe makes count only toward the Safe limits, safe.spend.native and safe.spend.erc20, which keep one budget per Safe. See Metered facts for the full rules.
The forms cannot save message signing, month-based or lifetime spend windows, or optional consent. Policies that target specific wallets or users, combine conditions in other ways, or need adjustable parameters, approval requirements or rules that block or hold raw signatures are written as JSON.
While Permissions is on, raw signatures follow the same defaults as other signing requests: an app-owned wallet signs them, and a user-owned wallet sends them to the user for review. Rules that name the raw_signature action, and rules with "actions": "all", can change that. Raw signatures are sign-raw requests, messages from Solana, Stellar and Sui wallets, and REST sign-message requests from a Cosmos wallet that do not pass walletType: "EVM". The SDKs sign messages from Cosmos wallets as EVM sign_message requests. Raw signatures carry no network a selector can name, so only a policy without chainId governs them. A rule that names raw_signature can read only para.wallet.* facts. The Developer Portal forms cannot create one, so write it in policy JSON, with Edit JSON in the Developer Portal or with the CLI.

​
Edit, turn off or delete a policy

The networks you pick identify a policy. To edit one, you start a new policy of the same type and pick exactly the same networks. Picking different networks creates a separate policy instead.
Save changes on an active policy replaces it immediately, as the next version. Test edits to active policies on the Development key before you rely on them.
Turning an Off policy back on in the Developer Portal does not create the next version. The Portal publishes a copy under a new policy ID, dev-portal-permission-<uuid>, at version 1, activates it and archives the Off record. Update any policy ID your app stores, such as for usage reads or consent links, and on a Request, each user has to consent to the copy. The switch is unavailable, with the reason in its tooltip, while a draft of the same type exists, while another policy of the same type is active on the same networks, and once the policy’s time window has ended. Activate or delete that draft, turn off the other policy, or create a new policy with a current window.

​
Changes that affect open approvals

Saving changes, activating a draft, turning a policy off and turning it back on can all invalidate open approval cases. An approval case is open while it is pending, and after it completes until it is used to sign or expires. Para refuses a change that would invalidate open cases until you confirm it. A confirmed change ends those cases as invalidated, and their requests need a new attempt. The Developer Portal asks in a dialog, Invalidate open approval cases?, which shows how many cases the change affects.
Invalidate open approval cases dialog showing the number of affected cases with Cancel and Save anyway buttons

​
Move to JSON

The Guardrail Logic and Request Logic steps have two tabs: Form and JSON. The JSON tab shows the policy your form generates, marked Engine policy when it can be saved or Preview only when it cannot. Select Edit JSON to edit the policy directly. While JSON edits exist, the Form tab is disabled. Discard JSON edits returns you to the form.
JSON tab on the Guardrail Logic step showing the generated policy preview, the Engine policy badge and the Edit JSON button
Some policies use rules the forms cannot show, such as adjustable parameters or nested condition groups. When you edit one of these, it opens straight in the JSON editor with the notice “This policy has rules the form can’t show, so it can only be edited as JSON.” The Write policy JSON page in your platform’s Permissions guides covers the editor and the CLI.

​
Production keys

Development and production keys keep separate policies, and nothing copies across on its own. On a Production key, the Permissions page is read-only: you can expand rows and read their JSON, but you cannot add, activate, turn off or delete policies. Until Permissions is on for a production key, the key shows a banner with Request production review once a Development key in the same project has an active policy. Selecting it asks Para to review your beta policy and publish it to the production key. The Go to production page in your platform’s Permissions guides covers what to finish first and what happens next.