> 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/smart-contracts.md). # Smart contracts div.fun's on-chain logic is a small set of contracts, each with one clear job. They are written in Solidity and deployed on HyperEVM. Tokens and their associated contracts are deployed as **minimal-proxy clones** of audited implementations, which keeps each launch cheap while sharing one reviewed codebase. This page describes each contract by role. It does not list addresses — addresses belong on the [resources](/resources/network-and-links.md) page and on the explorer, and tokens are deployed continuously. ### The factory The factory is the entry point. It deploys every token and wires up the contracts that belong to it — the bonding curve, the reward distributor, and, for stock rewards, the converter — in a single launch transaction. It holds the protocol configuration (the routers it uses, the platform's parameters) and stamps each new token with the immutable terms the creator chose: reward asset, dividend share, split, and supply. ### The token Each launched token is a fee-on-transfer ERC-20. Its responsibilities: * behave as a normal ERC-20 for holders; * on each market trade, set aside the configured [dividend share](/core-concepts/dividend-distribution.md); * route that share toward conversion into the [reward asset](/core-concepts/reward-assets.md); * track which balances are [eligible](/core-concepts/reward-eligibility.md) for dividends. The fee logic distinguishes market trades from ordinary transfers and the protocol's own internal movements, so that custody is not taxed — only trading is. ### The bonding curve Before graduation, the curve is the token's market. It prices the token from a formula, accepts HYPE for buys, pays HYPE for sells, and tracks progress toward the [graduation](/core-concepts/graduation.md) target. At graduation it seeds a HyperSwap V2 pool with the HYPE it collected and burns the LP (sends it to a dead address, making it provably non-withdrawable). The pricing math is isolated in its own library so it can be reviewed independently. ### The reward distributor The distributor holds and distributes the reward asset to holders. It accounts for each holder's share by [eligible balance](/core-concepts/reward-eligibility.md) and pushes the reward asset out to wallets. Its distribution function is permissionless — anyone, including the [keeper](/protocol/the-keeper.md), can call it to move dividends along, but no one can use it to take more than holders are owed. A conservative accounting invariant ensures the operator can never reach funds that belong to holders. ### The stock converter For tokens whose reward asset is a [tokenized stock](/stock-dividends/how-stock-dividends-work.md), the converter is the bridge to HyperCore. It moves accumulated value from HyperEVM to HyperCore, places spot buy orders for the stock, brings the bought stock back to HyperEVM, and hands it to the distributor. Because order-book settlement is asynchronous, the converter is a state machine the keeper steps through, with recovery paths so value is never stranded permanently. ### The reward-asset registry An on-chain catalog of known reward assets and their properties — including, for stocks, the metadata needed to trade them on HyperCore, and flags such as whether an asset gates its holders. The registry is a reference the factory and converter consult; the reward asset of a token is still ultimately just a token address fixed at launch. ### How they fit together ``` Factory ─deploys─> Token ─┬─> Bonding curve ─graduates─> HyperSwap pool ├─> Reward distributor ─pushes─> holders └─> Stock converter ─via─> HyperCore ▲ Reward-asset registry (reference) ``` For how these are driven over time, see [the keeper](/protocol/the-keeper.md). For the guarantees they provide, see [security](/protocol/security.md). div.fun's on-chain logic is a small set of contracts, each with one clear job. They are written in Solidity and deployed on HyperEVM. Tokens and their associated contracts are deployed as **minimal-proxy clones** of audited implementations, which keeps each launch cheap while sharing one reviewed codebase. This page describes each contract by role. It does not list addresses — addresses belong on the [resources](/resources/network-and-links.md) page and on the explorer, and tokens are deployed continuously. ### The factory The factory is the entry point. It deploys every token and wires up the contracts that belong to it — the bonding curve, the reward distributor, and, for stock rewards, the converter — in a single launch transaction. It holds the protocol configuration (the routers it uses, the platform's parameters) and stamps each new token with the immutable terms the creator chose: reward asset, dividend share, split, and supply. ### The token Each launched token is a fee-on-transfer ERC-20. Its responsibilities: * behave as a normal ERC-20 for holders; * on each market trade, set aside the configured [dividend share](/core-concepts/dividend-distribution.md); * route that share toward conversion into the [reward asset](/core-concepts/reward-assets.md); * track which balances are [eligible](/core-concepts/reward-eligibility.md) for dividends. The fee logic distinguishes market trades from ordinary transfers and the protocol's own internal movements, so that custody is not taxed — only trading is. ### The bonding curve Before graduation, the curve is the token's market. It prices the token from a formula, accepts HYPE for buys, pays HYPE for sells, and tracks progress toward the [graduation](/core-concepts/graduation.md) target. At graduation it seeds a HyperSwap V2 pool with the HYPE it collected and burns the LP (sends it to a dead address, making it provably non-withdrawable). The pricing math is isolated in its own library so it can be reviewed independently. ### The reward distributor The distributor holds and distributes the reward asset to holders. It accounts for each holder's share by [eligible balance](/core-concepts/reward-eligibility.md) and pushes the reward asset out to wallets. Its distribution function is permissionless — anyone, including the [keeper](/protocol/the-keeper.md), can call it to move dividends along, but no one can use it to take more than holders are owed. A conservative accounting invariant ensures the operator can never reach funds that belong to holders. ### The stock converter For tokens whose reward asset is a [tokenized stock](/stock-dividends/how-stock-dividends-work.md), the converter is the bridge to HyperCore. It moves accumulated value from HyperEVM to HyperCore, places spot buy orders for the stock, brings the bought stock back to HyperEVM, and hands it to the distributor. Because order-book settlement is asynchronous, the converter is a state machine the keeper steps through, with recovery paths so value is never stranded permanently. ### The reward-asset registry An on-chain catalog of known reward assets and their properties — including, for stocks, the metadata needed to trade them on HyperCore, and flags such as whether an asset gates its holders. The registry is a reference the factory and converter consult; the reward asset of a token is still ultimately just a token address fixed at launch. ### How they fit together ``` Factory ─deploys─> Token ─┬─> Bonding curve ─graduates─> HyperSwap pool ├─> Reward distributor ─pushes─> holders └─> Stock converter ─via─> HyperCore ▲ Reward-asset registry (reference) ``` For how these are driven over time, see [the keeper](/protocol/the-keeper.md). For the guarantees they provide, 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/smart-contracts.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.