Share Price & AUM

The share price is the value of one share in accounting-token terms. It is the single most important number a strategy produces: the Machine mints and redeems shares at it, and it is how holders measure their returns.

$\text{Share Price} = \dfrac{\text{AUM}}{\text{Share Supply}}$

Where AUM (assets under management) is the total value of everything the strategy controls. Successful execution by the Operator, through earned yield or appreciation of held assets relative to the accounting token, raises AUM, and because the share supply doesn't change when value accrues, the share price rises. Deposits and redemptions, by contrast, change AUM and supply proportionally, so they leave the share price unchanged.

What goes into AUM

AUM is assembled from four sources:

$\text{AUM} = \text{Idle balance} + \text{Hub Caliber} + \sum \text{Spoke Calibers} + \text{In-flight bridges}$

• Idle balance: the accounting token and any other priceable tokens sitting on the Machine itself (recent deposits not yet deployed, capital just bridged back, or a deliberate buffer kept for redemptions). Each is priced via the Oracle Registry.
• Hub Caliber: the net AUM of the Caliber on the Hub Chain, read directly.
• Spoke Calibers: the net AUM of each enabled Caliber on other chains, carried to the Machine through the Cross-Chain Accounting flow.
• In-flight bridges: capital that has left one chain but not yet arrived on the other. Bridging can take time, so the protocol explicitly tracks value in transit and counts it, ensuring no value appears to vanish mid-transfer. See Liquidity Bridging.

A Caliber's "net" AUM already nets out debt positions, so leveraged strategies are valued correctly.

Keeping AUM fresh

AUM is not recomputed on every block. It is updated on demand, in a single operation that re-reads every source and then mints any due fees. The update can be set either permissionless, or restricted to the Operator and designated accounting agents (see restricted accounting mode). For the update to succeed, the inputs must be fresh.

Freshness is not a fixed value. It is measured against two configurable staleness thresholds:

• Position staleness (per-Caliber positionStaleThreshold). Every position records the time it was last accounted. A position is considered stale once the elapsed time since that accounting reaches the threshold, so all of a Caliber's positions must have been refreshed within that window for the Caliber's value to count.
• Caliber staleness (per-Machine caliberStaleThreshold). Spoke Caliber data arrives through Cross-Chain Accounting carrying the timestamp of the chain it was read on. That data is stale once the elapsed time since its timestamp reaches the threshold. An incoming snapshot must also be strictly newer than the one already stored, so an older snapshot can never overwrite a more recent one. A spoke that has been disabled is skipped entirely.

If any input is stale, the update reverts rather than producing a wrong price. An update is also rejected if it would move the share price faster than a governance-set maximum change rate over the elapsed time, a guard against a sudden, suspicious jump. (The Security Council can update AUM bypassing that guard when legitimately needed.)

Inflation protection

To prevent the classic "first depositor" share-inflation attack on empty or near-empty vaults, share-price and conversion math use virtual offsets (a virtual share supply and a virtual unit of AUM) rather than dividing by raw zero-or-tiny values. In normal operation, with a meaningful supply and AUM, this has no observable effect on the price. It simply makes the math safe at the boundaries.