Flows

Shares of tokenized vaults are tokenized. When a user subscribes, the amount of vault shares to issue is calculated based on the current AUM of the vault. When a user redeems their shares, the shares get burned and withdrawal assets can be claimed.

​

Subscriptions

GLAM tokenized vaults support two types of subscriptions: instant subscription and queued subscription.

​

Instant Subscriptions

Vault shares are issued in the same transaction where the user makes the deposit. Instant subscription is preferred if vault AUM can be immediately calculated and the amount of shares can be determined instantly.

​

Queued Subscriptions

In case vault AUM can only be calculated with a delay, queued subscription should be used. The diagram below shows the subscription flow:

​

Redemptions

GLAM tokenized vaults support both instant and queued redemptions, depending on the strategy and configuration of the vault.

​

Instant Redemptions

Instant redemption allows users to redeem shares and receive withdrawal assets in a single transaction. This mode is enabled when the vault’s notice period and settlement period are both set to 0. Instant redemption is only possible if the vault has sufficient liquidity to fulfill the request at the time of redemption. This mode is recommended for tokenized vaults with simple, highly liquid strategies (e.g., token baskets).

​

Queued Redemptions

If the vault is configured with a non-zero notice period or settlement period, redemptions are queued and expected to be fulfilled asynchronously. When a user submits a redemption request, it is timestamped and placed in a queue. Once the request becomes eligible (based on the notice period and settlement period), it can be fulfilled. After fulfillment, the user must initiate a claim transaction to complete the redemption. Queued redemption is recommended for strategies that require liquidity management, batching, or time to unwind positions.

​

Execution Window

​

Notice Period

The notice period is the configured lead time for a queued subscription or redemption request. It is measured in seconds or slots. How it affects fulfillment eligibility depends on the notice period type. GLAM supports two notice period types:

• Hard: Requests become eligible only after the notice period has fully elapsed.
• Soft: Requests are eligible immediately if liquidity is available; the notice period is advisory and does not block early fulfillment.

For both types, the configured notice period is still used when calculating cancellation and execution-window boundaries. Choosing a type:

• Use Hard when the manager genuinely needs lead time, or when fulfillment must align to a known cutoff:
  • Strategy-bound assets that take time to unwind: lending positions (Kamino, Drift), LP positions, perps, native validator unstaking that is gated by epoch boundaries.
  • Periodic-NAV or batched funds, where a hard notice aligns requests to a known valuation cutoff and prevents acting on stale or pre-rebalance NAV.
  • Fairness and anti-timing: forces a minimum gap between request and execution, so users cannot front-run a NAV update, fee crystallization, or a large rebalance.
• Use Soft for stable, mostly-cash or DEX-liquid vaults where the manager can net requests instantly against on-hand liquidity. Liquid staking vaults that hold tradeable LSTs (e.g. JitoSOL, mSOL) typically fit here; vaults that perform native validator unstaking should use Hard.

​

Settlement Period

The settlement period defines the maximum duration after the notice period during which a request can be fulfilled. It ensures that requests are processed in a timely manner and provides a bounded execution window for managers or external actors.

​

Cancellation Window

The cancellation window defines the duration after submitting a request during which it can be cancelled. This must be less than or equal to the notice period. A request is cancellable under two conditions:

1. Within the cancellation window: The request was recently created and is still within the cancellation window (created_at + cancellation_window > now). This gives users a grace period to cancel immediately after submitting a request.
2. After the execution window has expired: The request has passed both the notice period and settlement period (created_at + notice_period + settlement_period < now). This protects investors by allowing them to reclaim their assets if the manager fails to fulfill the request within the promised timeframe.

Between these two windows — after the cancellation window closes but before the execution window expires — the request is locked and cannot be cancelled. Queued requests can be cancelled by:

• The user who submitted the request.
• The vault owner.
• An active delegate with the Mint CancelRequest permission.

When a request is cancelled, the escrowed deposit assets or vault shares are returned to the request user’s associated token account.

​

Permissionless Fulfillment

If permissionless fulfillment is enabled, any actor including users and bots can fulfill eligible requests once they enter the settlement window. If it is disabled, only the vault manager is authorized to trigger fulfillment.

​

Fulfillment Order

Fulfillment scans the request queue in FIFO insertion order. Requests are appended when submitted, and the fulfillment routine walks the queue oldest-first. It processes eligible, unfulfilled requests in that scan order; requests that are not yet eligible (for hard notice periods) or already fulfilled are skipped without stopping the scan. Within a single fulfillment call, subscriptions and redemptions net out against each other. It aggregates the share and base-asset deltas across the processed eligible requests and settles only the net difference. Shares are minted or burned once for the net delta, and base asset moves between the vault and escrow only by the net amount. Incoming subscription deposits processed earlier in the same batch therefore count as available liquidity for redemptions processed later in the queue. If a redemption cannot be paid out because the vault and earlier in-batch subscription deposits still lack sufficient base asset liquidity, fulfillment stops at that request. The redemption stays unfulfilled at its existing queue position and will be retried on a later fulfillment call once liquidity is available.