# System overview

TITHE is implemented as three separate contracts, each with a single responsibility. This separation is deliberate — it keeps each contract small, auditable, and replaceable in isolation (in the design sense, not in production: once deployed, none of them are upgradeable).

## The three contracts

| # | Contract              | Role                                                                                                                                                             | Why it's separate                                                                                                                                                                     |
| - | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1 | **TITHE (ERC-20)**    | The token itself. Vanilla ERC-20 with one minor settlement override.                                                                                             | Must be composable with all DeFi. Lives at a well-known address; integrations expect standard semantics.                                                                              |
| 2 | **CustomHook**        | Uniswap V4 hook attached to the TITHE/ETH pool. Skims the 5% fee on every swap, routes 4% to the distributor and 1% to the treasury, enforces permanent LP lock. | This is where the mechanic actually lives. Has to be a separate contract because V4 hooks are deployed independently and attached to a pool at initialization.                        |
| 3 | **RewardDistributor** | A claimable ETH vault. Receives the 4% on each swap, maintains a reward index, lets holders pull their share at any time.                                        | Separating distribution logic from the hook keeps the hook lightweight and the audit surface narrow. The distributor holds funds; the hook touches no balances except the swap delta. |

## How they connect

```
                    ┌─────────────────────────────┐
                    │   User initiates a swap     │
                    │   on TITHE/ETH (V4 pool)    │
                    └──────────────┬──────────────┘
                                   │
                                   ▼
                    ┌─────────────────────────────┐
                    │       Uniswap V4 Pool       │
                    │   (PoolManager + Hook)      │
                    └──────────────┬──────────────┘
                                   │
                       calls hook callbacks
                                   │
                                   ▼
                    ┌─────────────────────────────┐
                    │         CustomHook          │
                    │  • beforeSwap (buy fee)     │
                    │  • afterSwap  (sell fee)    │
                    │  • LP lock enforcement      │
                    └──────┬───────────────┬──────┘
                           │               │
                       4% ETH          1% ETH
                           │               │
                           ▼               ▼
              ┌────────────────────┐  ┌──────────────────┐
              │ RewardDistributor  │  │ Treasury (3/5    │
              │  • accETHPerToken  │  │  Safe multisig)  │
              │  • claim()         │  └──────────────────┘
              └─────────┬──────────┘
                        │
                  Holders call claim()
                        │
                        ▼
              ┌────────────────────┐
              │   Holder wallet    │
              │   receives ETH     │
              └────────────────────┘
```

## Design principles

**Single responsibility per contract.** The token handles transfers. The hook handles fee collection. The distributor handles accounting and claims. Each can be reasoned about — and audited — independently.

**Immutability by default.** None of the three contracts have admin functions. No `setFee`, no `pause`, no `transferOwnership`, no upgrade path. Every parameter that could change behavior is a constant or set in the constructor.

**Pull-based distribution.** Holders claim their rewards on-demand. The hook never pushes ETH to wallets, never iterates over a holder list, never runs into gas-griefing or DoS vectors that plague push-based reward systems.

**ETH-side fees only.** The hook never touches the token side of the pool. It does not hold TITHE, does not need approval, does not create internal sell pressure on the token. Every fee is denominated in ETH from the moment it is collected.

**Composability preserved.** The TITHE token is a standard ERC-20. It can be deposited into Aave (subject to listing), used as collateral, wrapped, bridged (subject to standard bridge listings), traded on aggregators, held by smart accounts. The reflection mechanic is invisible from the token's perspective.

## What this architecture is similar to

This pattern — token + hook + separate distributor — is now common in V4-native deployments. Reference points:

* **Flaunch:** Each creator coin deploys a vanilla `Memecoin` ERC-20 paired with a dedicated hook. The hook handles fee collection and routing. Distribution is handled by a separate per-creator vault.
* **Founil:** Uses a `CollateralToken` (vanilla ERC-20) paired with a hook and a `DonationRegistry` that handles reward accounting separately. Architecturally near-identical to TITHE's split.
* **Zora creator coins:** V4 hooks attached to creator-specific pools, with revenue routing to separate recipient contracts.

TITHE adapts the same separation-of-concerns pattern to the reflection mechanic specifically.

## What this architecture is *not*

It is not a fork of any existing reflection token. The ERC-20 contract has no transfer override beyond the minor settlement hook required by the distributor's accounting. It does not implement RFI math, does not maintain reflected/total supply balances, does not have an excluded-from-rewards list.

It is not a rebasing token. Balances do not change without a transfer event.

It is not a wrapper or vault token. There is no underlying asset. TITHE is the asset.

It is not upgradeable. No proxy pattern, no `delegatecall` to implementation contracts, no diamond standard. All three contracts are deployed as standard non-upgradeable contracts.


---

# 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/system-overview.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.