# How requests and approvals work

In Webapp 2.0, most actions that move funds or initiate operations don't take effect the moment you click. They create a **request** that follows the account's governance rules, is authorised on secure hardware, and is then carried out on the blockchain. Understanding this lifecycle makes the rest of these guides easier to follow.

This applies to Operators and Administrators alike, so it's worth reading once before the task guides.

## What counts as a request

Actions that create a request include:

* **Operator actions**: actions like sending funds, staking (stake, unstake, and the network-specific staking operations) and smart contract interactions are requests.
* **Administrator actions**: actions like creating an account, editing an account's rules, creating whitelists and groups are requests.

Read-only actions, such as viewing balances, browsing history, or displaying a receive address, are not requests. (Verifying a receive address still uses your device, but it doesn't create a request.)

## The lifecycle of a request

1. **Created.** A permitted **creator** starts the request from the relevant flow, for example the [send screen](/helpcenter2/for-operators/sending-assets.md).
2. **Checked against the rules.** The request must satisfy the account's [governance rules](/helpcenter2/governance-rules-and-whitelists.md): it has to stay within any **threshold**, send only to **whitelisted** recipients where a whitelist applies, and match an active rule.
3. **Approved.** The request collects the approvals its rules require. Approvals can be organised into one or more **steps**, each needing a set number of approvers drawn from named users or groups, where a group counts as a single approval. Administrator requests (such as account changes) go to the **admin quorum**.
4. **Authorised on a device.** Approvals and the final authorisation happen on a **Physical Security Device (PSD)**, so the details are verified on trusted hardware, not just on screen.
5. **Broadcast.** Once it has every required approval, the transaction is broadcast to the network.
6. **Confirmed.** It then progresses to **confirmed** after the network validates it. The number of validations is shown in the operation's details.

If an approver rejects the request, or it can't complete (for example the fee is too low or funds are missing), it ends in a rejected or failed state instead. Every outcome is recorded.

You can follow all of this in the account's history. See [Operations, history & statuses](/helpcenter2/for-operators/operations-history-and-statuses.md) for what each status means, including each failure reason.

> **Note:** What you see depends on your role. When you view an account's rules, Operators see group names but not individual approver names, while Administrators see the full membership of every rule.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://help.enterprise.ledger.com/helpcenter2/getting-started/how-requests-and-approvals-work.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.