> For the complete documentation index, see [llms.txt](https://takes.gitbook.io/takes-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://takes.gitbook.io/takes-docs/reference/status-reference.md).

# Request status

A wallet transaction, a request, and your payout have separate stages.

| What you see                        | Meaning                                                                   |
| ----------------------------------- | ------------------------------------------------------------------------- |
| Confirm in your wallet              | An active wallet prompt needs your approval.                              |
| Wallet request paused               | A previous wallet request has an unknown outcome; another send is paused. |
| Transaction submitted               | A transaction hash exists; chain confirmation is pending.                 |
| Transaction confirmed               | The action reached the chain; updated observations are pending.           |
| Buying / Selling                    | An accepted request is processing; shares or USDC have not arrived yet.   |
| Delivering shares / Delivering USDC | Settlement is complete; automatic delivery is outstanding.                |
| Complete                            | Delivery has finished; your shares or USDC have arrived.                  |

Transaction details contain the hash and explorer link; request details contain request identifiers. Known hashes resume tracking automatically. A receipt timeout is not a failed transaction; use Check status when offered rather than sending another request.

## Request states

Identify a request by its network, token address and `requestId`.

| Contract state | Meaning                                                                             |
| -------------- | ----------------------------------------------------------------------------------- |
| Accepted       | Assets or shares are escrowed; the request can still be cancelled.                  |
| Executing      | The request has started its account or transfer steps; cancellation is unavailable. |
| Settled        | The exact shares or USDC payout is fixed and ready for delivery.                    |
| Delivered      | The whole entitlement has been delivered, including completion of a zero payout.    |
| Cancelled      | An accepted buy was refunded or accepted sell shares were returned.                 |

Each pool allows one capital-changing execution at a time. Several independent requests may be accepted; cancelling one buy affects only that request. Delivery goes to its original controller; an authorized manual claim can select a receiver and delivers the whole payout.

The fresh rollout supports only its configured factories and individual requests. Previous pools and historical batch records are outside this rollout; funds are not automatically migrated.

For API readers, reporting states retain `pending`, `in_flight`, `settled`, `claimed` and `cancelled`. They map respectively to Accepted, Executing, Settled, Delivered and Cancelled. The `active` filter includes pending, in-flight and settled undelivered requests. These reporting names do not imply grouped execution.

## Token activation

A basket is public once published. A pool becomes created after its deployment transaction is confirmed. Setup then appears as activating, live, or needs attention. Unknown means no activation record is available.

Deployment checks funding automatically, opens the required wallet prompts, then tracks activation. The activation card uses **Waiting for activation**, **Activating your pool**, **Open for investment** for live status, and **Activation needs attention**. Live indicates account setup is complete. It does not guarantee current target exposure. See [Review and deploy](/takes-docs/creators/review-and-launch.md#review-and-deploy).

## Token health

**Insolvent** is separate from launch activation. It means the worker recorded six consecutive valid minute observations spanning at least five minutes with matched backing capital strictly below 1 USDC and positive outstanding shares. An unsettled request or unreliable observation resets the streak. A marked vault stays marked after recovery.

Marked vaults are hidden from Explore, Portfolio lists, and Your tokens. Direct token and creator links show Insolvent and the recorded reason. Portfolio totals and charts retain hidden vaults and their losses. History and existing action paths remain available. Hiding does not block investment through direct links or contract calls.

API `health.status` is `unmarked` or `insolvent`. Unmarked is not a solvency guarantee. The API also returns the observation streak, evaluation minute, marking time, reason, exact capital and supply, and threshold. Token and creator API collections retain marked vaults for accounting and direct access.

See [Troubleshooting](/takes-docs/reference/troubleshooting.md#troubleshooting).


---

# 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://takes.gitbook.io/takes-docs/reference/status-reference.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.
