> 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/technical-design/accounting-model.md).

# Accounting model

The protocol keeps trading backing separate from pending deposits, claimable payouts, and fees.

## Minting

For each accepted deposit, at execution:

```
Percentage fee = floor(gross USDC × 10 / 10,000)
Net principal = gross USDC − percentage fee − locked settlement fee
```

Fees lock independently for every submission, including repeated controllers. Gross escrow stays fully cancellation-refundable until execution starts. A CCTP burn includes the exact principal plus an execution reserve; any reserve shortfall comes from operating wallets, never user principal. The hub deposits exactly the principal and records unused reserve as platform surplus. When the fee becomes final, the token sends the percentage fee to its network's fee distributor, which splits it between the creator, the request's frontend and the platform. Historical records preserve their original accounting.

With existing supply:

```
New tokens = floor(credited USDC × existing supply ÷ equity before credit)
```

Here, `floor` rounds down in the contract's smallest units. Equity before credit is the equity read at credit confirmation minus the deposit, not a historical price quote. With existing supply, zero equity before credit prevents settlement.

The first mint starts at one token per credited USDC. Account costs can then reduce its backing.

Tokens are issued to the contract at settlement and delivered automatically to the original controller. A blocked recipient can use authenticated manual claim recovery.

## Redemption

Execution records the request’s redeemed token quantity and total supply. The hub reads current account equity when it executes the withdrawal:

```
Share value = floor(equity × redeemed tokens ÷ recorded supply)
Withdrawal = min(share value, max(equity − Core fee reserve, 0))
```

Equity includes Core spot USDC and the account value on its configured perpetual markets, with negative total equity treated as zero. A zero withdrawal completes without a zero-value CCTP burn or Core withdrawal; redeemed shares still burn at settlement. The [Core fee reserve](/takes-docs/reference/fees-and-limits.md#fees-and-limits) limits the withdrawal; it is not a separate Takes fee.

For positive expected proceeds, the hub requires its available USDC to increase. That increase plus the reserve must cover the expected withdrawal. It returns the full increase, so donations can add to proceeds. For new HyperEVM deployments, holder escrow and accrued fees remain on the token, separate from the trading hub.

Fees are deducted from actual returned USDC. The locked tokens burn at settlement, and net proceeds remain claimable.

Each request pays `floor(actual gross proceeds / 1,000)` as its percentage fee. Its settlement fee is the smaller of its accepted fee and proceeds remaining after the percentage fee. The remainder is that request's entire USDC payout. A zero payout still settles, burns the locked shares and can be marked delivered without a USDC transfer.

## Escrow and units

The token's local USDC must cover accepted mint deposits, settled unclaimed redemptions, and accrued settlement fees, transport surplus and tracked operating reserves. Percentage fees leave the token when they become final. Funds already sent to the trading account are outside those local balances.

USDC uses 6-decimal units at the token interface. Tokens use 18. Arc native seed value uses 18-decimal USDC units.

## Displayed NAV and custody

The recorded values correct for a transfer reaching the account before the request settles:

```
TVL = account equity − credited, unsettled mint USDC
Adjusted supply = token supply − tokens in withdrawn, unsettled redemptions
NAV = TVL ÷ adjusted supply
Custody total = TVL + accepted mint deposits + in-flight USDC
                + claimable redemption USDC + unwithdrawn fees
```

In-flight USDC tracks deposits and withdrawals awaiting settlement. Unwithdrawn fees are settlement fees and percentage fees still in the token; fees forwarded to the fee distributor no longer count. NAV is unavailable when adjusted supply is zero. The NAV formula uses whole-token quantities after decimal conversion.

For example, 100 USDC credited to an account worth 1,100 USDC is excluded until its mint settles. With 500 existing tokens, displayed NAV remains 1,000 ÷ 500 = 2 USDC.

These are recorded display values, not a live payout guarantee. See [NAV and TVL](/takes-docs/concepts/nav-and-tvl.md#nav-and-tvl).

Strategy allocation is separate from share accounting. Notional targets use available equity and `weight / sum(weight / asset leverage)`. A partial redemption scales that equity by the exact remaining-share fraction. Neither the strategy weight model nor its derived capital allocations enter share issuance, redemption fees, or holder payout formulas.


---

# 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/technical-design/accounting-model.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.