> 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/concepts/trading-and-rebalancing.md). # Trading and rebalancing Takes monitors the trading account and adjusts positions toward the pool's fixed basket. Rebalancing changes positions, not the pool's configured markets, directions, weights or asset leverage. You do not need to submit a rebalance transaction yourself. ```mermaid flowchart LR A["Deposit, withdrawal or exposure drift"] --> B["Read account and confirm trigger"] B --> C["Recalculate every leg from equity"] C --> D["Reduce positions, then increase"] D --> E["Wait for updated state and re-evaluate"] ``` ## What triggers a rebalance Confirmed deposits and preparation for withdrawals recalculate targets. Between those operations, automation compares observed exposure with the basket's target leverage and notional weights. The default leverage band runs from 0.8 to 1.1 times target. Routine correction triggers strictly below or above that band; emergency correction triggers at or above 1.5 times target. For a 2× target, that means below 1.6×, above 2.2×, and emergency at 3×. Being inside the band does not mean exposure exactly equals target. Weight correction triggers when an asset's observed absolute-notional weight differs from target by more than the smaller of 5 percentage points or 20% of its target weight. A 10% target therefore triggers below 8% or above 12%; a 60% target triggers below 55% or above 65%. Exposure in the wrong direction also triggers correction. Emergency takes priority over ordinary leverage correction, which takes priority over weight correction. These are configurable policies. The [reference settings](/takes-docs/reference/fees-and-limits.md#trading-and-timing) describe defaults, not guaranteed intervention times or leverage limits. ## How trades are sized and sent A trigger leads to a fresh account check and recalculation of every leg using current equity and the [notional-weight formula](/takes-docs/concepts/token-and-basket-model.md#token-and-basket-model). It does not just adjust the asset that crossed a band. For a single-market 2× long pool, 100 USDC of equity targets 200 USDC of exposure. If equity falls to 90 USDC, the new target is 180 USDC. If current exposure is 205 USDC, observed leverage is about 2.28×, above the default upper band, so the worker plans a reduction of about 25 USDC before market-lot rounding and execution costs. Reducing orders go first to release margin, followed by increases. Orders have price limits and use **immediate-or-cancel** execution: available quantity fills now, and the remainder does not stay open. Sizes round down to market lots. An opposite-direction position closes first; a later account read is needed before planning exposure in the correct direction. Ordinary adjustments below 12 USD are skipped. Full position closes are exceptions. During redemption preparation, an existing position can also close when its remaining target is below the trade floor. Small pools may therefore remain off target or temporarily have fewer active legs. The exchange's cross-margin leverage setting is set to that market's maximum; Takes controls strategy leverage through position sizes. An exchange leverage setting is not the pool's target leverage. Derived capital weights are accounting allocations within shared margin, not isolated collateral. ## During buys and sells A confirmed mint credit retargets the whole account using equity that includes the deposit. Mint settlement confirms deposited funds and share issuance; it does not prove all target trades have filled. Before executing a redemption, Takes prepares exposure for the equity left to remaining shares: ``` Remaining target equity = current equity × (supply − redeemed shares) ÷ supply ``` A partial sale usually reduces positions, but an underweight leg can require an increase. A full redemption targets zero. If available withdrawal funds remain insufficient, preparation can close all positions, even for a partial sale. Low leverage can then trigger rebuilding after settlement. Share pricing and payout calculations remain separate from target weights. Redemption preparation temporarily controls the pool's target. Ordinary band correction waits until it ends, and pending capital operations can delay other trading. A sell request does not guarantee immediate closure of your market exposure or fix your USDC proceeds at submission. ## Why actual exposure can differ Orders can partially fill or fail. After an order pass, Takes waits for updated account state before trading again. Later corrections use refreshed exposure; automation does not promise immediate retries until every exact target is reached. A remaining difference inside the bands or below the trade floor can persist. Cooldowns, missing prices, trading permissions, exchange outages and pending capital operations can delay adjustment. Emergency correction can bypass quiet cooldowns, but still waits after orders and cannot bypass active redemption preparation or pending capital operations. Funding, trading fees, builder fees and slippage affect equity and future targets. Frequent rebalancing can add costs. Rebalancing cannot guarantee returns, continuous target exposure or protection from liquidation. Hypothetical strategy charts use simplified hourly replay; they do not reproduce these live execution constraints. --- # 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/concepts/trading-and-rebalancing.md?ask=&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.