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

# Capacity Protocol

How Model A supplies pooled DUST capacity and Model B sponsors bounded execution.

The Capacity Protocol connects distributed DUST supply with bounded sponsored execution on Midnight.

It is more than a relayer. It combines provider authorization, capacity accounting, application policy, sponsorship execution, receipts and reconciliation.

![Ura Capacity Exchange flow](https://1748825992-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FINAVQvcBCGwClq336pmc%2Fuploads%2Fua4J8lcqjrIk5T8hat66%2Fura-capacity-exchange-flow.png?alt=media)

## Hybrid model

| Layer                   | Purpose                                                                                   | Current boundary                                                                  |
| ----------------------- | ----------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- |
| **Model A — supply**    | Selected NIGHT UTXOs authorize future DUST generation to an external receiver             | NIGHT remains with the holder; generalized wallet onboarding is not yet available |
| **Model B — execution** | An operator validates bounded requests and spends receiver-side DUST to sponsor execution | Bounded Preprod execution and reconciliation are proven                           |

Model A can fill Model B. Model B can also operate initially from Ura's own operator-seeded capacity.

## Custody facts

* NIGHT is not transferred to Ura through the bounded redesignation model.
* Selected NIGHT remains in the provider's wallet.
* Generated DUST at the designated receiver is controlled by the receiver/operator key.
* Non-custodial applies to NIGHT, not to the generated receiver-side DUST.

## Relay Club

Relay Club is the provider-facing participation layer. It explains the authorization, shows the selected capacity relationship and is intended to let providers review the action before signing.

The current blocker is wallet support for a generalized signing flow. Ura does not bypass wallet authorization or replace it with an unsafe workaround.

## Protocol direction

The target is verifiable pool accounting: identifiable requests, operator-signed receipts, on-chain inclusion evidence, receiver observation windows and append-only reconciliation. The protocol does not claim per-coin DUST attribution.


---

# 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 dynamically by asking a question.

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

```
GET https://ura-labs-1.gitbook.io/ura-documentation/capacity-protocol.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.