GLAM IDL Reference

GLAM is a modular Solana program for tokenized vaults, external integrations, and policy enforcement. GLAM Protocol is the core program: it owns the state account, derives the vault account from the state account, records access control, stores vault-level policies, and authorizes vault-signed actions. Readers who want the underlying Solana model for deterministic program-controlled accounts can refer to the official Program Derived Addresses documentation.

GLAM Mint manages Token-2022 share mints, subscription and redemption flows, fee logic, request queues, escrows, and pricing validation for tokenized vaults. Token-2022 behavior such as extensions, transfer hooks, and default account state is documented by Solana in the official Token-2022 extensions documentation. Integration programs connect a GLAM vault to external protocols while preserving GLAM-level authorization. GLAM Config stores protocol-wide configuration, and GLAM Policies provides Token-2022 transfer-hook policy checks.

Account ownership and purpose:

This document covers 21 programs and 274 instructions. The table below summarizes the persistent accounts each program owns or controls. It intentionally describes account purpose rather than raw PDA seed arrays.

Policies and access control:

Access control has three layers that must be read together:

1. The vault owner has all rights on the vault, but only for functionality enabled at the vault level (e.g., an enabled integration).
2. Integrations are opt-in. A Kamino, SPL, CCTP, Bridge, Registered Positions, Loopscale, Neutral Trade, Phoenix, Jupiter Lend, Orca, or MarginFi instruction requires the corresponding integration to be enabled on the vault before it can run.
3. Delegates start with no rights. Adding a delegate only registers an address; the owner must explicitly grant protocol-specific permissions before that delegate can act.

The recommended operating pattern is for the owner to be a multisig, such as Squads, with timelocks enabled for sensitive changes. Timelocks make policy, fee, integration, and access-control changes visible before they take effect. Emergency access updates are intended for narrow response actions such as disabling a compromised delegate or integration.

Policies apply even when the signer is the owner. Vault policies cover asset allowlists, borrowable assets, transfer destinations, and timelocks. Mint policies cover capacity, minimum subscription and redemption amounts, allowlists, blocklists, lockups, and fulfillment rules. Integration policies add protocol-specific restrictions such as slippage limits, market allowlists, borrow allowlists, vault allowlists, destination allowlists, etc.

Pricing atomicity:

All pricing instructions for a given pricing operation must be included in the same Solana transaction.

Splitting pricing instructions across multiple transactions is not supported and will produce incorrect or rejected NAV calculations. Pricing writes per-protocol valuation records into the GLAM state. Subscription fulfillment, redemption fulfillment, fee crystallization, and AUM validation rely on those records being fresh and internally consistent for the same operation.

Remaining-account validation:

Many GLAM instructions accept additional accounts via Anchor's remaining_accounts slot — for CPI into external programs, batch operations, or transfer-hook extra metas. These extras are not constrained by Anchor's account-struct macros, so GLAM enforces them inside the instruction: the only vault-controlled accounts the instruction can touch are the ones it is meant to act on.

For example, jupiter_swap and jupiter_swap_v2 reject any vault token accounts in remaining_accounts other than the input and output ATAs — preventing a caller from sneaking additional vault token accounts into the route and having them swapped or otherwise mutated.

This is an ongoing effort: per-instruction validation is being applied progressively across every instruction that accepts remaining accounts.