GLAM ProtocolProduction
set_jupiter_swap_policy
Sets Jupiter swap policy including slippage and allowlist guardrails.
Handler narrative
- Load the GLAM state or program account required by the instruction and verify the signer.
- Apply the requested state, policy, pricing, or system action after enforcing owner/delegate checks.
Required conditions
- The submitted accounts must match the declared account list, signer requirements, writable requirements, fixed program addresses, and account relationships shown below.
- The GLAM state account is the source of truth for owner, enabled integrations, delegate permissions, policies, assets, borrowable assets, timelock settings, mint linkage, and pricing records.
- Owner-level actions must be signed by the state owner unless the instruction is explicitly an integration callback, mint-authority callback, delegate action, or emergency access update.
- Configuration changes must pass owner or authorized-manager checks and, when the state or mint timelock is active, must follow the propose/apply timing model instead of taking effect immediately.
Accounts
| Account | Role | Description |
|---|---|---|
| glam_state | writable | State account owned by the GLAM Protocol program; it records vault configuration, policies, and pricing records. |
| glam_signer | signer, writable | Calling authority. It must be the owner or a delegate with the explicit permission required by this instruction. |
Arguments
| Argument | Type | Notes |
|---|---|---|
| policy | JupiterSwapPolicy | Policy object written to GLAM state for this program or integration. Fields: max_slippage_bps: u16 - Upper bound on swap slippage accepted by the vault.; swap_allowlist: option<vec<pubkey>> - Optional list of allowed output/input mints for allowlisted swap mode.; max_deviation_bps: i16 - Quote/oracle deviation guardrail where configured. |
Policy & permissions
- No external integration enablement is required beyond the program-level functionality involved in this instruction.
- Only the owner is expected. Delegates do not receive this capability by being added; it must be granted explicitly if supported.
- Policy changes should be governed by owner controls and timelock settings.
Cross-instruction constraints
- No additional cross-instruction constraint is documented beyond account initialization, authority checks, and policy validation.