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

# Dividends

Share-backed pools hold real tokenized shares, so they receive the dividends those shares pay. The issuer (today Dinari, for its dShares) pushes the cash to the holder's address: no claim call, the USDC or USD+ simply arrives at the pool. Two things then have to happen, and they are kept apart:

1. the perp must stay fair across the ex-date, when the spot price drops by the dividend;
2. the cash must be booked somewhere.

The rule is: longs are credited and shorts debited the dividend per token they hold, and everything else is pool NAV. `dividendFeeBps` is deployed at 0, so the platform takes none of it. Dividends are LP yield.

## The ex-date pass-through

The perp's index is spot (`PriceFeed.indexPrice` is the mid, not dividend-adjusted). Without compensation every short would collect the ex-date gap and every long would pay it, a scheduled transfer that traders would farm by piling into shorts the day before. The PositionManager compensates per position instead, the way a stock loan pays a dividend in lieu:

```
applyDividend(perShare)            called by the pool during the sweep
  cumDividendPerToken += perShare
  longDividendAccrued  += longTokens  x perShare      owed by the pool to longs
  shortDividendAccrued += shortTokens x perShare      owed by shorts to the pool
```

Each position snapshots `cumDividendPerToken` when it opens or changes. Its adjustment is `sizeTokens x (index now - snapshot)`, positive for a long and negative for a short. The adjustment is realised into the collateral when the position is closed, reduced or liquidated, and when it is increased (so the snapshot can reset). Until then it is part of `poolExposure`, so the pool's NAV already reflects what it owes longs and is owed by shorts, and it counts toward equity in the liquidation check.

A position opened after the sweep snapshots the new index and is unaffected. A position closed before the sweep never sees it.

The pool can always afford the long credit because `longTokens <= stockBalance`: the long cap is the inventory, so the pool holds the shares the longs are "borrowing" and receives their dividend.

## The sweep

The keeper calls `sweepDividends(perShare)` after the cash has arrived:

```
cash       = USDC and USD+ on the pool above what its accounting knows about
owed       = max(0, longTokens - shortTokens) x perShare       the net cost of the pass-through
retained   = min(owed, cash)
toTreasury = (cash - retained) x dividendFeeBps / 10 000       = 0 at the deployed value
NAV        = the whole cash stays on the pool's books
```

Everything that arrived is added to the pool's `usdcBalance` and `usdPlusBalance` and recorded in `yieldTotals.dividends`. The pass-through liability is created in the same call through `applyDividend`, so the net effect on NAV is `cash - owed`: the dividend on every share the pool holds, minus the dividend on the net shares lent to longs, which those longs receive. If `perShare` is zero or no PositionManager is wired, nothing is retained and the cash is plain NAV.

The sweep is refused while a buy order is in flight at the issuer (`OrdersInFlight`), so a refund on an order can never be read as a dividend. Any USD+ the pool receives is swapped one-for-one for USDC by the settler through `sweepUsdPlus`, which redeems it with the issuer off-chain.

Events: `DividendReceived(cash, perShare)`, `DividendRouted(cash, retained, toTreasury)` and, on the PositionManager, `DividendApplied(pool, perShare)`.

## Who ends up with what

On the ex-date the pool's shares mark down by `perShare` each, so an LP's stock exposure loses exactly what the cash gained. Then:

| holder                                                           | effect                                                                                                                                            |
| ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| a long                                                           | credited `tokens x perShare`, paid out of the collateral at close                                                                                 |
| a short                                                          | debited `tokens x perShare` at close; the debit goes to the pool                                                                                  |
| the pool's LPs, including anyone who staked shares into the pool | the dividend on every share the pool holds, net of the long credit and plus the short debit, as NAV; every LP token is worth more after the sweep |
| the treasury                                                     | nothing (`dividendFeeBps = 0`)                                                                                                                    |

Because the LP token is a share of the whole pool, a user who bought dShares outright and staked them keeps the dividends on the stock the pool holds, pro rata to their share of the pool, on top of the pool's fee and borrow income. See [Pools and NAV](/protocol/pools-and-nav.md#staking-shares).

## The platform's revenue, for contrast

The platform earns the protocol fee, `protocolFeeBps` (10 %) of every taker fee and of every borrow and funding leg, paid to the treasury on each settlement, plus a 10 bps fee on dShare purchases made through the terminal. Neither has anything to do with dividends. `dividendFeeBps` still exists in the pool config as a governance lever: the timelock could route a share of the net dividend to the treasury, but it is set to 0 on every deployment. See [Governance and roles](/protocol/governance-and-roles.md#treasury-and-the-protocol-fee-switch).

## What the keeper needs

`perShare` and the ex-date come from the issuer per stock; the keeper computes `perShare` in the share token's own units (18 decimals for dShares) and calls the sweep once the cash has landed. A worked case is in [Worked examples](/protocol/worked-examples.md#e-a-dividend).


---

# 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.jaawle.xyz/protocol/dividends.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.
