Guardrail templates

Guardrail templates are tested policies for the app-owned wallets your backend signs with. Pick a scenario, adjust the addresses and amounts, and publish it on beta through the Developer Portal or the CLI. When it behaves as expected there, request a production review to apply it to production. A Guardrail restricts signing. Its rules deny a request or hold it for approval, and a request that no rule blocks signs as usual. When several active Guardrails cover the same wallet, all of them apply, and a block in any of them wins.

Scenario	What the templates do	Developer Portal forms
Spending caps	Limit native and token transfers per transaction or per day, on EVM, Solana and Stellar	Yes
Allowlists	Limit transfers to known recipients and calls to known contracts and functions	Partly
Approval tiers	Hold large transfers for approval, or sign, approve or deny by amount	No, use JSON
Treasury	Deny everything except planned payouts, check Safe payouts by recipient, amount and asset, and require staged approval for each payout	No, use JSON
Message signing	Block or hold raw signatures, and block permit signatures sent through REST	No, use JSON

Each template lists sample signing requests with one of three results: signs, denied, or needs approval. Your platform’s Permissions page shows what your backend receives for each. Raw signatures sign by default as well, and no transfer rule can read them. The message signing templates show how to block or hold them:

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.

Choose a scenario

Use a template

Every template comes with a JSON policy. Templates the Developer Portal forms can express also list the form steps. Publish each one on your Development key, which runs on beta, and test it there first.

Developer Portal forms
Developer Portal JSON editor
CLI

Follow the template’s Developer Portal tab. A policy saved from the forms gets generated policy and rule IDs, and its JSON can differ in small ways that the template points out. Compare it with the Normalized policy JSON on the Review step before you select Save Draft.

On your Development key, open Permissions, select the Guardrails or Requests tab, and select Add. Once the tab lists policies, the button is New Guardrail or New Request.
Enter a name, select the networks the template’s selector names, and select Continue.
Select the JSON tab, then Edit JSON.
Replace everything in Policy JSON with the template and select Review. Para validates the policy before anything is saved, and the template’s metadata.description replaces the name you entered.
Select Save Draft, then Activate on the draft.

Save the template to a file, then validate it, create a draft and activate it on your beta key:

para keys permissions validate KEY_ID --file policy.json --environment beta
para keys permissions create KEY_ID --file policy.json --environment beta
para keys permissions activate RECORD_ID KEY_ID --environment beta

create prints the draft’s record ID and the exact activate command to run.

If your key already has a policy of the same type on the same networks, the Developer Portal opens that policy for editing, and the page title changes to Edit Guardrail Policy or Edit Request Policy. The editor holds that policy’s JSON with the next version filled in. Merge the template’s rules into it and keep its id, selector and version, because pasting the template over it fails with policy_record_identity_conflict, policy_record_selector_conflict or policy_record_version_conflict. The button there is Save changes, and an active policy enforces the merged rules as soon as you save.

Conventions

The templates share a few conventions. Keep them when you adapt a template, or validation fails.

Amounts

Amounts are strings of whole base units, such as "1000000". A JSON number fails validation with value_type_mismatch.

Asset	Decimals	1 unit in base units
ETH (wei)	18	`1000000000000000000`
USDC on EVM networks	6	`1000000`
SOL (lamports)	9	`1000000000`
XLM (stroops) and Stellar assets such as USDC	7	`10000000`

Addresses

Para lowercases EVM addresses before it compares them, so checksummed and lowercase addresses match. The templates use lowercase, as the Developer Portal does. Other wallet types need each network’s canonical form: a Solana base58 key as is, a Stellar G… account in upper case, and a Sui 0x address with 64 lowercase hex characters.

Networks

chainId in the selector picks the networks a policy covers. Omit it to cover every network of the wallet type. A personal message and a raw signature carry no network, and the Para SDKs sign typed data and authorizations as messages, so the message signing templates leave chainId out. The treasury templates leave it out as well and check the network through each asset value, such as eip155:8453:native. The other templates use mainnets. To test with testnet funds, swap in the testnet everywhere the template names the network, including asset values and token addresses.

Wallet type	Templates use	Testnet	Accepted forms
EVM	`8453` (Base)	`84532` (Base Sepolia), where USDC is `0x036cbd53842c5426634e7929541ec2318f3dcf7e`	Numeric chain ID or `eip155:<id>`
SOLANA	`solana:mainnet`	`solana:devnet`	`solana:mainnet`, `solana:devnet`, `solana:testnet`
STELLAR	`stellar:mainnet`	`stellar:testnet`	`stellar:mainnet`, `stellar:testnet` or the network passphrase, which the Developer Portal writes

IDs, versions and windows

Give each policy an id your key does not use yet. IDs that start with para- are reserved.

Raise version when you publish a change to a policy.
window: "24h" is a fixed daily window that resets at 00:00 UTC, not 24 hours after the first transfer. The Developer Portal writes windows in hours, and 1d is the same window. A policy can use one window length per spend fact.

Production keys are read-only in the Developer Portal. Once a template behaves as expected on beta, request a production review from your Production key, and Para applies your active beta policies to production.

Get Started

Set Up Project

Manage Sessions

Use Pregeneration

Sign from Server

Add Permissions

Add Advanced Features

Guardrail templates

Choose a scenario

Use a template

Conventions

Amounts

Addresses

Networks

IDs, versions and windows

​Choose a scenario

​Use a template

​Conventions

​Amounts

​Addresses

​Networks

​IDs, versions and windows

Choose a scenario

Use a template

Conventions

Amounts

Addresses

Networks

IDs, versions and windows