Message signing

These templates let your app sign messages from a user’s wallet without a prompt for each one, such as the sign-in proofs your app creates. The Developer Portal forms cannot create message signing permissions yet, so publish them as JSON with the Developer Portal JSON editor or the CLI.

No condition can read the content of a message. Once the user approves, every message your app sends for signing in the covered wallet type signs without the user seeing it. Use these templates only for messages your app builds itself, and write a description that tells the user what they are signing and why.

Sign messages from EVM wallets

Use this for personal messages (personal_sign) from a user’s EVM wallet. Without it, each message goes to the user for review.

request-evm-message-signing.json

{
  "id": "evm-message-signing",
  "schemaVersion": "permissions.policy.v1",
  "version": "1",
  "selector": {
    "walletType": "EVM"
  },
  "rules": [
    {
      "id": "allow-personal-messages",
      "effect": "allow",
      "actions": ["sign_message"],
      "when": { "kind": "compare", "fact": "request.classification", "op": "eq", "value": "message_signing" }
    }
  ],
  "metadata": {
    "productMode": "delegation",
    "description": "Sign messages with your wallet"
  }
}

The policy uses sign_message and has no chainId, because a message carries no network and a policy that names one never matches it. The SDKs sign messages from a user’s Cosmos wallet as EVM personal messages, so this template covers them too.

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.Once the user approves this policy, typed data and authorizations your app signs through the SDK also sign without a prompt. That includes permits, which let another address spend the user’s tokens, and authorizations, which hand the account to another contract’s code. No condition can tell them apart from a personal message. Publish this template only if your app never signs typed data or authorizations for the user.

Signing request	Result
Sign a personal message after the user approved	Signs without a prompt
Sign typed data or an authorization through the SDK after the user approved	Signs without a prompt, as a message over its hash
Send a transaction	Goes to the user for review, because this policy does not cover it

Test it on your Development key: sign a message from a test user’s wallet, approve the consent screen, then sign the message. Sign another message and it signs without a prompt.

Sign messages from Solana wallets

On Solana, Stellar and Sui, every message is a raw signature. Without a Request, each one goes to the user for review:

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.

This template lets your app sign raw signatures from users’ Solana wallets without a prompt once the user approves.

request-solana-message-signing.json

{
  "id": "solana-message-signing",
  "schemaVersion": "permissions.policy.v1",
  "version": "1",
  "selector": {
    "walletType": "SOLANA"
  },
  "rules": [
    {
      "id": "allow-message-signing",
      "effect": "allow",
      "actions": ["raw_signature"],
      "when": { "kind": "compare", "fact": "para.wallet.hasUserOwner", "op": "eq", "value": true }
    }
  ],
  "metadata": {
    "productMode": "delegation",
    "description": "Sign messages with your Solana wallet"
  }
}

para.wallet.hasUserOwner is always true for the user-owned wallets a Request covers, so the rule matches every message.

Signing request	Result
Sign a message from a Solana wallet after the user approved	Signs without a prompt
Sign a message after the user chose Manually approve each transaction instead	Goes to the user for review
Send SOL	Goes to the user for review, because this policy does not cover it

Test it on your Development key: open the URL that getPolicyConsentUrl returns for a test user and approve the consent screen. A message from that user’s Solana wallet then signs without a prompt.

For Stellar or Sui wallets, copy the policy with a new id and change walletType to STELLAR or SUI. Each wallet type needs its own policy and its own consent. Cosmos wallets need no copy, because the EVM template covers their messages.

Publish your message signing permissions

Users see your description on the consent screen before anything else, so make sure it names the messages your app signs. Check how it reads on beta before you request a production review.

Get Started

Set Up Project

Add Authentication

Build Wallet UI

Sign with Para

Transact on Chains

Add Permissions

Manage Sessions

Add Advanced Features

Debug and Launch

Sign messages from EVM wallets

Sign messages from Solana wallets

Publish your message signing permissions

​Sign messages from EVM wallets

​Sign messages from Solana wallets

​Publish your message signing permissions

Sign messages from EVM wallets

Sign messages from Solana wallets

Publish your message signing permissions