Skip to main content
Production Guardrails apply to the app-owned wallets that your production secret key signs with. Para publishes production policies after reviewing the policy you tested on beta. This page covers what to finish before you ask, how to request the review, how later changes reach production and what users notice when a policy changes.

​
Beta and production are separate

Each API key has its own policies, and beta and production are separate environments. Creating a production key copies nothing from your Development key. Until Para publishes a policy to it, the production key keeps its current signing behavior.

​
Finish on beta first

The review starts from the policy that is active on your Development key. Before you request it:
  1. Run your full test matrix against the version you want to ship.
  2. Keep that version active on a Development key in the same project as the production key. The review can only be requested while one is active.
  3. Tell Para which values differ in production, such as chain IDs, token contracts, recipients and Safe addresses. Para already has the beta policy and copies it after review with the production values you confirm.
  4. Check the features the policy uses. Approval requirements and adjustable parameters are enabled per key, so confirm with Para that the production key will have them.
  5. If the policy uses approvals, prepare your production backend: assign approver roles and bind wallets to authorization scopes again with the production secret key, because beta assignments do not carry over.

​
Request production review

The review request lives on the production key in the Developer Portal. It tells Para which project and keys to review; it does not copy anything by itself.
1

Open the production key

In the key switcher, select your Production key. While Permissions is off for that key and a Development key in the same project has an active policy, a banner across the top of the key’s pages asks you to request a review.
2

Request the review

Select Request production review. The button changes to Review requested and a Production review requested. message confirms it. The button remembers this only for the current browser session, and the banner stays until Para turns Permissions on for the key.
3

Para reviews and publishes

Para reviews your active beta policy and copies the approved policy to the production key with its production values. Publishing turns Permissions on for that key.
4

Verify before you send traffic

Open Permissions on the production key, expand each policy and compare its Normalized policy JSON with the policy you tested.
If the request fails with “Production review is not available yet”, check that a Development key in the same project has an active policy and that Permissions is still off on the production key. If it fails to deliver, select the button again.

​
Change a production policy

The banner appears only while Permissions is off for the production key, so later changes go through Para directly. Changing, turning off or deleting a beta policy never changes production.
  1. Make the change on your Development key and rerun the tests it affects.
  2. Contact Para support to review the new version and publish it to the production key.
  3. Verify the published version on the production key.

​
What users notice after a change

A published change applies to the next signing request on the production key. What users see depends on the policy type.
No one is asked to consent. The new version starts deciding requests as soon as it is published.
An approval case that has not been used to sign is invalidated when the active policies that apply to its request change, for example when a policy is replaced, activated or turned off. An invalidated case cannot complete, so start a new request to open a new case.