This guide demonstrates how to build a custom integration program that interacts with GLAM Protocol through Cross-Program Invocation (CPI). The example program adds support of Drift Protocol's transfer_deposit instruction.

For demo purpose, we use the mainnet staging program (gstgptmbgJVi5f8ZmSRVZjZkDQwqKa3xWuUtD5WmJHz) of GLAM.

Steps to create a custom integration

Dependencies

Add GLAM Protocol and target protocol dependencies to Cargo.toml:

[dependencies]
anchor-lang = { workspace = true }
glam_protocol = { path = "../../deps/glam_protocol" }
drift = { path = "../../deps/drift" }  # Replace with your target protocol

glam_protocol and drift are auto generated crates from IDLs using anchor-gen. They provide helpful CPI interfaces that make the integration process easier.

Instruction

Create instructions that wrap target protocol operations. Each instruction should:

1. Accept required parameters - Include instruction-specific parameters (e.g., market_index, amount)
2. Validate authorization - Check integration and signer permissions
3. Build instruction payload - Construct the instruction data for the target protocol
4. Prepare remaining accounts - Collect all accounts needed by the target protocol
5. Call CPI proxy - Invoke GLAM Protocol's cpi_proxy to execute the instruction

Example: Drift Transfer Deposit

See lib.rs:18-79 for a complete example.

Account Structure

Define account structures that include:

1. GLAM accounts (required):

   • glam_state: The vault state account
   • glam_vault: The vault PDA (derived with seeds ["vault", glam_state])
   • glam_signer: The transaction signer
   • glam_protocol_program: GLAM Protocol program

2. Integration authority (required):

   • PDA with seeds ["integration-authority"] from the integration program

3. Target protocol accounts:

   • cpi_program: The target protocol program
   • Protocol-specific accounts (mark as UncheckedAccount if validated by target protocol)

See lib.rs:82-112 for the account structure.

Authorization

Authorization ensures only permitted users can execute specific operations. This is implemented in acl.rs.

1. Define Supported Protocols

Use bitflags to represent protocols your integration supports:

#[repr(u16)]
pub enum SupportedProtocols {
    DriftProtocol = PROTO_DRIFT,  // 1 << 0
}

#[constant]
pub const PROTO_DRIFT: u16 = 1 << 0;

2. Define Protocol Permissions

Define granular permissions for each protocol:

#[repr(u64)]
pub enum DriftPermissions {
    DriftTransferDeposit = PROTO_DRIFT_TRANSFER_DEPOSIT,  // 1 << 0
}

#[constant]
pub const PROTO_DRIFT_TRANSFER_DEPOSIT: u64 = 1 << 0;

3. Check Integration & Protocol

Verify the protocol is enabled for the vault (see acl.rs:45-63):

check_integration_and_protocol(
    &ctx.accounts.glam_state,
    &crate::ID,
    SupportedProtocols::DriftProtocol.into(),
)?;

This checks if the integration program and protocol are registered in the vault's integration_acls.

4. Check Signer Access

Verify the signer has permission for the specific operation (see acl.rs:66-107):

check_signer_access(
    &ctx.accounts.glam_state,
    ctx.accounts.glam_signer.key,
    &crate::ID,
    SupportedProtocols::DriftProtocol.into(),
    DriftPermissions::DriftTransferDeposit.into(),
)?;

This checks:

• Owner has full access
• Delegates must have explicit permission for this integration/protocol/operation
• Delegate access must not be expired

Call CPI Proxy

The CPI proxy is GLAM's mechanism for secure cross-program invocations. Your integration program calls glam_protocol::cpi::cpi_proxy which:

1. Validates the integration authority - Ensures your program is authorized
2. Uses the vault's authority - Signs transactions with the vault's PDA
3. Executes the target instruction - Invokes the target protocol with provided payload and accounts