Skip to main content
These templates ask the user for standing access to addresses your app already knows: the recipients it pays and the contract it calls. Anything outside the list still goes to the user for review. Replace the placeholder addresses with your own before you publish.

​
Send ETH to known recipients

Use this when your app pays a fixed set of addresses, such as your own payout or escrow wallets. ETH transfers on Base to a listed address sign without a prompt once the user approves.
  1. On your Development key, open Permissions, select the Requests tab, and select Add or New Request.
  2. In User consent request language, enter Send ETH on Base to approved recipients. In Networks, clear Ethereum (1), select Base (8453), and select Continue.
  3. Select Transfer ETH, then Add Condition. Keep Recipient address, choose is one of, and enter the addresses separated by commas.
  4. Select Review, then Save Draft, then Activate on the draft.
The rule sets no amount limit, so the user grants access to any amount sent to these addresses. To cap it, add a Transaction amount condition to the same action. A Request action holds up to 8 conditions, and a transfer must meet all of them.
Test it on your Development key: after the test user approves the consent screen, send ETH to a listed address and it signs without a prompt. A transfer to an unlisted address opens a review.

​
Call your app’s contract

Use this when your app calls one function on its own contract for the user, such as minting an item. Calls to mint on the listed contract on Base sign without a prompt once the user approves.
  1. On your Development key, open Permissions, select the Requests tab, and select Add or New Request.
  2. In User consent request language, enter Mint items from our contract on Base. In Networks, clear Ethereum (1), select Base (8453), and select Continue.
  3. Select Call a contract. Enter the contract in Contract Address and mint in Function Name.
  4. Select Review. The Review step warns that no conditions are set, but the contract and function still limit the rule, as the Normalized policy JSON shows. Select Save Draft, then Activate on the draft.
Para reads the function only from calls it can decode. The rule’s request.classification check means a call Para cannot decode never matches, so it goes to the user for review instead of signing.
Test it on your Development key: after the test user approves, call mint and it signs without a prompt. A call to another function opens a review.
Each Request policy has its own consent screen, and the user sees one at a time. To ask once for both templates, put them in one policy: in the Developer Portal, select Add Action to add the second action, or combine both rules in one JSON policy.

​
Publish your lists

Test recipients and contracts are often not the ones you use in production. Para applies the policies active on your Development key to production after a production review, so update the lists to your production addresses before you request it.