# Fee structure

## Summary

| Fee         | %      | Destination                                    |
| ----------- | ------ | ---------------------------------------------- |
| The Tithe   | 4%     | Distributed to public holders pro-rata, in ETH |
| The Sanctum | 1%     | Treasury 3/5 Safe multisig                     |
| **Total**   | **5%** | Applied on every swap, both directions         |

## How it's applied

The 5% is taken from the **ETH side of every swap** through the CustomHook. See [The Tithe](file:///3539486/mechanic/the-tithe.md) for the mechanic and [Swap Lifecycle](file:///3539486/architecture/swap-lifecycle.md) for the per-transaction trace.

Both directions pay 5%. There is no asymmetric tax (no "5% buy / 8% sell" structure as some prior reflection tokens had). The fee is symmetric, predictable, and applies uniformly to anyone trading the pool.

## Treasury management

The 1% treasury share flows to a 3-of-5 Gnosis Safe multisig. Signers are disclosed at launch on the [Contract Addresses](file:///3539486/reference/addresses.md) page.

Treasury funds are used for:

* **Audit retainers** for the initial audit and any follow-up scope changes
* **Bug bounty payouts** (Immunefi or Cantina-hosted)
* **Infrastructure costs** (Sanctum portal hosting, subgraph indexing, RPC providers)
* **Legal and operational overhead**
* **Ceremony and community operations**

The multisig is a standard Safe deployment. Spending requires 3 of 5 signers. All transactions are visible on-chain.

## What the treasury *cannot* do

The treasury is a multisig wallet, not a privileged actor in the protocol. Specifically, the treasury cannot:

* Change the fee rate (the hook is immutable)
* Change the fee split (constants in the hook)
* Pause swaps (no pause function exists)
* Mint TITHE (no mint function exists)
* Drain the RewardDistributor (no privileged caller; the distributor only sends to claimants)
* Modify the LP (the hook blocks all `removeLiquidity` calls on the initial position)
* Upgrade any contract (no proxy pattern in use)

The treasury can only spend the ETH that flows to it from the 1% allocation. Everything else is structurally outside its reach.

## Fee economics at different volume levels

At illustrative daily volumes, the 4% holder allocation produces:

| Daily Volume | Daily Holder Yield (4%) | Annualized |
| ------------ | ----------------------- | ---------- |
| $100K        | $4,000                  | $1.46M     |
| $500K        | $20,000                 | $7.3M      |
| $1M          | $40,000                 | $14.6M     |
| $5M          | $200,000                | $73M       |

Per-holder yield depends on (a) eligible supply and (b) the holder's share of it. For a holder with 1% of eligible supply at a $1M daily volume:

```
Daily Blessing = $40,000 × 1% = $400/day
Annualized   = ~$146,000/year per 1% position
```

These are mechanical projections, not promises. Actual volume depends on market conditions and is outside protocol control.

## Why 5% total, 4:1 split

The 5% rate was chosen as the median of comparable V4 reflection/revenue-share deployments. Rates lower than 3% generate insufficient holder yield to differentiate the project from vanilla tokens; rates higher than 10% create enough friction that volume migrates to alternate venues, harming holders.

The 4:1 holder/treasury split prioritizes holder yield while leaving sufficient runway for the treasury to sustain operations. At meaningful volume, 1% to treasury is more than enough to fund audits, bounties, and operations indefinitely. At low volume, the treasury simply scales down with the project.

Neither value can be changed post-deployment. They are constants in the hook contract bytecode.


---

# Agent Instructions: 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:

```
GET https://tithe-coin.gitbook.io/tithe-coin/fee-structure.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.