Vault Lifecycle & NAV¶

How value moves through an ARKONIX vault: the ERC-7540 epoch cycle, how deposits are deployed and redemptions funded, how vaults are provisioned, and how asset prices become the published share price. For the contract-level standards see the Protocol Layer; for how each transaction in these flows is authorized and signed see the Execution & Strategy Layer.

The epoch cycle¶

Asynchronous vaults settle in epochs. Users queue intent on-chain; the platform approves and settles the queue at NAV; users claim the result. The platform is never in possession of the funds — every step is a contract interaction (see Custody & Key Management).

user wallet                      execution platform                on-chain
───────────                      ──────────────────                ─────────
requestDeposit /
requestRedeem  ──────────────▶   request queued in the
                                 current epoch
                                        │
                                 epoch becomes due
                                 (schedule, threshold,
                                  or manual trigger)
                                        │
                                 approval ──────────────────────▶  epoch approved
                                  · per-asset pricing resolved       at NAV
                                  · share-price sanity gates
                                  · redemptions: liquidity
                                    sourcing must complete first
                                        │
                                 settlement ────────────────────▶  shares issued /
                                  · driven by the on-chain           revoked at the
                                    approval event                   approved price
                                  · cross-chain delivery
                                    verified before issuing
                                        │
claim shares / assets  ◀───────────────┘                           claimable

Approval and settlement are deliberately split. The approval step only advances the epoch at a verified NAV. Settlement is event-driven: dedicated workers watch the chain for approval events, reconcile against live on-chain state, and only then issue or revoke shares and notify each depositor's position. Nothing settles off a database record alone; if an event is missed or a step fails, the watcher's cursor rewinds so no request is dropped.

Safeguards on every approval:

Pricing never defaults. Each asset's pool price is resolved through the pricing service; a pricing failure aborts the run rather than falling back to an assumed value.
Share-price sanity gates. A computed share price that deviates materially from the last published value triggers alerts, and large deviations block the run entirely until an operator investigates.
Cross-chain delivery gates. For vaults on spoke chains, issuance waits until the approved assets have verifiably arrived in the pool escrow.

Manual epoch runs go through an explicit approval workflow: the platform prepares an execution snapshot (pending depositors, amounts, NAV and share price at preparation time), and a partner admin must approve it — with the EIP-712 second factor — before anything executes. Only one prepared execution can be pending per vault and direction at a time.

Redemption sourcing¶

Redemptions are funded automatically. When a redeem epoch is due and the hub escrow holds less liquidity than the epoch requires, the platform plans and executes a sourcing run before the epoch is approved:

Free hub cash — counted first, no action needed.
Hub asset sales — non-cash assets held at the hub are swapped to the redemption asset, sized with a slippage cushion. Only assets the vault's execution policy permits selling are candidates.
Sub-vault redemptions (hub-local) — shares the vault holds in other ARKONIX vaults on the same chain are redeemed straight into hub escrow.
Leveraged-position shrink — where the vault runs a leveraged carry loop, cash is extracted at constant loan-to-value, sized conservatively against live market liquidity.
Remote-chain legs — per remote chain: asset sales and sub-vault redemptions, consolidated into a single CCTP bridge transfer back to the hub. Bridged funds only count toward coverage once they arrive.

All-or-nothing settlement

A redemption epoch is approved only when the full required amount has been staged — partial approvals are never fired. If the plan cannot fully cover the shortfall, or execution stalls, the run parks for operator review with staged funds accounted for; it does not settle a partial epoch. Immediately before approval the NAV is re-checked so the epoch settles at a current price.

Staged funds are credited crash-safely (balances are measured before and after each sweep, so a restart cannot double-count), and every leg is executed through the same policy-gated pipeline as any other transaction.

Deposit routing¶

The inverse flow. Share classes can be configured with target allocations across sub-vaults; after deposits settle, free hub cash is routed toward those weights — same-chain allocations as vault-to-vault deposits, cross-chain allocations via a CCTP bridge leg followed by a deposit on the destination chain.

Routing is best-effort rather than all-or-nothing: uneconomic legs are skipped, an under-deployed residual simply waits for the next pass, and routing always yields to active redemptions — escrow liquidity is reserved for exits first.

Vault-to-vault flows¶

Vaults can hold shares of other ARKONIX vaults (fund-of-fund composition):

Deposit — escrow cash moves into a sub-vault deposit request, the sub-vault's own epoch approves it, and the minted shares are claimed back into the parent's escrow. Where the sub-vault settles in a different asset, conversion steps run first with quoted minimum-output floors.
Unwind — the exact reverse: shares are redeemed through the sub-vault's epoch machinery and the proceeds land back in the parent escrow. Because an unwind has no rollback, every permission it will need is validated up front before the first transaction is sent.

Both directions are long-running, multi-step operations executed as durable, resumable state machines — every step re-checks on-chain state before acting and is idempotent, so a crash or restart never repeats a transfer (see orchestration state machines).

Escrow sweeping¶

Swap and bridge outputs land in the vault's on-chain execution manager, which NAV does not read — only pool escrow counts. A shared sweep primitive deposits execution-manager balances back to escrow after each operation, retries around settlement races, and self-heals any previously stranded amounts. This keeps NAV complete and conservative.

Cross-chain USDC: CCTP¶

All cross-chain USDC movement uses Circle's CCTP (burn on the source chain, attest, mint on the destination):

Each transfer is tracked end-to-end: burn → attestation → mint → sweep to escrow.
Transfers in flight are counted in NAV on the source chain, so the published share price does not dip while funds are mid-bridge.
Source and destination domains are verified before any burn, and a transfer that stalls parks for operator review rather than failing silently.

Vault deployment & provisioning¶

Deploying a vault is a multi-step cross-chain operation, run as a resumable orchestration:

Register the deposit asset on the spoke chain and verify the pool is active.
Deploy and link the vault through the hub's cross-chain messaging, then wait for the deployment to resolve on the destination chain.
Configure pricing: publish the initial share price and synchronize the price of every registered asset — preventing the class of go-live failures where a strategy's first trade reverts on a missing price.
Grant the balance-sheet manager roles and register transfer-restriction hooks where the share class requires them.

Share-class creation follows the same pattern — created at the hub, then notified to each spoke with per-network transferability settings that default to fully restricted rather than accidentally open.

Vault controls (pause/unpause, link/unlink, reserve limits) are exposed to authorized roles; pausing a vault both blocks synchronous deposits on-chain and stops the settlement and strategy workers from acting on it. A read-only provisioning preflight verifies policy roots, notified prices, and execution permissions before a vault goes live — anything unknown is treated as not provisioned.

All share-class configuration changes (epoch durations and thresholds, auto-settlement flags, cooldowns, fee recipient, routing weights, strategy enablement) flow through a single validated mutation path and are audit-logged; sub-vault target weights are validated so enabled weights never exceed 100%.

Share classes can be presented in a non-USD denomination. Internal accounting always remains USD; the published series is converted using FX marks taken only from allowlisted on-chain sources, with staleness and sanity-band checks plus an independent cross-source divergence check. If a compliant FX mark cannot be obtained the denominated series fails closed (it is withheld rather than published from a suspect rate) while USD accounting continues unaffected.

Pricing & NAV¶

Asset pricing¶

Every token is priced in USD through a configuration-driven pricing service. Supported methods include direct oracle reads with staleness bounds, exchange-rate contracts composed over an underlying, market pricing with fallback sources, internal NAV-per-share for ARKONIX share tokens held as assets, and fixed-income instrument pricing that pins to par at maturity. Per-asset sanity bounds reject implausible prints, and a pricing failure raises — it never silently defaults.

Portfolio NAV¶

NAV is computed per share class across all of its chains and includes everything the vault economically owns: escrow holdings, execution-manager balances, positions held inside lending and yield protocols (valued with maturity effects), balances on connected trading venues, in-flight bridge transfers, and pending issuance. Share price is then simply NAV / total supply, with supply summed across every chain the share class is deployed on.

On-chain publication¶

A dedicated publisher computes each share class's price on a fixed cadence and pushes it on-chain (the event series the public API exposes as share-price history). It is the sole writer of the published price: updates below a minimal change threshold are skipped, sanity-gate violations block publication and alert operators, and every update — pushed, skipped, or blocked — is recorded with its reason.

APY & return integrity¶

Return figures are protected by two independent layers:

Snapshot validation. Daily snapshots are only marked valid when share price, supply, and TVL are mutually consistent; torn or partial reads are flagged and excluded rather than averaged in.
Conservative return math. Short windows (7/30/90-day) are reported as cumulative returns — annualizing short windows manufactures headline numbers — and all-time returns are annualized only after a minimum track record. The return basis is the published on-chain share price, computed over valid snapshots only, with median anchoring and hard caps against outlier reads.

Continue with the Execution & Strategy Layer for how every transaction in these flows is authorized, or Data, Indexing & Workers for how the underlying events are indexed and served.