Skip to main content
Permissions let you define guardrails on your REST API wallets. Set up a policy through the Para dashboard that specifies what transactions are allowed, and Para enforces it on every signing request. If a transaction violates the policy, the request is denied before anything is signed.
Permissions are opt-in. If you don’t create a policy, all signing requests are allowed (existing behavior). Once a policy is active, it becomes deny-by-default — transactions must match an ALLOW rule.

Key Concepts

  • One active policy per API key. Each policy contains one or more scopes, and each scope contains permission rules.
  • Deny-by-default. When a policy exists, any transaction that doesn’t match an ALLOW rule is denied.
  • DENY always wins. If a transaction matches both an ALLOW and a DENY rule, it’s denied.
  • Windowed spend limits. Direct native transfers and direct ERC-20 transfers can be limited by cumulative amount per fixed time window.
  • EVM only. Permissions currently evaluate EVM transactions. Solana and Cosmos are not yet supported.

How Enforcement Works

When you call any signing endpoint (sign-raw, sign-message, sign-typed-data, sign-transaction, transfer), Para checks whether a policy exists for your API key. If one does, the transaction is evaluated against every scope and permission in the policy. If the transaction is denied, you get a 403 response with details about which rule blocked it:
{
  "code": "POLICY_DENIED",
  "message": "Transaction denied by policy",
  "deniedBy": {
    "scopeName": "Token Transfers",
    "permissionType": "TRANSFER",
    "condition": {
      "resource": "TO_ADDRESS",
      "comparator": "CONTAINED_IN",
      "reference": ["0xabc...", "0xdef..."]
    }
  }
}
The deniedBy field tells you exactly which scope, permission type, and condition caused the denial, making it straightforward to debug. Windowed spend denials use the same 403 POLICY_DENIED response. Para denies the request before signing, so no transaction is broadcast and no pending user review is created for REST API wallets.

Permission Types

Each permission targets a specific kind of signing operation:
TypeApplies To
SIGN_MESSAGEsign-message, sign-typed-data, and sign-raw endpoints
TRANSFERtransfer endpoint (native token sends)
CALL_CONTRACTsign-transaction when calling a contract function
DEPLOY_CONTRACTsign-transaction when deploying a contract

Condition Reference

Conditions narrow when a permission applies. Every condition has a resource (what to check), a comparator (how to check), and a reference (expected value).

Resources

ResourceDescriptionUsed With
VALUETransaction value in weiTRANSFER, CALL_CONTRACT
TO_ADDRESSDestination addressTRANSFER, CALL_CONTRACT
MESSAGEThe message being signedSIGN_MESSAGE
ARGUMENTSContract function arguments (e.g., ARGUMENTS[0])CALL_CONTRACT

Comparators

ComparatorDescriptionReference Type
EQUALSExact matchSingle value
NOT_EQUALSMust not matchSingle value
GREATER_THANNumeric greater thanNumber string (wei)
LESS_THANNumeric less thanNumber string (wei)
CONTAINED_INMust be one of the listed valuesArray of values
NOT_CONTAINED_INMust not be any of the listed valuesArray of values

Windowed Spend Limits

Use a WINDOWED_SPEND_LIMIT condition when a REST API wallet should automatically sign only up to a cumulative amount in a fixed time window. The reference object must include:
FieldDescription
assetTypeNATIVE for native token transfers, or ERC20 for direct ERC-20 transfers
tokenAddressERC-20 token contract address. Required for ERC20, omitted for NATIVE
limitBaseUnitsMaximum amount in the asset’s smallest unit, as a decimal string
windowMsFixed window length in milliseconds
Windowed spend limits count transaction value only. They do not include gas or fees, and each limit is scoped by API key, wallet, chain, asset, and window length.

Limitations

  • EVM only. Solana and Cosmos transactions are not evaluated against policies.
  • Direct transfers only. Windowed spend limits cover native transfers and ERC-20 transfer(address,uint256). They do not cover approvals, transferFrom, router calls, multicalls, non-transfer contract calls, USD-normalized limits, or cross-asset aggregate limits.