Skip to main content
App-owned wallets can sign by default through your authenticated backend. Guardrails restrict selected signing requests; conditional approval requirements can hold a request until the configured people approve it. Your server secret authenticates the application, not a human approver. What you’ll learn: configure a Guardrail, understand signing outcomes, and connect approval requirements to backend administration.
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.
Ordinary Guardrails allow or deny requests without asking for user consent. A policy with conditional approvals adds a separate approval flow. For user-owned SDK wallets, configure Requests: consent grants the application the standing access specified by the policy.

​
Configure a Guardrail

Create and test Guardrails against a Development API key in the Developer Portal:
  1. Open Permissions and select Guardrails.
  2. Select Add, choose the networks, and optionally set a policy window.
  3. Add each transaction action you want to guard and the condition that defines its permitted boundary.
  4. Review the normalized policy and save it as a draft.
  5. Activate the draft, then test a transaction inside the boundary and one outside it.
Follow the Developer Portal walkthrough for the full setup and production review process.
A saved draft does not enforce anything. Activation changes signing behavior for the selected API key.

​
Developer Portal actions

The Developer Portal walkthrough above exposes these EVM transaction actions: The Developer Portal supports one authored condition per action. Advanced JSON policies can use the supported non-EVM facts and nested conditions described in the Permissions Reference. Use authenticated CLI authoring on beta or contact Para for help with a policy beyond the Portal controls.

​
Enforcement behavior

For a Guardrail created with these Developer Portal forms, when the REST API receives a transaction signing request:
  1. Para selects the active Guardrail policies that match the API key and transaction selector.
  2. Para evaluates the transaction action and its configured boundary.
  3. A transaction inside the boundary continues to signing.
  4. A transaction outside the boundary is rejected before signing.
  5. A transaction type that is not covered by an active Guardrail remains allowed for the app-owned wallet.
A policy denial returns an HTTP 403 with the code POLICY_DENIED. No signature is created, no transaction is broadcast, and no pending user review is created. Handle this response as an expected application-level rejection. Log enough request context to identify the attempted action, but do not retry the same transaction without changing the transaction or the policy.

​
Conditional approvals

A matching conditional approval requirement pauses signing with POLICY_REVIEW_REQUIRED. The error data includes approvalCaseId when a conditional approval case was created. Read that case with getPartnerApprovalCase(approvalCaseId) and present its state in your application. No signature is produced while the requirement remains unsatisfied. Eligible people authenticate and complete their approval through the user flow. The partner backend can inspect cases and administer allowed configuration, but cannot approve on a person’s behalf. After the case is approved, retry the original signing request; Para evaluates it again before signing. Authenticated approvals record people’s decisions. Signature-based requirements collect the configured wallet signatures; completing a case does not itself assemble or broadcast an onchain multisig transaction.

Manage permissions from your backend

Assign roles, bind wallet scopes, configure declared approval settings, and read approval cases.

​
Selectors and versions

The Portal selects current Guardrails by their complete network set. Ethereum + Base is the same selector regardless of order. Base only is a different selector, so it can have an independent Guardrail. Editing an active Guardrail for the same selector creates its next version and replaces the active version when you select Save changes. Editing a draft keeps the new version in draft. A different selector starts a separate Guardrail.

​
Windowed spend limits

For EVM native and direct ERC-20 transfers, an amount condition can apply to each transaction or to cumulative spend over a fixed window. Cumulative limits:
  • Use the asset’s base unit.
  • Support positive windows in hours, days, or weeks.
  • Are scoped to the API key, wallet, network, asset, and window.
  • Do not include gas or fees.
Direct ERC-20 limits cover transfer(address,uint256). They do not aggregate approvals, transferFrom, router calls, multicalls, non-transfer contract calls, or USD-normalized amounts.

​
Production

Development and Production API keys do not share policy records. Creating a Production key does not copy or activate the tested Development Guardrail. Para reviews the active Development policy and independently publishes the approved production policy. The Production Permissions page is read-only.

Permissions setup

Follow the Development draft, activation, testing, and production workflow.

Permissions reference

Review policy JSON, selectors, actions, conditions, and current limits.