> For the complete documentation index, see [llms.txt](https://docs.shuffle.family/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.shuffle.family/how-the-basket-works-technical-section/rebalancing.md). # Rebalancing and accounting ## The daily rhythm 1. **12:00 UTC — daily rebalance.** The operator values the current holdings, fetches fresh CoinGecko rankings, vets candidates and compares actual allocations with targets. The first transaction can combine sales and purchases using available WETH. 2. **Hourly at :00 — unfinished work continues.** Runs wait when new-token checks require it. Otherwise, the operator freshly assesses holdings, rankings and eligibility, then combines capped trims and eligible purchases in the same transaction. Purchases use available WETH and conservative sale proceeds. 3. **After completion — wait for the next 12:00 UTC.** No separate allocation hour is required after finishing trims. If caps, deferred trades or new-entry checks leave work unfinished, later checks continue the cycle. Once complete, no automated portfolio trading happens until the next daily review, including investing new fee receipts. Deposits and withdrawals are unaffected. A few details: * At most **one portfolio transaction confirms per UTC hour**. Retries and recovered transactions do not create an extra allowance. * The wait runs until the next noon UTC, not 24 hours after completion. A rebalance finished at 17:20 UTC waits until 12:00 UTC the next day. * A run that finds nothing worth adjusting also counts as complete. A failed or partial run does not. * At each 12:00 UTC boundary, unfinished plans expire and a fresh assessment is required. Already signed transactions must still be reconciled before another submission. See [current configured settings](/how-the-basket-works-technical-section/current-settings.md) for the full schedule and limits. ## How drift is measured The basket's value $$V$$ is the sum of each holding's quantity $$q\_i$$ times its price $$p\_i$$. A coin's actual allocation $$a\_i$$ is its share of that total: $$ V = \sum\_i q\_i p\_i, \qquad a\_i = \frac{q\_i p\_i}{V} $$ **Example:** $1,200 of a coin in a $10,000 basket is a 12% allocation. If its target is 9.11%, it is overweight and can be trimmed, possibly over several hours. Underweight coins can be topped up; fresh assessments update targets when ranks change. ## Limits on sales Automated rebalancing sells at most **0.05% of each token's total supply per UTC hour**, including SHUFFLE. This is a ceiling, not a target: the operator sells only what the adjustment needs. It is measured against the token's total supply, not the index's holding or market liquidity, and it does not guarantee a particular price impact. The cap is checked against fresh on-chain supply before each transaction is signed. It is an operator rule, not a contract restriction; it never limits user withdrawals. Other limits: * Adjustments below **$1** are usually skipped. A final exit can clear a smaller leftover balance. * Estimated gas must stay within **1% of planned turnover**: conservative WETH sale proceeds plus WETH purchase inputs, counting each leg once and excluding internal routing hops. This is not a cap on slippage or trading losses. * A missing route or failed simulation can defer an adjustment. Unspent funds stay as WETH. So a scheduled run can end with no trades. ## Replacing a token The contract requires a complete basket and cannot hold an extra token temporarily. A token leaving the index therefore keeps its slot while its capped sales continue. Its final sale and the replacement purchase settle together in one transaction, after fresh eligibility checks. If a slot is empty after a delisting, it can be filled in the same transaction as other trades. Each transaction is atomic: if any part fails, the whole batch reverts. A token sold in a batch is not bought back in that same batch, though a later round can select it again. After SHUFFLE activation the basket tracks 21 entries: 19 memes, SHUFFLE and WETH. Before activation, WETH holds the 5% slot instead, giving 20. ## Fee receipts At **:40 each hour UTC**, a separate job claims SHUFFLE trading-fee revenue and adds it to the index as WETH. It does not buy anything itself; the rebalance loop decides when that WETH is invested. Fee receipts create no new XSHUFFLE, so they add backing to existing shares. ## Share price and management fee The estimated value of one XSHUFFLE is the basket's value divided by effective share supply, including management-fee shares accrued but not yet minted: $$ P\_{\mathrm{XSHUFFLE}} = \frac{V}{N\_{\mathrm{effective}}} $$ **Example:** a basket worth $10,000 with 100,000 effective shares gives $0.10 per share. The **3% annual management fee** creates new XSHUFFLE for the admin operator. At each checkpoint, the newly minted shares are: $$ \Delta N = \left\lfloor\frac{N \times 300 \times \Delta t}{10{,}000 \times 365\text{ days}}\right\rfloor $$ Here, $$N$$ is minted supply before the checkpoint, 300 is the rate in basis points, and $$\Delta t$$ is elapsed time in the same units as the denominator. Each checkpoint rounds down to whole share wei and discards the fractional remainder. Accrual is linear between checkpoints and compounds as minted shares enter supply. **Example:** with a single checkpoint after one year and no other supply changes, 100,000 shares become 103,000. An unchanged holding then represents 100,000 ÷ 103,000 ≈ 97.09% of its previous share of the basket. More frequent checkpoints slightly increase the annual dilution through compounding. **Annual dilution from the management fee remains below 3%, even with very frequent checkpoints.** With no other supply changes and ignoring integer rounding, one yearly checkpoint reduces an existing holder's ownership fraction by about **2.91262%**. As checkpoints become more frequent, that reduction approaches **2.95545%**, still below 3%. Share supply grows by up to approximately 3.04545% in this limit; supply growth and holder dilution are different percentages. Deposited capital is not counted as investment profit: deposits add backing and issue shares against it. Trading costs, fee receipts and management dilution can still change value per share. Market-data valuations can differ from the amount actually obtainable by selling. ## Trade execution Deposits settle in ETH. The contracts use WETH internally and return ETH for cash redemptions. Swaps can route through up to three hops; intermediate tokens never become basket holdings. Pools are checked against canonical deployments. V4 swaps use the same hook data for quoting and execution. Full transaction simulation and on-chain custody checks enforce execution bounds. --- # 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://docs.shuffle.family/how-the-basket-works-technical-section/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.