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

# Fee accounting and claims

USDC-side LP fees move through a traceable pipeline. The exact destinations depend on which permanent and temporary allocations are eligible when fees are collected.

```
Canonical LP fees ──→ Fee distribution
                            │
        ┌───────────────────┼───────────────┬───────────────┬──────────────────┐
        ▼                   ▼               ▼               ▼                  ▼
     Creator            Protocol        Referral      Launch Partner      Community epoch
                                                           pool                 │
                                                                                ▼
                                                                       Staking / InfoFi
                                                                                │
                                                                                ▼
                                                                      Published allocation
                                                                                │
                                                                                ▼
                                                                          Wallet claim
```

Collection is separate from accrual, and accrual is separate from claiming. A balance can be earned before the recipient submits a claim.

Referral and Genesis Launch Partner accounting are independent temporary overlays. A collection can credit both when both are eligible. If either overlay is absent or expired, its unused allocation returns to protocol rather than being redistributed to another optional recipient.

## Epoch accounting

For a Community-enabled market, the launch-selected genesis policy supplies the starting Community share and Staking/InfoFi split from epoch 1. A later successful governance policy can replace those values only for its eligible future epoch onward.

Community fees are credited to the current token epoch. When an epoch is initialized, its applicable Staking/InfoFi split is fixed from the policy effective for that epoch. After the epoch and attribution window, Souless publishes the pool totals and claim record. Each feature either distributes its complete available amount or carries that complete amount into the same feature's next fee-bearing finalized epoch. Open fee-bearing epochs finalize in on-chain insertion order.

A claim leaf binds chain ID, distributor address, token, epoch, wallet, and amount. The contract rejects a second claim and prevents total claims from exceeding the epoch pool.

Integer division may leave rounding dust. Published totals must show it; it must never be silently reassigned. Finalized results are historical records. Delayed finalization delays claims but does not change the already credited pool.

Historical allocation can be reconstructed from the launch's genesis policy, later governance policy when applicable, fee collection, campaign/referral eligibility, epoch finalization, and claim events.


---

# 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.souless.fun/economics/accounting.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.
