On-chain access

Decide which addresses can act on the account and what each of them may do, with every rule enforced by the contract rather than by the Platform.

Where: Account rail → ON-CHAIN ACCESS: Signers, Roles

If a team shares this account, read Organization governance alongside this page: it maps each role to a job title and covers onboarding, offboarding and the review routine. Design roles and permissions covers how to shape the model before you build it.

Three kinds of thing

Term	What it is	Where you manage it
Signer	An address that holds one or more roles on this account	Signers
Role	A named set of permissions, with a maximum number of wallets	Roles
Protected role	Owner, Broadcaster, Recovery. Created at deploy, cannot be removed. Their members are changed in Security, not on Signers.	Security

Custom roles (for example Operator or Approver) are yours to create and delete. Protected roles exist on every account.

How a permission composes

A signer can perform a step of an action only when the whole chain below holds. Break any link and the chain rejects the call, whatever the Platform shows.

Layer	Question it answers	Set on
Role membership	Does this address hold the role?	Signers
Action permission	May this role perform this step (Request, Approval, Execute) of this action, on this execution path?	Actions → Manage permissions
Gate	Is the role's shared right to request, approve or cancel actually granted on-chain?	Gates
Allowlist	Is the destination (recipient, payee or contract function) allowed?	Allowlists

Every request passes all four checks in the contract before it can execute.

A mental model that works: who (signers) hold which hats (roles); each hat lists which steps of which actions it may take (permissions); the account must have switched that right on for the hat (gates); and the action may only point at approved destinations (allowlists).

Why two layers for one right

Permissions are per action; gates are shared across actions. The permission says "Operator may request NATIVE_TRANSFER". The gate says "Operator's request right is live on this account". Gates are permanent for a role once granted, so the split lets an owner grant fine-grained permissions without re-authorising the role each time, and lets the Platform warn you (Gates gap, Gates mismatch) when the two disagree.

Order of work for a new account

1. Create the custom roles you need on Roles, with a sensible Max wallets.
2. Add addresses on Signers and give each its roles.
3. Assign roles to steps under Policies → Actions → Manage permissions.
4. Grant the resulting gates on Policies → Gates.
5. Add destinations on the Allowlists.
6. Ask a member to open My access and confirm the expected actions appear.

Every change is a batch that the owner signs and that is then submitted on-chain. Nothing takes effect until the batch is executed. The contract side of this model is Runtime RBAC in the Protocol reference.