Managed baskets and permissions
The separate official-basket design, its fixed roles, and the bounds on keeper rebalancing.
Community baskets use fixed vaults with no portfolio-trading authority. The source also includes a separate official managed-basket design that permits a designated keeper to rebalance within an immutable policy.
The managed implementation requires a qualified external price source and venue. The repository does not supply a production price source or establish production readiness for official management. The existence of these contracts is not confirmation that an official managed basket is available in a particular deployment.
Separate contracts and roles
| Role or component | Authority |
|---|---|
| Community creator | Launch a basket with their own funds; no later backing-management authority |
| Managed-factory project address | Create and seed baskets in the separate managed registry |
| Managed keeper | Submit trades among the existing constituents, subject to the fixed policy |
| Managed guardian | Pause or resume rebalancing only |
| Share holder | Transfer shares, mint with required backing, or request redemption of their own shares |
The managed project role grants no authority over community vaults. Managed baskets have a separate registry; community routing does not automatically support them. The native basket router is designed for the configured community registries.
Keeper, guardian, venue, price source, targets, and execution budgets are fixed at deployment. There are no role-rotation, target-change, upgrade, or emergency-sweep entry points.
What a rebalance must satisfy
The keeper can trade between existing constituents through the configured V2-compatible venue, using a direct route or an allowed two-hop route. It cannot add or remove constituents, sell the entire active reserve of a constituent, or spend pending withdrawal claims.
Each batch must pass the following checks:
- The caller is the keeper, rebalancing is unpaused, and the expected policy hash matches.
- The deadline and cooldown are satisfied, and all constituents cover their liabilities.
- Every reference price is qualified, positive, and no older than the configured maximum age.
- The basket’s starting drift meets the configured threshold, and the batch reduces that drift.
- Turnover and reference-value loss stay within the per-batch and cumulative window budgets, plus any tighter bounds supplied by the keeper.
A batch reads one price snapshot and uses it for before-and-after valuation. Drift is the sum of the absolute differences between reference-value weights and target weights; a successful batch must reduce it, but need not restore every target exactly.
Budgets persist across transactions
Splitting a rebalance into smaller transactions does not bypass cumulative limits. Pausing does not reset the budget window. New deposits do not replenish the current window’s budget, while a lower current portfolio value can tighten its base. Profitable batches do not erase losses already recorded in the window.
These are execution limits measured against the configured reference source. They do not cap losses from market moves or make a compromised or incorrect source reliable. A nonzero source-qualification hash records a required reference; the contract cannot independently certify the underlying qualification process.
Withdrawals remain available during a pause
The guardian’s pause affects rebalancing only. The shared vault core continues to support redemption and independent claims, subject to normal token behavior and coverage checks.
When shares are burned, the resulting pending claims remain separate from tradable active reserves. A keeper cannot use them to fund a later rebalance.