Skip to main content
These templates cap how much an app-owned wallet can send, per transaction or per day. Each one covers a single asset on a single network, so pick the closest match and change the amounts. Daily caps use a fixed window that resets at 00:00 UTC. A transfer counts toward the day’s total once Para signs it, whether or not you broadcast it, and a denied transfer does not count.
Native limits count positive native value: on EVM from any transaction, contract calls included, and on Solana, Cosmos, Stellar and Sui from native transfers. Token limits count ERC-20 transfer calls on EVM, including ERC-20 transfers sent through Para gas sponsorship, and token transfers on Solana, Cosmos and Stellar. Sui has no token limits. Gas and fees never count. Apart from those sponsored transfers, smart account user operations do not count toward EVM limits. A token limit that names an asset counts only that asset. Each network, asset and window has its own budget, so a limit of 1 ETH per day on Ethereum and Base allows 1 ETH per day on each network. Payments a Safe makes count only toward the Safe limits, safe.spend.native and safe.spend.erc20, which keep one budget per Safe. See Metered facts for the full rules.

Cap ETH per transaction and per day

Use this to limit what a compromised or misbehaving backend can move. The policy denies an ETH transfer on Base above 0.1 ETH, and any ETH transfer that would take the day’s total above 1 ETH.
  1. On your Development key, open Permissions, select the Guardrails tab, and select Add or New Guardrail.
  2. Enter a Guardrail Policy Name. In Networks, clear Ethereum (1), select Base (8453), and select Continue.
  3. Select Transfer ETH. Select Add Condition, change the condition to Transaction amount, keep is at most and per transaction, and enter 0.1 with the unit set to ETH.
  4. Select Add Action and choose Transfer ETH again. Add a Transaction amount condition: is at most, 1 ETH, per time window, 24 hours.
  5. Select Review, then Save Draft, then Activate on the draft.
In the form you enter the amount the wallet may send, and the saved rule denies anything above it. That is why each condition in the JSON uses gt.
Test it on your Development key: sign a 0.05 ETH transfer, then a 0.2 ETH transfer. The first signs and the second is denied.
The cap counts ETH transfers only. ETH sent along with a contract call is a call_contract request, which this policy does not cover.

Cap USDC per day

Use this when the wallet pays out USDC and other tokens should stay unrestricted. The policy denies a USDC transfer on Base once the day’s total would pass 1,000 USDC. USDC has 6 decimals, so the cap is 1000000000.
The form builds a stricter version of this template. It pins the token contract, so the saved Guardrail also denies transfers of every other ERC-20 token on Base, and its JSON leaves out asset.
  1. On your Development key, open Permissions, select the Guardrails tab, and select Add or New Guardrail.
  2. Enter a Guardrail Policy Name. In Networks, clear Ethereum (1), select Base (8453), and select Continue.
  3. Select Transfer tokens and enter 0x833589fcd6edb6e08f4c7c32d4f71b54bda02913 in Contract Address. Function Name is fixed to transfer.
  4. Select Add Condition, change the condition to Transaction amount, choose per time window with 24 hours, keep is at most, and enter 1000000000 token base units.
  5. Select Review, then Save Draft, then Activate on the draft.
Keep asset when you edit this template. Without it, the rule caps every ERC-20 token at 1000000000 base units a day, each token with its own budget. That is 1,000 USDC, but only a billionth of a token that uses 18 decimals.
Test it on your Development key with a lower cap, such as 1000000 (1 USDC): sign two 0.6 USDC transfers, and the second is denied. Restore the cap before you request a production review.

Cap SOL per day

The same daily cap works on other wallet types. This policy denies a SOL transfer on Solana mainnet once the day’s total would pass 10 SOL, which is 10000000000 lamports.
  1. On your Development key, open Permissions, select the Guardrails tab, and select Add or New Guardrail.
  2. Enter a Guardrail Policy Name. In Networks, expand Solana and select Mainnet. Choosing a Solana network clears the EVM selection. Select Continue.
  3. Select Native transfer. Select Add Condition, change the condition to Transaction amount, choose per time window with 24 hours, keep is at most, and enter 10000000000 lamports.
  4. Select Review, then Save Draft, then Activate on the draft.
The rule checks request.actionFamilies, which lists every kind of action in the transaction, so the cap also counts a SOL transfer bundled with other instructions.
Test it on your Development key with chainId set to solana:devnet and a 1 SOL cap (1000000000): sign two 0.6 SOL transfers, and the second is denied. Restore the mainnet values before you request a production review.

Cap Stellar USDC per day

On Stellar, a token cap names the asset as stellar:<network>:<code>:<issuer>. This policy denies a USDC payment on the Stellar public network once the day’s total would pass 1,000 USDC. Stellar amounts use 7 decimals, so the cap is 10000000000.
The form builds a stricter version of this template. It pins the asset in Token Asset, so the saved Guardrail also denies payments of every other Stellar token. It also writes the network as its passphrase instead of stellar:mainnet.
  1. On your Development key, open Permissions, select the Guardrails tab, and select Add or New Guardrail.
  2. Enter a Guardrail Policy Name. In Networks, expand Stellar, select Public, and select Continue.
  3. Select Token transfer and enter stellar:mainnet:USDC:GA5ZSEJYB37JRC5AVCIA5MOP4RHTM335X2KGX3IHOJAPP5RE34K4KZVN in Token Asset.
  4. Select Add Condition, change the condition to Transaction amount, choose per time window with 24 hours, keep is at most, and enter 10000000000 token base units.
  5. Select Review, then Save Draft, then Activate on the draft.
Test it on your Development key on stellar:testnet: change chainId, and change asset to stellar:testnet:USDC: followed by the testnet issuer. Lower the cap, then sign payments that pass it.

Publish your caps

Once each cap holds on beta, request a production review from your Production key. Para applies the same caps to production, so set the amounts you want in production before you ask.