Allowlists
Limit where the account's money and calls can go: which addresses may receive native transfers or payments, and which contract functions the account may call.
Where: Policies → ALLOWLISTS: Allowed recipients, Allowed payees, Allowed contracts · You need: owner wallet connected
The three lists
Allowed recipients
Recipients
"Addresses allowed to receive native transfers from this account."
NATIVE_TRANSFER (__bloxchain_native_transfer__())
Allowed payees
Payees
"Addresses allowed as payout destinations for attached payments."
ATTACHED_PAYMENT_RECIPIENT, for actions that carry an attached payment
Allowed contracts
Allowed contracts
"Which destinations can governed operations call — allowlisted targets for Operation Governance." Each destination has Assigned functions.
ERC20_TRANSFER (token contracts), CONTROLLER_OPERATION (governed execution), custom actions
An empty list means nothing is allowed. There is no wildcard. A request to a destination that is not listed is rejected by the contract, and the Platform will not even offer it: the Recipient dropdown in New request only shows allowlisted addresses.
Recipients and payees
Click Add recipient (or Add payee).
Enter the address.
Confirm. The change joins a signed batch.
To remove entries, tick one or more rows and use the bulk action, then sign. It is labelled Remove recipients on the recipients list and Remove payees on the payees list.
What an attached payment is
Allowed payees only makes sense once you know what it guards, and nothing else on the Platform explains it, so here it is.
An attached payment is a payout that rides along with a request. The request carries a recipient, an optional amount of the native coin, and an optional ERC-20 token and amount. When the request executes, the account first does the thing it was for, then settles the payout to that recipient in the same transaction. It is one governed request, not two.
That makes it useful for anything where doing the work and paying for it should be approved together: paying a supplier as part of releasing their goods, settling a fee when a contract call runs, paying out on an action rather than in a separate transfer that someone could forget or approve differently.
Because the payout leaves the account, it is policed like any other movement of value:
The recipient must be on Allowed payees. An empty list allows nothing, so an account that has never configured payees cannot make an attached payment at all.
If the payout is in a token, the token contract must also be on Allowed contracts. Both checks must pass.
The account must actually hold the balance. If it does not, the whole request reverts, including the part that had nothing to do with the payment.
The record moves through a distinct payment status while the payout settles, which is what stops a recipient contract from re-entering the account part-way through.
Allowed contracts
A contract allowlist entry is a pair: a Destination address and the Assigned functions the account may call on it. Listing a token contract with transfer(address,uint256) lets the account send that token; it does not let the account call anything else on the contract.
Click the add control for a destination.
Enter the contract address.
Assign one or more registered functions to it. Only functions that exist as Actions can be assigned.
Confirm and sign.
Remove destinations removes the selected rows. Clear any pending requests that target a destination before you remove it; a pending request whose target has been delisted cannot be cancelled or completed until the target is listed again.
Tokens on this list are also the tokens that appear on the Assets page.
Who can edit
Allowlists are guard configuration on the account contract. Adding or removing entries needs a wallet that may sign guard configuration changes, which is the owner. Edits collect into a batch; you Sign it and a broadcaster Executes it. Until then the list shows the old state and the batch sits in Approvals.
Readiness
The action drawer's Related setup card reports the allowlist for that action: Recipients for native transfers ("Recipient allowlist is configured.") or Targets for contract calls ("Contract target allowlist is configured."). While the list is empty, the action stays Flow incomplete with the alert "Denied by default until permissions and allowlist are configured." and the Open Recipients → shortcut brings you here.
Good practice
Add one recipient, test a small transfer, then add the rest.
Keep the list short. Every address on it is an address a compromised requester could target, subject to the time lock.
Review the list when people or counterparties change; removal is a signed batch, not an emergency stop. The time lock and Cancel in Approvals are your emergency stop.
Related
Last updated
Was this helpful?