> 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/the-keeper.md). # The keeper The keeper is the off-chain service that keeps dividends moving. It is what makes the [push model](/core-concepts/dividend-distribution.md) work: instead of holders claiming, the keeper continuously drives distribution so the reward asset reaches wallets on its own. ### What it does * **Pushes dividends.** It calls the [distributor's](/protocol/smart-contracts.md) permissionless distribution function across active tokens, sending the accumulated reward asset to holders in proportion to their eligible balance. * **Drives stock settlement.** For tokens that pay in a [tokenized stock](/stock-dividends/how-stock-dividends-work.md), it steps the converter through its state machine: bridge value to HyperCore, place the spot order, confirm the fill, bridge the stock back, distribute. * **Recovers stuck value.** If a stock cycle cannot complete — a thin order book, a partial fill — the keeper follows the contract's recovery paths so value is returned and redistributed rather than stranded. ### What it cannot do The keeper has no privileged power over funds or token terms. It can only do what the contracts already allow anyone to do: * It **cannot** change a token's reward asset, dividend share, or split — those are immutable. * It **cannot** take dividends owed to holders. The distributor's accounting prevents the operator from reaching holder funds. * It **cannot** alter eligibility or balances. In other words, the keeper is an automation of public, permissionless calls. Anyone could perform the same distribution calls; the keeper just does them reliably and on schedule so holders do not have to. ### Why distribution is periodic The keeper works through tokens and holders over time rather than acting on every single trade. This is why dividends arrive in **batches** rather than instantaneously. Over any meaningful window, what a holder receives still reflects their share of the eligible supply and the volume the token traded — the batching affects timing, not fairness. ### Reliability Distribution is designed to tolerate the keeper running periodically and to recover from failures. Stock settlement in particular is built as a state machine precisely because order-book actions are asynchronous and can partially complete. The result is that dividends keep flowing without requiring the keeper to be perfect or instantaneous — and without ever requiring a holder to intervene. ### The honest framing The keeper is infrastructure, not authority. It is the reason you never click "claim", and it is constrained by the contracts so that convenience does not come at the cost of trust. See [security](/protocol/security.md) for how that constraint is enforced. The keeper is the off-chain service that keeps dividends moving. It is what makes the [push model](/core-concepts/dividend-distribution.md) work: instead of holders claiming, the keeper continuously drives distribution so the reward asset reaches wallets on its own. ### What it does * **Pushes dividends.** It calls the [distributor's](/protocol/smart-contracts.md) permissionless distribution function across active tokens, sending the accumulated reward asset to holders in proportion to their eligible balance. * **Drives stock settlement.** For tokens that pay in a [tokenized stock](/stock-dividends/how-stock-dividends-work.md), it steps the converter through its state machine: bridge value to HyperCore, place the spot order, confirm the fill, bridge the stock back, distribute. * **Recovers stuck value.** If a stock cycle cannot complete — a thin order book, a partial fill — the keeper follows the contract's recovery paths so value is returned and redistributed rather than stranded. ### What it cannot do The keeper has no privileged power over funds or token terms. It can only do what the contracts already allow anyone to do: * It **cannot** change a token's reward asset, dividend share, or split — those are immutable. * It **cannot** take dividends owed to holders. The distributor's accounting prevents the operator from reaching holder funds. * It **cannot** alter eligibility or balances. In other words, the keeper is an automation of public, permissionless calls. Anyone could perform the same distribution calls; the keeper just does them reliably and on schedule so holders do not have to. ### Why distribution is periodic The keeper works through tokens and holders over time rather than acting on every single trade. This is why dividends arrive in **batches** rather than instantaneously. Over any meaningful window, what a holder receives still reflects their share of the eligible supply and the volume the token traded — the batching affects timing, not fairness. ### Reliability Distribution is designed to tolerate the keeper running periodically and to recover from failures. Stock settlement in particular is built as a state machine precisely because order-book actions are asynchronous and can partially complete. The result is that dividends keep flowing without requiring the keeper to be perfect or instantaneous — and without ever requiring a holder to intervene. ### The honest framing The keeper is infrastructure, not authority. It is the reason you never click "claim", and it is constrained by the contracts so that convenience does not come at the cost of trust. See [security](/protocol/security.md) for how that constraint is enforced. --- # 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/the-keeper.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.