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

# Architecture

div.fun is built from on-chain contracts on HyperEVM and a small amount of off-chain infrastructure that drives distribution. This page gives the shape of the system; [smart contracts](/protocol/smart-contracts.md) describes each contract's role, and [the keeper](/protocol/the-keeper.md) covers the off-chain part.

### The pieces

```
                         HyperEVM
  ┌──────────────────────────────────────────────────┐
  │  Factory ── deploys ──> Token (fee-on-transfer)   │
  │                          │                         │
  │                          ├─ Bonding curve          │
  │                          ├─ Reward distributor     │
  │                          └─ Stock converter        │
  │                                                     │
  │  Token <── trades ──> HyperSwap V2 pool            │
  └──────────────────────────────────────────────────┘
                          │            ▲
              stock orders │            │ stock back
                          ▼            │
                       HyperCore spot order book

  Keeper (off-chain) ── drives distribution & stock flow
  Indexer (off-chain) ── serves the board, token pages, history
```

### On-chain

* A **factory** deploys every token and its associated contracts as cheap clones, with a fixed configuration.
* Each **token** is a fee-on-transfer ERC-20. Its dividend logic, curve, distributor, and (for stock rewards) converter are wired to it at creation.
* Tokens trade on a **bonding curve** before graduation and on a **HyperSwap V2 pool** after. Liquidity from graduation is burned (LP sent to a dead address, provably non-withdrawable).
* For stock reward assets, a **converter** interfaces with **HyperCore**, Hyperliquid's spot order book, to acquire the stock.

Everything that defines a token — its reward asset, dividend share, split, and supply — is set on-chain at launch and is immutable thereafter.

### Off-chain

Two services support the on-chain contracts without having custody of holders' funds or the power to change token terms:

* **The keeper** drives [distribution](/core-concepts/dividend-distribution.md): it pushes dividends to holders and, for stock rewards, drives the asynchronous HyperCore order flow. It can only do what the contracts permit — call permissionless distribution functions and place the orders the contract design allows.
* **The indexer** reads on-chain events and serves the data behind the [board](/for-traders/the-board.md), token pages, and dividend history. It is read-only: it informs the interface, it does not control anything.

### Trust model in one line

The contracts hold the rules and the funds; the off-chain services only do work the contracts already allow anyone to do. A holder needs to trust the contracts — which are immutable and on-chain — not the operator. See [security](/protocol/security.md).

div.fun is built from on-chain contracts on HyperEVM and a small amount of off-chain infrastructure that drives distribution. This page gives the shape of the system; [smart contracts](/protocol/smart-contracts.md) describes each contract's role, and [the keeper](/protocol/the-keeper.md) covers the off-chain part.

### The pieces

```
                         HyperEVM
  ┌──────────────────────────────────────────────────┐
  │  Factory ── deploys ──> Token (fee-on-transfer)   │
  │                          │                         │
  │                          ├─ Bonding curve          │
  │                          ├─ Reward distributor     │
  │                          └─ Stock converter        │
  │                                                     │
  │  Token <── trades ──> HyperSwap V2 pool            │
  └──────────────────────────────────────────────────┘
                          │            ▲
              stock orders │            │ stock back
                          ▼            │
                       HyperCore spot order book

  Keeper (off-chain) ── drives distribution & stock flow
  Indexer (off-chain) ── serves the board, token pages, history
```

### On-chain

* A **factory** deploys every token and its associated contracts as cheap clones, with a fixed configuration.
* Each **token** is a fee-on-transfer ERC-20. Its dividend logic, curve, distributor, and (for stock rewards) converter are wired to it at creation.
* Tokens trade on a **bonding curve** before graduation and on a **HyperSwap V2 pool** after. Liquidity from graduation is burned (LP sent to a dead address, provably non-withdrawable).
* For stock reward assets, a **converter** interfaces with **HyperCore**, Hyperliquid's spot order book, to acquire the stock.

Everything that defines a token — its reward asset, dividend share, split, and supply — is set on-chain at launch and is immutable thereafter.

### Off-chain

Two services support the on-chain contracts without having custody of holders' funds or the power to change token terms:

* **The keeper** drives [distribution](/core-concepts/dividend-distribution.md): it pushes dividends to holders and, for stock rewards, drives the asynchronous HyperCore order flow. It can only do what the contracts permit — call permissionless distribution functions and place the orders the contract design allows.
* **The indexer** reads on-chain events and serves the data behind the [board](/for-traders/the-board.md), token pages, and dividend history. It is read-only: it informs the interface, it does not control anything.

### Trust model in one line

The contracts hold the rules and the funds; the off-chain services only do work the contracts already allow anyone to do. A holder needs to trust the contracts — which are immutable and on-chain — not the operator. See [security](/protocol/security.md).


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.div.fun/protocol/architecture.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.
