Skip to main content
Pick the build path that matches the wallets your app signs with, then work through the planning questions with your team before anyone writes a policy. If Permissions is new to you, read How permissions work first.

​
Choose your path by wallet ownership

Wallet ownership decides which kind of policy you write. Each platform’s path walks through the Developer Portal forms, policy JSON, templates, testing and production for that kind of policy.

​
App-owned wallets use Guardrails

Your backend controls these wallets and signs with them, for example for treasury or payouts. Guardrails block or hold the transactions you never want them to sign.

​
User-owned wallets use Requests

Your users sign in to Para and control these wallets. A Request asks each user to let your app sign certain transactions without a prompt every time.
If your app signs with both kinds of wallet, follow both paths. A Guardrail’s rules never apply to user-owned wallets, and a Request’s rules never apply to app-owned wallets. Activating either kind still turns on Para’s defaults for every wallet on your app’s API key, as the Warning below explains.
Policies belong to an API key, and your Development and Production keys each keep their own. Permissions turns on for the whole API key as soon as any policy on it is active. From then on, a request from a user-owned wallet that no accepted Request covers goes to the user for review, even if the key’s only active policies are Guardrails. Before you activate a Guardrail on a key your users also sign with, plan Requests for the transactions they should not have to review, or expect those reviews.

​
Plan your policies

Work through these questions with your product and engineering leads. Each answer maps to a part of the policy, so together they give you a short spec for your first version.
1

Which wallets and networks

List the wallet types and networks your app signs on. Each policy covers one wallet type, so plan a policy for each type you want rules for. A policy can cover every network of its type or only the ones you list, and it can narrow further to specific wallets.
2

What to allow or stop

List the transactions your app signs, such as native transfers, token transfers, contract calls and message signing. For a Guardrail, decide what to block and what to hold for approval. For a Request, decide what to ask users to allow, and write the one-line description they will read on the consent screen.Decide which app-owned wallets should never produce raw signatures, where a wallet signs arbitrary data instead of a transaction or message Para can decode. By default, an app-owned wallet signs them and a user-owned wallet sends them to the user for review. To block or hold them, plan a Guardrail that covers every network of the wallet type, because raw signatures carry no network.If your treasury is a Safe on an EVM network with Para wallets as owners, decide which recipients, amounts and assets its payments may have. Para can read only a single, direct native or ERC-20 payment from the Safe. It cannot read any other Safe transaction, such as a batched payment, a delegate call, a nested Safe call, a payment that refunds gas to a relayer, another contract call or a change to the Safe’s own settings. A rule on the payment’s recipient, amount or asset blocks every Safe transaction Para cannot read. If your treasury needs those transactions, run them from a Safe whose owner wallets that rule does not cover, or plan for them to be blocked. How permissions work explains how Para reads Safe payments.Owner wallets can also approve a Safe payment directly on chain. Para sees that approval as an ordinary contract call, so Safe payment rules never check it. Plan to block contract calls from the owner wallets to the Safe, as the treasury template for REST API and Node & Server does.
3

Limits and windows

Set amount caps per transaction and spending limits over a time window, such as 500 USDC per day. Para counts each limit separately for every wallet, network and asset, so a daily limit of 1 ETH on Ethereum and Base allows 1 ETH a day on each network. A Safe spending limit is shared by every Para wallet in your app that owns the Safe.
A Safe spending limit counts only the Safe payments Para can read. Safe transactions Para cannot read and payments an owner approves directly on chain do not count toward it, and the limit alone does not stop them. Pair the limit with a rule on the payment’s recipient, amount or asset, and block contract calls from the owner wallets to the Safe, as described in the previous step.
Time windows are fixed, not rolling. A daily limit resets at 00:00 UTC, not 24 hours after the first payment.
4

Who approves

For payments that need sign-off, name the approver groups, how many approvals each stage needs, and the amount where each stage starts. For example, payments over 10,000 USDC need one finance approver, and payments over 50,000 USDC also need the CFO.Your backend assigns people to these groups, and approvers sign in to Para to decide. Only Para users with a wallet linked to your app can be assigned.The person who asked for a payment cannot approve it. For an app-owned wallet, Para knows who asked only when your backend names that user in the request, and that user also needs a wallet linked to your app, so plan where that identity comes from. Decide when your app should cancel an open approval and how it retries an interrupted request. How permissions work covers rejection, expiry and when an approval carries over to a rebuilt transaction.
Changing approvers, approval settings or the policy itself can invalidate open approvals. Para asks for explicit confirmation before such a change, and once you confirm, those requests need new approvals.
5

What users or managers can adjust

A Request can let each user choose their own value for a limit you declare, such as a daily cap, on the consent screen or in your app. An approval requirement can expose settings, such as how many approvals a stage needs or the amount where a stage starts, that your backend or a manager you name can change later without publishing a new policy version. You decide the allowed values for each setting, for example two to four approvals, or a choice between two approver groups. An amount threshold can only move lower than the one you publish, unless you allow a higher maximum.
You can give each adjustable limit a minimum and a maximum. Without a maximum, a user can set a limit above your default, so set one unless any value the user picks is acceptable to you.
6

How you will test on beta

Build each policy on your beta key, labeled Development in the Developer Portal. Plan a test request for each outcome you expect: one that signs, one that is denied, one that goes to the user for review and one that needs approval. Include requests just under and just over each limit. If you use approvals, also test a requester trying to approve their own payment, a cancelled approval and a resumed request. If you use a Safe, test a batched Safe payment too.
7

When to request production review

When beta behaves as planned, request a production review from your Production key in the Developer Portal. Para reviews the policy and applies it to production, where it cannot be edited from the Developer Portal or the CLI. Leave time for the review in your launch plan, and see Production for the steps.
Approval requirements and adjustable limits work only after Para turns them on for you. Ask Para to enable them before your plan depends on them.

​
Choose how you will build

The Developer Portal forms cover common policies, such as amount caps, spending limits and recipient or contract allowlists. Approval requirements, adjustable limits, raw-signature rules and more complex conditions need policy JSON, which you can paste into the Developer Portal’s JSON tab or submit with the CLI. Every platform path above covers both, starting with the forms.