> For the complete documentation index, see [llms.txt](https://takes.gitbook.io/takes-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://takes.gitbook.io/takes-docs/technical-design/strategy-estimates-and-rebalances.md).

# Strategy estimates and rebalances

Deployment configuration and pool detail offer hypothetical 24h, 7d and 30d strategy returns using hourly prices, the selected notional weights, directions and effective asset leverages. Replay applies standard shared leverage/weight bands at hourly boundaries and fills adjustments at those prices. Historical funding changes equity before depletion and rebalance checks: `cash change = -signed position size × boundary price × hourly funding rate`. Positive rates charge longs and credit shorts; negative rates reverse this. The opening boundary incurs no previous-hour payment. Paid and received funding are percentages of starting capital.

These are estimates, separate from actual NAV. Hourly boundary prices approximate exchange oracle prices. Fees, slippage, order constraints, live cooldowns, deployment-specific band overrides and intrahour liquidation are excluded. Observed equity depletion stops the replay at a 100% loss. Missing prices or settlements make the affected period unavailable, never zero-filled.

`GET /instruments/:id/price-history` returns hourly `points` with exact price strings and source (`worker` or `exchange`), plus exact signed `fundingRates` at nominal UTC hours. Stored observations are preferred; missing boundaries use validated exchange closes and realized historical funding. Worker prices collected in the first minute can replace exchange backfill; midhour restarts do not invent observations. Prices and funding are retained without automatic pruning. Dependency failures preserve stored partial history; no stored prices during an outage returns 503. Unknown instruments return 404. Requests are coalesced and cached for one minute with hourly rollover invalidation.

`GET /tokens/:address/value-history` includes paginated `rebalances` alongside NAV points. An event requires a positive-size recorded fill matched by hub and order ID; rejected, unfilled and under-minimum attempts are excluded. A partial fill qualifies without proving target completion. Events use first/last fill timestamps and triggers `mint`, `redemption`, `leverage`, `weight` or `emergency`. Grouping happens before first-fill filtering into the chart’s `[from,to)` window. Items sort oldest first by first fill and rebalance ID. `rebalanceLimit` accepts 1–200 (default 200); `rebalanceCursor` binds pagination to the resolved chart window. `total` counts qualifying executions across that window. Synchronization can add recent events later. This metadata does not imply plotted chart markers or hypothetical replay events.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://takes.gitbook.io/takes-docs/technical-design/strategy-estimates-and-rebalances.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.