> 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/platform-guide/access.md).

# 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](/guides/organization-governance.md) alongside this page: it maps each role to a job title and covers onboarding, offboarding and the review routine. [Design roles and permissions](/guides/roles-and-permissions.md) 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](/platform-guide/access/signers.md) |
| **Role**           | A named set of permissions, with a maximum number of wallets                                                                                                                   | [Roles](/platform-guide/access/roles.md)     |
| **Protected role** | **Owner**, **Broadcaster**, **Recovery**. Created at deploy, cannot be removed. Their members are changed in [Security](/platform-guide/policies/security.md), 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                   |

<figure><img src="https://2633730519-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0GcVTQuj6X0G3RZ3YY7r%2Fuploads%2Fgit-blob-884409b0113460ba31670673b18f3ac3aca80cfe%2Fpolicy-enforcement.svg?alt=media" alt="Diagram of how a call passes role membership, action permission, gate and allowlist checks before execution"><figcaption><p>Every request passes all four checks in the contract before it can execute.</p></figcaption></figure>

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](/platform-guide/policies.md) → 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](/platform-guide/operate/my-access.md) 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](/protocol-reference/api-reference/runtime-rbac.md) in the Protocol reference.


---

# 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/platform-guide/access.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.