Message and raw signing

Message signing works differently from transfers. On an app-owned EVM wallet, personal messages and typed data sign unless a Guardrail blocks them, and so do raw signatures:

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.

Para cannot read what a raw signature signs, so spending caps, allowlists and other rules about transfers and contract calls never apply to one. These templates block or hold raw signatures for wallets that should not produce them, and block the typed data signatures that can hand over funds. The Developer Portal forms cannot express any of them, so publish them as JSON.

Block raw signatures

Use this when your backend never calls sign-raw with its EVM wallets, for example because it only sends transfers that your other Guardrails check.

guardrail-block-raw-signatures.json

{
  "id": "evm-block-raw-signatures",
  "schemaVersion": "permissions.policy.v1",
  "version": "1",
  "selector": {
    "walletType": "EVM"
  },
  "rules": [
    {
      "id": "deny-raw-signatures",
      "effect": "deny",
      "actions": ["raw_signature"],
      "when": { "kind": "compare", "fact": "para.wallet.hasUserOwner", "op": "eq", "value": false }
    }
  ],
  "metadata": {
    "productMode": "guardrail",
    "description": "Block raw signatures from app-owned EVM wallets"
  }
}

A Guardrail applies only to app-owned wallets, where para.wallet.hasUserOwner is always false, so the rule denies every raw signature from them. Personal messages and typed data are separate actions, so this policy leaves them alone.

Signing request	Result
REST: `sign-raw` with an app-owned EVM wallet	Denied by `deny-raw-signatures`
Sign a personal message or typed data	Signs, because this policy does not cover it
Send ETH or tokens	Not limited by this policy

Test it on your Development key: call REST sign-raw with an app-owned EVM wallet before and after you activate the policy. The first request signs and the second is denied.

To block raw signatures for some wallets only, list their IDs in the selector as walletId. For Solana, Stellar or Sui wallets, copy the policy with a new id and change walletType. On those wallet types every message is a raw signature, so the copy blocks message signing as well. Cosmos wallets need more, as Cosmos wallets explains.

Hold message signing for approval

Use this when your backend signs messages with app-owned Solana wallets only now and then, for example to prove wallet ownership to another service, and a person should confirm each one.

Para turns on conditional approvals per API key, so your beta and production keys are enabled separately. Until it does, validating or saving this policy fails with permissions_v2_extension_unavailable.

guardrail-solana-message-signing.json

{
  "id": "solana-review-message-signing",
  "schemaVersion": "permissions.policy.v1",
  "version": "1",
  "selector": {
    "walletType": "SOLANA"
  },
  "rules": [
    {
      "id": "review-message-signing",
      "effect": "require_approval",
      "actions": ["raw_signature"],
      "when": { "kind": "compare", "fact": "para.wallet.hasUserOwner", "op": "eq", "value": false },
      "approvalRequirement": {
        "id": "message-signing-review",
        "evidence": "authenticated_approval",
        "stages": [
          { "id": "reviewer", "requiredApprovals": 1, "eligibility": [{ "kind": "role", "name": "signing-reviewer" }] }
        ]
      }
    }
  ],
  "metadata": {
    "productMode": "guardrail",
    "description": "Hold message signing from app-owned Solana wallets for approval"
  }
}

Each message opens an approval case for one person with the signing-reviewer role. Set them up as in the approval tiers templates: once the policy is active, your backend assigns the role in an authorization scope and binds the wallet to that scope.

Signing request	Result
Sign a message with an app-owned Solana wallet	Needs approval from one `signing-reviewer`
Send SOL or call a program	Not limited by this policy

The case covers that exact message. When it is completed, send the same request again: through REST with the same Idempotency-Key, or through the server SDK with the case ID as resumeApprovalCaseId.

Test it on your Development key: assign signing-reviewer to a test user and bind the wallet. Sign a message with the app-owned Solana wallet through REST with an Idempotency-Key, approve the case as that user, and send the request again with the same key to sign it.

For Stellar or Sui wallets, copy the policy with a new id and change walletType. Each wallet type needs its own policy.

Cosmos wallets

A Cosmos wallet can also sign as an EVM wallet, so its messages are raw signatures only on some routes. A copy of either template with walletType set to COSMOS covers those routes, and an EVM policy covers the others:

Signing request from an app-owned Cosmos wallet	Action	Policy that covers it
REST `sign-raw`	`raw_signature`	The `COSMOS` copy
REST `sign-message` without `walletType: "EVM"`	`raw_signature`	The `COSMOS` copy
REST `sign-message` with `walletType: "EVM"`	`sign_message`	An EVM policy without `chainId` whose rule lists `sign_message`
Server SDK `signMessage`	`sign_message`	An EVM policy without `chainId` whose rule lists `sign_message`

evm-block-raw-signatures does not cover the last two rows, because they are sign_message requests. To block or hold every message from a Cosmos wallet, add the COSMOS copy and an EVM policy whose rule lists sign_message. List the Cosmos wallet’s ID as walletId in the EVM policy, or it also applies to messages from your EVM wallets.

Block permit and authorization signatures

A permit is typed data that lets another address spend the wallet’s tokens without a transaction from the wallet. An EIP-7702 authorization lets the account run another contract’s code. Both can move funds later, outside any transfer cap. Use this template when your backend should never sign either one.

The Para client and server SDKs, including their viem, ethers and wagmi integrations, sign EIP-712 typed data and EIP-7702 authorizations as a message over their hash, so Para evaluates those requests as sign_message. The sign_typed_data and sign_authorization actions, and the facts Para reads from typed data and authorizations, such as request.typedData.primaryType, apply only to the REST API’s sign-typed-data and sign-authorization routes, which the REST SDK calls.This template cannot inspect a permit or an authorization your backend signs through the server SDK.

guardrail-block-permit-signatures.json

{
  "id": "evm-block-permit-signatures",
  "schemaVersion": "permissions.policy.v1",
  "version": "1",
  "selector": {
    "walletType": "EVM"
  },
  "rules": [
    {
      "id": "block-permits-and-authorizations",
      "effect": "deny",
      "actions": ["sign_typed_data", "sign_authorization"],
      "when": { "kind": "compare", "fact": "request.approvalLike", "op": "eq", "value": true }
    }
  ],
  "metadata": {
    "productMode": "guardrail",
    "description": "Block permit and EIP-7702 authorization signatures"
  }
}

Para sets request.approvalLike to true for every authorization, and for typed data whose primary type contains permit in any letter case, such as Permit, PermitSingle or PermitBatch. Typed data with any other primary type is not affected.

Signing request	Result
REST: sign typed data with primary type `Permit` or `PermitSingle`	Denied by `block-permits-and-authorizations`
REST: sign an EIP-7702 authorization	Denied by `block-permits-and-authorizations`
REST: sign typed data with primary type `Order`	Signs
Sign a personal message	Signs
Server SDK: sign a permit or an authorization	Signs, because Para sees it as a personal message

Test it on your Development key: through the REST sign-typed-data endpoint, sign an EIP-2612 Permit with an app-owned EVM wallet, then sign a personal message. Only the permit is denied.

To block all typed data and authorizations on REST, whatever their primary type, replace the condition with { "kind": "compare", "fact": "para.wallet.hasUserOwner", "op": "eq", "value": false }. If your backend signs through the server SDK, also add sign_message to the rule’s actions. That is the only way to stop permits and authorizations there, and it also blocks every personal message.

Publish your signing rules

Wallets and roles belong to each environment. Before you request a production review, confirm that each policy names the wallet types and wallets you mean to restrict in production. After the review, assign signing-reviewer there and bind the production wallets. A policy with a walletId needs the production wallet’s ID.

Get Started

Set Up Project

Create and Manage Wallets

Sign and Transact

Add Permissions

Use Pregeneration

Endpoints

Message and raw signing

Block raw signatures

Hold message signing for approval

Cosmos wallets

Block permit and authorization signatures

Publish your signing rules

​Block raw signatures

​Hold message signing for approval

​Cosmos wallets

​Block permit and authorization signatures

​Publish your signing rules

Block raw signatures

Hold message signing for approval

Cosmos wallets

Block permit and authorization signatures

Publish your signing rules