Allowlisted contract calls

Let the smart account call approved external contracts through a governed execution, with a signer who approves and a broadcaster who submits.

Where: Policies → Actions, Allowed contracts, then On-chain access · You need: the address and function list of the contract you want to call, three wallets on Sepolia, test ETH

When to use this

Use a governed execution when the account needs to interact with a contract that is not a plain transfer: a staking contract, a bridge, a registry, or your own application contract. The account performs the call, so the destination sees the smart account as the caller. Every call must still pass through request and approval, and only allowlisted destinations and functions are accepted.

This is not an action you register. The controller surface is installed on every account at deploy under the operation name CONTROLLER_OPERATION, and its entry point is executeWithTimeLock(address,uint256,bytes4,bytes,uint256,bytes32) (selector 0xe85b3c5e). What you configure is who may take each step of it, and which destinations and functions it may point at.

Risk framing

A governed execution is the most powerful thing an account can be permitted to do. The calldata decides what happens at the destination. The allowlist is your main control, and the approver is your second. Keep these rules:

• Allowlist only contracts you have read or that your team has audited. Add the functions you need, not the whole contract.
• Never allowlist a proxy without knowing who can upgrade it.
• Keep the One signature path empty. One person should never be able to compose and execute an arbitrary call alone.
• Start with a small, reversible call on Sepolia.

Who is involved

Duty	Role	Example
Configures policy, fallback approver	Owner	0x3B9d…A41e
Requests calls and approves them	Integration Signer	0xD27a…f9E3
Submits signed approvals, pays gas	Broadcaster	0x5E60…c7D1
Destination contract	for example a staking contract 0xC44a…1E9b	outside Bloxchain

Time: about 60 minutes on Sepolia.

Phase 1: Deploy and check Security

1. Deploy an account from any preset on Discover (it lands as a Vault). Set Owner, at least one Broadcaster address, Recovery and a Time-lock.
2. Inside the account, open Policies → Security and confirm the broadcaster is listed. The signed path in this guide depends on it.

Phase 2: Confirm the controller operation

1. Open Policies → Actions. CONTROLLER_OPERATION is listed already, with executeWithTimeLock(address,uint256,bytes4,bytes,uint256,bytes32) as its entry point. There is nothing to register.
2. The row reads Flow incomplete, because no role may take its steps and no destination is allowed yet. The next phases fix both.

Do not use Add action for this. Add action registers your own functions, for example mint(address,uint256) on a token you govern. The functions of the destination contract are not registered on your account either: you allowlist them on the destination, in Phase 3.

Phase 3: Allowlist the destination and its functions

1. Open Policies → Allowed contracts.
2. Add the destination address and assign only the functions the integration needs (for example stake(uint256) and unstake(uint256)).
3. Sign the batch.

The Destination and Assigned functions columns are the whole destination policy for a governed execution. If a function is not listed here, the call reverts on-chain, whatever the approver signs.

Phase 4: Create the Integration Signer role

1. Open On-chain access → Roles → Create role. Name it Integration Signer, Max wallets 2.
2. Open the role, select Manage role signers, add the integration wallet, and sign.

If you want the requester and approver to be different people, create two roles (Integration Requester and Integration Approver) and split them in the next phase, as in Team treasury.

Phase 5: Manage permissions on the Signed approval path

1. In Policies → Actions, open CONTROLLER_OPERATION and select Manage permissions.
2. On the Signed approval tab: Request → Integration Signer; Approval steps → Integration Signer; Execute → Broadcaster.
3. Optionally, on Delayed release, assign Integration Signer to Request and leave Approval with Owner. This gives the owner a time-locked veto over unusual calls.
4. Leave One signature empty. Review and sign.
5. Open Policies → Gates → Needs attention → Edit, grant the gate for Integration Signer, confirm in Update gates and sign.

Phase 6: Test

1. Fund the account with a small amount of the asset the destination expects (for example some Sepolia ETH or a test token, via Assets → Receive).
2. Connect the Integration Signer wallet and select New request. Choose the card for the contract call, pick the allowlisted destination and function, fill in the parameters, and select Sign request.
3. Open Approvals, open the request, switch to Sign and sign the approval. It moves to the Approved tab.
4. Connect the Broadcaster wallet, open the signed transaction under Approved and select Execute.
5. Verify the effect at the destination (for example the staked balance) and confirm Executed in History.
6. Negative test: try to build a request against a function that is not assigned to the destination. It is not offered, and if you force it through the SDK the call reverts.

Monitoring

• History → group by Operation to see every governed execution in one place. Open a row for the decoded parameters.
• Approvals → the Approved tab shows signed calls the broadcaster has not submitted. Delete anything whose signature deadline has passed.
• Review Allowed contracts whenever the destination contract is upgraded or a new integration is proposed. Remove destinations you no longer use with Remove destinations.

Checklist

• Broadcaster set in Security and funded with test ETH
• CONTROLLER_OPERATION shows ready, not Flow incomplete
• Every destination and every function allowlisted, nothing else
• Integration Signer cannot execute on its own; the broadcaster submits
• One signature path empty
• One successful call and one refused call on Sepolia

Related

• Allowlists
• Actions
• Signed files
• History