> For the complete documentation index, see [llms.txt](https://docs.bloxchain.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bloxchain.app/guides/contract-calls.md).

# 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.

{% hint style="info" %}
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.
{% endhint %}

## 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](/guides/team-treasury.md).

## 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](/platform-guide/policies/allowlists.md)
* [Actions](/platform-guide/policies/actions.md)
* [Signed files](/platform-guide/operate/signed-files.md)
* [History](/platform-guide/operate/history.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.bloxchain.app/guides/contract-calls.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.