Skip to main content
A co-signer adds a second person to large transfers from a user’s wallet. The user starts the transfer, and someone you choose, such as a guardian or an account manager, approves it before Para signs.

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.

​
Require a co-signer for large transfers

ETH transfers on Base above 0.1 ETH wait for one person with the cosigner role. The Developer Portal forms cannot express approval requirements, so publish the template as JSON.
request-cosigner-approval.json
The user approves this policy on the consent screen like any other Request, and the rule applies only after they do. Then each large transfer opens an approval case, and a co-signer approves or rejects it in Para. The user who starts a transfer cannot approve its case, even if they hold the cosigner role. One rejection from a co-signer ends the case, and a case that is still open after 7 days expires. When the case is completed, call the signing method again with the case ID as resumeApprovalCaseId. Para matches the case even if your app rebuilt the transaction with a new nonce or new gas values, and a completed case covers one signature. While the case is pending, the user can withdraw the transfer with cancelApprovalCase or the useCancelApprovalCase hook, and the case ends as cancelled. The conditional approvals guide for your platform shows how your app follows the case and completes the transfer.
An approval case that has not been used to sign is invalidated when the active policies that apply to its request change, for example when a policy is replaced, activated or turned off. An invalidated case cannot complete, so start a new request to open a new case.

​
Set up co-signers

Approvals come from Para users your backend picks, inside an authorization scope you name.
1

Activate the policy

Para accepts role assignments only for roles that an active policy declares, so publish the template first.
2

Assign the co-signer role

From your backend, give cosigner to each co-signer’s Para user in the authorization scope.
3

Bind the user's wallet

Bind the user’s wallet to the same authorization scope, so its cases go to those co-signers. Give each user their own scope if each has their own co-signer.
Test it on your Development key with two test users: assign cosigner to the second user and bind the first user’s wallet. After the first user approves the consent screen, send 0.5 ETH from their wallet, approve the case as the second user, then sign again with resumeApprovalCaseId and check that the transfer signs.

​
Combine with an allowance

On its own, this policy leaves smaller transfers to the user’s review. To let small transfers sign without a prompt as well, add the allow-small-native-transfers rule from the allowances templates to this policy’s rules. The user then consents once to both rules: If an allow rule and a require_approval rule both match a transfer, the approval wins, whatever order the rules are in.

​
Publish with co-signers

Roles and wallet bindings belong to each environment. After a production review, assign the production co-signers and bind production wallets before your users need large transfers there.