> 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/value-flow.md). # Value flow This page traces value through the protocol, from a trade to a holder's wallet, for each kind of reward asset. It complements the creator-facing [economics](/for-creators/economics-and-fees.md) page with the protocol-level view. ### A trade When a div.fun token is traded — on its bonding curve or on its HyperSwap pool: 1. The token sets aside its **dividend share** of the trade. 2. The share is **converted** into the reward asset. 3. The reward asset is **split** between holders and the creator, per the creator-chosen split. 4. The holders' portion is **distributed** to wallets in proportion to [eligible balance](/core-concepts/reward-eligibility.md). The difference between reward assets is entirely in step 2 — conversion. ### Conversion: HYPE The dividend share is realized as HYPE-denominated value directly. Holders receive wrapped HYPE. This is the most direct path and the most liquid. ``` trade ─> share ─> (already HYPE value) ─> split ─> holders / creator ``` ### Conversion: stablecoin The dividend share is swapped on HyperSwap into the chosen stablecoin, then split and distributed. Deep stablecoin liquidity on HyperEVM makes this clean and predictable. ``` trade ─> share ─> swap on HyperSwap ─> stablecoin ─> split ─> holders / creator ``` ### Conversion: tokenized stock The dividend share is first realized as a stablecoin, then routed through HyperCore to buy the stock, which is bridged back and distributed. This is asynchronous and [keeper](/protocol/the-keeper.md)-driven. ``` trade ─> share ─> stablecoin ─> bridge to HyperCore ─> spot buy order ─> fill ─> bridge stock back to HyperEVM ─> split ─> holders / creator ``` See [How stock dividends work](/stock-dividends/how-stock-dividends-work.md) for the full state machine. ### The launch and curve flows ``` Launch ─> launch fee (HYPE) ─> platform └> direct-liquidity seed ─> token's HyperSwap pool Curve trade ─> protocol fee ─> platform ├> dividend share ─> split ─> holders / creator └> HYPE collected ─> reserved to seed the pool at graduation (LP burned at graduation) ``` ### Who can touch what * **Holders' dividends** are accounted on-chain by eligible balance and can only flow to holders. The operator and keeper cannot divert them. * **The creator's share** flows to the creator, set by the immutable creator-chosen split. * **Burned liquidity** from graduation is permanently destroyed and cannot be recovered by anyone. The structural point: every path that touches holder value is fixed at launch and enforced on-chain. The flexible parts of the system — the keeper, the indexer, the interface — sit outside the value paths that matter. See [security](/protocol/security.md). This page traces value through the protocol, from a trade to a holder's wallet, for each kind of reward asset. It complements the creator-facing [economics](/for-creators/economics-and-fees.md) page with the protocol-level view. ### A trade When a div.fun token is traded — on its bonding curve or on its HyperSwap pool: 1. The token sets aside its **dividend share** of the trade. 2. The share is **converted** into the reward asset. 3. The reward asset is **split** between holders and the creator, per the creator-chosen split. 4. The holders' portion is **distributed** to wallets in proportion to [eligible balance](/core-concepts/reward-eligibility.md). The difference between reward assets is entirely in step 2 — conversion. ### Conversion: HYPE The dividend share is realized as HYPE-denominated value directly. Holders receive wrapped HYPE. This is the most direct path and the most liquid. ``` trade ─> share ─> (already HYPE value) ─> split ─> holders / creator ``` ### Conversion: stablecoin The dividend share is swapped on HyperSwap into the chosen stablecoin, then split and distributed. Deep stablecoin liquidity on HyperEVM makes this clean and predictable. ``` trade ─> share ─> swap on HyperSwap ─> stablecoin ─> split ─> holders / creator ``` ### Conversion: tokenized stock The dividend share is first realized as a stablecoin, then routed through HyperCore to buy the stock, which is bridged back and distributed. This is asynchronous and [keeper](/protocol/the-keeper.md)-driven. ``` trade ─> share ─> stablecoin ─> bridge to HyperCore ─> spot buy order ─> fill ─> bridge stock back to HyperEVM ─> split ─> holders / creator ``` See [How stock dividends work](/stock-dividends/how-stock-dividends-work.md) for the full state machine. ### The launch and curve flows ``` Launch ─> launch fee (HYPE) ─> platform └> direct-liquidity seed ─> token's HyperSwap pool Curve trade ─> protocol fee ─> platform ├> dividend share ─> split ─> holders / creator └> HYPE collected ─> reserved to seed the pool at graduation (LP burned at graduation) ``` ### Who can touch what * **Holders' dividends** are accounted on-chain by eligible balance and can only flow to holders. The operator and keeper cannot divert them. * **The creator's share** flows to the creator, set by the immutable creator-chosen split. * **Burned liquidity** from graduation is permanently destroyed and cannot be recovered by anyone. The structural point: every path that touches holder value is fixed at launch and enforced on-chain. The flexible parts of the system — the keeper, the indexer, the interface — sit outside the value paths that matter. 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/value-flow.md?ask=&goal= ``` `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.