> 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/security.md). # Security This page sets out the protections div.fun's design provides, and — just as importantly — the risks it does not remove. Read both halves. A token that pays real dividends is still a token with market risk. ### What the design protects **Immutable token terms.** A token's reward asset, dividend share, split, and supply are fixed at launch and cannot be changed by anyone, including the creator and the protocol operator. A holder can read these on-chain and rely on them. **Burned liquidity at graduation.** The LP that seeds a token's pool when it [graduates](/core-concepts/graduation.md) is burned — sent to a dead address. It is provably non-withdrawable by anyone, including the team. This removes the classic liquidity rug-pull. **Burn LP for direct-liquidity tokens.** Creators who launched with direct liquidity can burn their LP from the token page at any time. Once burned, the LP is sent to a dead address and is permanently non-withdrawable. Every token page shows a public "Liquidity X% burned" badge so holders can verify the current state on-chain. **No claim, no operator custody of dividends.** Dividends are [pushed](/core-concepts/dividend-distribution.md) by a permissionless distributor whose accounting prevents the operator or [keeper](/protocol/the-keeper.md) from reaching funds owed to holders. The keeper automates public calls; it has no privileged access to holder value. **Shared, reviewed code.** Tokens are minimal-proxy clones of common implementations, so every token runs the same reviewed logic rather than bespoke, unaudited code per launch. Pricing math, fee handling, and distribution accounting are isolated and tested. **Reentrancy and conversion safety.** Distribution and conversion paths are guarded against reentrancy, and internal swaps are structured to avoid the failure modes that break naive fee-on-transfer tokens. ### What the design does not protect **Market risk.** A token's price can fall. Dividends are paid from trading volume, not guaranteed, and a token that stops being traded stops paying. Burned liquidity prevents a liquidity rug; it does not prevent a price decline. **Creator behavior off-chain.** The creator cannot change the token's terms, but they can stop promoting it, sell their own holdings, or simply move on. Judge a token by its on-chain record, not its creator's promises. **Reward-asset risk.** Your dividends are only as sound as the reward asset. A stablecoin can depeg; a tokenized stock carries the risk of its issuer and its market; a thin reward asset distributes poorly. The [reward asset](/core-concepts/reward-assets.md) is a real asset with its own risk. **Permissionless listing.** Anyone can launch a token with any name. A familiar ticker guarantees nothing. Always read the token's [page](/for-traders/the-token-page.md), its reward asset, and its dividend history before buying. **Smart-contract risk.** Audited, reviewed code is not risk-free code. As with any on-chain protocol, residual smart-contract risk exists. ### How to protect yourself 1. **Read the on-chain record.** Dividend history and token terms are the honest data. Use them. 2. **Check the reward asset.** Decide whether you trust and want the asset a token pays in. 3. **Verify what you connect to and what you buy.** Confirm the site and the token address. 4. **Size positions to the risk.** Real dividends do not make a token a safe asset. div.fun's contribution to your safety is structural: immutable terms, burned LP, and dividends the operator cannot touch. The rest is the ordinary discipline of trading on-chain. This page sets out the protections div.fun's design provides, and — just as importantly — the risks it does not remove. Read both halves. A token that pays real dividends is still a token with market risk. ### What the design protects **Immutable token terms.** A token's reward asset, dividend share, split, and supply are fixed at launch and cannot be changed by anyone, including the creator and the protocol operator. A holder can read these on-chain and rely on them. **Burned liquidity at graduation.** The LP that seeds a token's pool when it [graduates](/core-concepts/graduation.md) is burned — sent to a dead address. It is provably non-withdrawable by anyone, including the team. This removes the classic liquidity rug-pull. **Burn LP for direct-liquidity tokens.** Creators who launched with direct liquidity can burn their LP from the token page at any time. Once burned, the LP is sent to a dead address and is permanently non-withdrawable. Every token page shows a public "Liquidity X% burned" badge so holders can verify the current state on-chain. **No claim, no operator custody of dividends.** Dividends are [pushed](/core-concepts/dividend-distribution.md) by a permissionless distributor whose accounting prevents the operator or [keeper](/protocol/the-keeper.md) from reaching funds owed to holders. The keeper automates public calls; it has no privileged access to holder value. **Shared, reviewed code.** Tokens are minimal-proxy clones of common implementations, so every token runs the same reviewed logic rather than bespoke, unaudited code per launch. Pricing math, fee handling, and distribution accounting are isolated and tested. **Reentrancy and conversion safety.** Distribution and conversion paths are guarded against reentrancy, and internal swaps are structured to avoid the failure modes that break naive fee-on-transfer tokens. ### What the design does not protect **Market risk.** A token's price can fall. Dividends are paid from trading volume, not guaranteed, and a token that stops being traded stops paying. Burned liquidity prevents a liquidity rug; it does not prevent a price decline. **Creator behavior off-chain.** The creator cannot change the token's terms, but they can stop promoting it, sell their own holdings, or simply move on. Judge a token by its on-chain record, not its creator's promises. **Reward-asset risk.** Your dividends are only as sound as the reward asset. A stablecoin can depeg; a tokenized stock carries the risk of its issuer and its market; a thin reward asset distributes poorly. The [reward asset](/core-concepts/reward-assets.md) is a real asset with its own risk. **Permissionless listing.** Anyone can launch a token with any name. A familiar ticker guarantees nothing. Always read the token's [page](/for-traders/the-token-page.md), its reward asset, and its dividend history before buying. **Smart-contract risk.** Audited, reviewed code is not risk-free code. As with any on-chain protocol, residual smart-contract risk exists. ### How to protect yourself 1. **Read the on-chain record.** Dividend history and token terms are the honest data. Use them. 2. **Check the reward asset.** Decide whether you trust and want the asset a token pays in. 3. **Verify what you connect to and what you buy.** Confirm the site and the token address. 4. **Size positions to the risk.** Real dividends do not make a token a safe asset. div.fun's contribution to your safety is structural: immutable terms, burned LP, and dividends the operator cannot touch. The rest is the ordinary discipline of trading on-chain. --- # 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/security.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.