> For the complete documentation index, see [llms.txt](https://docs.adcpcapital.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.adcpcapital.com/protocol/peu.md).

# PEU

PEU is ADCP's permanent, protocol-wide residual layer. It is a fixed-supply accounting unit, **not** a customer reward, not a routine partner commission, and not ordinary product participation.

## Fixed supply

Total PEU supply is fixed at genesis at exactly `100.00000000` (8 decimals) and is never inflatable — no governance action, no product configuration, and no code path can mint additional PEU beyond this fixed total.

## Three distinct layers — never conflated

| Layer                     | What it is                                                                                                       | Who may receive it                                                                                        |
| ------------------------- | ---------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
| **Product participation** | Temporary, product-specific economics of a defined product series (e.g. a future Participating Capital position) | Product capital providers, under that product's own terms                                                 |
| **PEU**                   | Permanent, protocol-wide residual participation                                                                  | Founding/strategic claimants; exceptional, long-term ecosystem contribution — never a routine service fee |
| **ADCP corporate equity** | Legal ownership and governance of the company/IP                                                                 | Founders, employees, strategic investors, under ordinary corporate agreements                             |

A strategic partner does not receive PEU merely for a routine introduction, one client, or ordinary origination volume — PEU is reserved for contribution that materially increases the protocol's own long-term value.

## How PEU capacity works (implemented)

* PEU capacity exists in three states at any time: **allocated** (currently issued to a holder), **reserved** (earmarked for a specific future commitment, not yet held by anyone), and **unallocated** (unused capacity with no current beneficiary). All three always sum to the fixed total supply.
* A PEU holder is represented internally as an opaque claimant identity, distinct from any single wallet address — a claimant can survive a wallet being reassigned or revoked, and creating a claimant or assigning it a wallet carries no economic weight or identity-verification implication by itself.
* Reserved capacity carries **no** distribution accrual until it is actually allocated to a holder — neither reserved nor unallocated capacity participates in economics it hasn't been assigned to.
* A newly allocated unit participates only prospectively, from the moment of its own allocation, with no retroactive distribution economics for periods before it existed.

## Activation is a separate governance decision

Before any production-scale residual-distribution economics can occur in any ADCP deployment, a foundational bootstrap allocation must first be authorized by human protocol governance — this is a distinct, explicit decision, never an automatic default of deploying the protocol. See [Deployment Reference](/network/deployment-reference.md) for the current pilot's specific configuration.


---

# 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.adcpcapital.com/protocol/peu.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.