Skip to main content
Request templates are tested policies that ask the owners of user-owned wallets for standing access. Pick a scenario, adjust the addresses and amounts, and publish it on beta through the Developer Portal or the CLI. Try the consent screen there with test users before you request a production review, because every user sees it before your app gets standing access. A Request describes what your app may do without prompting the user each time. Para shows it to the user on a consent screen, and the user chooses one of two options:
  • Approve grants standing access. Signing requests that match an allow rule then sign without a prompt.
  • Manually approve each transaction instead keeps the user in the loop. Each matching signing request opens Para’s review window.
A signing request that no rule matches goes to the user for review, as it would without the Request. When the first matching signing request arrives before the user has decided, the consent screen opens ahead of the review for that request. Standing access starts with the next request once the user approves this one. If they reject this request, or an approver rejects its approval case, the standing access is cancelled too.
The policy’s description is the text users see on the consent screen, after your app name and “would like to”. In the Developer Portal it is the User consent request language field. Write it as a short action, such as Send up to 0.01 ETH per transfer on Base.

​
Choose a scenario

Each scenario page has the policy JSON, sample signing requests with their results, and the values to change for your app.

​
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.
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.
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.

​
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.

​
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.