> 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/operate.md).

# Operate an account

Use the account rail to fund an account, raise requests, approve them and read the record of what settled.

**Where:** Accounts → open an account · **You need:** wallet connected to the account's network (Sepolia during alpha)

<figure><img src="https://2633730519-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0GcVTQuj6X0G3RZ3YY7r%2Fuploads%2Fgit-blob-292058489c6b7e33bd162214056452787384d000%2F20-overview.png?alt=media" alt="Account Overview showing balance, contract security, holdings and open requests" width="1000"><figcaption><p>Overview of a smart account. The rail on the left is the same on every page inside an account, and Needs attention (1) is where unfinished setup surfaces.</p></figcaption></figure>

## The rail

| Rail item         | What it is for                                                                  | Page                                                  |
| ----------------- | ------------------------------------------------------------------------------- | ----------------------------------------------------- |
| **Overview**      | Balance, security status, top holdings and open requests at a glance            | [Overview](/platform-guide/operate/overview.md)       |
| **Assets**        | Native and allowlisted token balances, **Receive** and **Send**                 | [Assets](/platform-guide/operate/assets.md)           |
| **Approvals**     | Open requests and stored signed transactions waiting for a decision or a submit | [Approvals](/platform-guide/operate/approvals.md)     |
| **History**       | Settled operations: executed, cancelled or failed                               | [History](/platform-guide/operate/history.md)         |
| **+ New request** | Start a transfer, mint, burn or custom action                                   | [New request](/platform-guide/operate/new-request.md) |
| **My access**     | The roles your connected wallet holds and what it can do                        | [My access](/platform-guide/operate/my-access.md)     |

Below the rail, the **ON-CHAIN ACCESS** section (**Signers**, **Roles**) and **Policies ›** belong to administrators. They are covered in [On-chain access](/platform-guide/access.md) and [Policies](/platform-guide/policies.md).

Anyone with the account link can [open it](/platform-guide/accounts/open-and-share.md) and read every page without signing in. Acting on the account needs a [connected wallet](/platform-guide/connect-wallet.md) that holds a role. The status footer tells you where you stand: "Connect a wallet to sign. Reads still work." or "Switch to Sepolia".

## Who does what

A governed account separates three jobs. One wallet can hold more than one of them, but a well-run account keeps them apart. The [Glossary](/resources/glossary.md) defines the terms these pages use for each step.

| Job         | What they do in the Platform                                                                                                         | Typical role                                                          |
| ----------- | ------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------- |
| Requester   | Opens **New request**, fills the form, chooses **Wallet** or **Sign**                                                                | A custom role such as Operator                                        |
| Approver    | Opens the request in **Approvals**, reviews the decoded parameters, chooses **Approve** or **Cancel**                                | Owner, or a custom approver role                                      |
| Broadcaster | Submits [signed transactions](/platform-guide/operate/signed-files.md) on-chain and pays gas; executes items on the **Approved** tab | **Broadcaster** protected role, or the optional Bloxchain broadcaster |

The rules that decide which wallet may do which step are set by the account admin in Policies. If a button is greyed out, [My access](/platform-guide/operate/my-access.md) shows why and [Help](/platform-guide/help.md) lists what the account still needs.

## A suggested daily flow

1. Open **Overview**. Check the **Needs attention** card for open requests and any setup gap messages.
2. Open **Approvals**. Work the **Pending** tab first (items whose time lock has run show **Ready**), then the **Approved** tab for signed transactions that still need an **Execute**.
3. Raise anything new with **+ New request**.
4. Confirm the outcome in **History** at the end of the day. Every row links to the transaction hash.

When the approver and the broadcaster are not at the same machine, follow [Approve from another device](/guides/cross-device-approval.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/platform-guide/operate.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.
