Skip to main content
App-owned wallets can sign by default through your authenticated backend. Guardrails restrict selected signing requests, and raw signatures need a rule that allows them. 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 wallets. The Developer Portal forms cover a subset of policy shapes; use JSON authoring or work with Para for other supported configurations. Each policy selects one wallet type and can narrow it to specific networks, and each rule names the actions it governs. 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. To start from a common policy shape, see Guardrail templates.
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: For Solana, Cosmos, Stellar, and Sui policies, it exposes these actions: The Developer Portal supports one authored condition per action. Advanced JSON policies can use other supported 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 action that no active Guardrail covers remains allowed for the app-owned wallet.
Raw signatures are the exception to step 5.While Permissions is on, Para denies raw signatures for app-owned and user-owned wallets unless an active policy that applies to the wallet has a rule allowing the raw_signature action. Raw signatures include sign-raw requests and message signing from wallets that cannot sign as EVM, such as Solana, Stellar, and Sui wallets. The Developer Portal forms cannot create this rule; use JSON authoring.A denied POST /v1/wallets/{walletId}/sign-raw on any wallet, or POST /v1/wallets/{walletId}/sign-message on a Solana, Cosmos, Stellar, or Sui wallet, returns 403 POLICY_DENIED with the reason raw-signature-not-allowed. To allow them, add a rule with effect allow and actions ["raw_signature"] to an active Guardrail for that wallet type.

​
Handle a denial

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. The response body names the denial:
The REST SDK exposes this body as ParaRestError.body. policyId and ruleId are present when a specific rule decided the outcome. Handle a denial as an expected application-level rejection and log enough request context to identify the attempted action.
A Solana or Sui request whose network field contradicts the network Para proves for the transaction returns 400 INVALID_REQUEST, not a policy denial. Correct the network value before sending it again.

​
Conditional approvals

A matching conditional approval requirement pauses signing with an HTTP 403 and the code POLICY_REVIEW_REQUIRED. No signature is produced while the requirement remains unsatisfied. The response body includes: 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.
Para keys each case to the request’s Idempotency-Key, or to a hash of the payload when the request has no key. Retry with the same Idempotency-Key and an identical body to continue the case. A new key opens a new case, and the same key with a different transaction returns 409 CONFLICT.
Replacing or deactivating the policy that required an approval invalidates the approval if it has not completed. An invalidated approval cannot complete; submit the request again under the current policy.A rejected or expired case cannot complete either. When you send a request again, use a new Idempotency-Key so Para opens a new case.
Conditional approvals require the wallet to be bound to an authorization scope. Without a binding, a request that matches an approval requirement returns 403 FORBIDDEN. 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

An amount condition can apply to each transaction or to cumulative spend over a fixed window. Cumulative limits are available for every wallet type. Spending limits cover native transfers on every wallet type and token transfers on EVM (ERC-20), Solana, Cosmos, and Stellar. Sui limits cover native transfers only. A token limit counts only the asset it names. Each network and asset has its own budget, so a limit of 1 ETH per day on Ethereum and Base allows 1 ETH per day on each network. Amounts Para cannot decode do not count toward a limit. Smart account user operations do not count toward EVM limits, except ERC-20 transfers sent through Para gas sponsorship. Cumulative limits:
  • Use the asset’s base unit.
  • Use a window of hours, days, or weeks in the Developer Portal, or a positive integer with ms, m, h, or d in JSON.
  • Are scoped to the API key, wallet, network, asset, and window.
  • Do not include gas or fees.
ERC-20 limits count direct transfer(address,uint256) calls. 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.