Policies

Configure what the account may do and under which rules: protected roles and time lock, registered actions and their permissions, gates and allowlists.

Where: Account rail → Policies ›

The Policies nest

Policies › on the account rail opens a second rail. ← Account at the top takes you back.

Group	Item	What it controls	Page
POLICIES	Security	Owner, Recovery, time lock, Broadcasters	Security
POLICIES	Actions	Which functions the account can perform, listed by operation name with the signature underneath, and who may perform each step	Actions, Manage permissions
POLICIES	Gates	Whether each role's request, approve and cancel rights are switched on	Gates
ALLOWLISTS	Allowed recipients	Addresses native transfers may go to	Allowlists
ALLOWLISTS	Allowed payees	Addresses attached payments may go to	Allowlists
ALLOWLISTS	Allowed contracts	Contract destinations and the functions the account may call on them	Allowlists

Everything here is stored in the account contract. The Platform reads it, shows gaps, and helps you build the change; the chain enforces it.

Setup gap badges

The rail and the Overview page count what is still incomplete:

• Actions badge: actions that are Flow incomplete or have a Gates mismatch.
• Gates badge: roles that need a gate.
• Roles badge (on the main rail): roles with no signers or no actions.
• Overview: "N actions need registration", "N role items incomplete", "N setup items need attention" → Fix in Administration.
• Actions drawer: Related setup shows Gates and Recipients or Targets as Ready or not.

A fresh account with none of this configured is a Vault: it can hold funds and be recovered, but no transfer can even be requested. See what a new account already has. The badges disappear as you complete the steps below.

The order to configure a new account

1. Security. Confirm Owner, Recovery, time lock and Broadcasters are what you want. Fix Recovery not set first.
2. Roles and Signers (main rail). Create custom roles and add the addresses that will hold them. See On-chain access.
3. Actions. NATIVE_TRANSFER and ERC20_TRANSFER are registered at deploy, so check the list rather than adding them. Use Add action only for functions of your own, such as mint(address,uint256).
4. Manage permissions. For each action, assign roles to Request, Approval and Execute on the paths you want to enable.
5. Gates. Grant the gates the previous step created a need for.
6. Allowlists. Add recipients, payees and contract destinations.
7. Test with a member. Have a non-owner open My access and raise a small request.

Each step is a batch that the owner signs and that a broadcaster submits. Ownership transfer is the exception: it is time-locked.

For a worked example of these seven steps on a shared account, follow the Team treasury guide.