Skip to main content
The wallet and minter programs have a set of accounts and instructions that you can use to build with Gateway on Solana. The following sections describe the main Program Derived Account (PDA) structures and instructions for the Gateway programs. For static Solana accounts, instruction arguments, and instruction definitions, use the onchain IDLs as the source of truth. This page adds high-level Gateway guidance and documents the dynamic gatewayMint remaining accounts that are not represented statically in the IDL.

Mainnet program addresses

Devnet program addresses

Account structures

The following section describes the main Program Derived Account (PDA) structures for the Gateway programs. You can find the full IDLs for the Gateway Solana programs at the following links:

GatewayDeposit

A Gateway Wallet data account used to track the balance of a particular depositor and token.

GatewayDelegate

A Gateway Wallet data account used to store delegates.

Denylist

A Gateway Wallet data account used to store a single denylisted account. The address being denylisted is implied in the PDA address, and the account itself stores no additional data.

UsedTransferSpecHash

A Gateway Wallet data account used to store whether a TransferSpecHash has been used, to prevent replay. The used TransferSpecHash is implied in the PDA address, and the account itself stores no additional data.

PDA derivation

The following PDAs are used by the Gateway Solana programs. Seed bytes are ASCII strings unless otherwise noted.

GatewayWallet program PDAs

GatewayMinter program PDAs

GatewayMinter

Stores general configuration for the GatewayMinter program.

GatewayWallet

Stores general configuration for the GatewayWallet program.

Instructions

The following section describes the main instructions for the Gateway programs. Instruction data uses Anchor-style Borsh encoding.

gatewayMint

Mints tokens to a recipient on Solana based on a signed attestation produced by the Gateway API. The instruction supports two parameter encodings:
  • Full attestation mode: Pass the full ReducedMintAttestation message and its ECDSA signature as returned by the Transfer API.
  • Parameter mode: Pass only the minimal fields that cannot be inferred onchain; the program reconstructs the attestation and verifies the ECDSA signature against it.
For the static instruction definition, refer to the onchain GatewayMinter IDL. The remaining accounts described below are dynamic and therefore are not captured statically in the IDL.

Account list

The Gateway Mint flow uses fixed program accounts together with three additional ordered accounts for each transfer in the attestation. Refer to the onchain IDL for the canonical static account list.
For transfers to Solana, the destinationRecipient must be an initialized USDC Token Account. If the intended recipient is a standard wallet address, use its Associated Token Account (ATA), not the recipient wallet address itself.
Three additional ordered accounts are required in the remaining accounts list for each transfer in the attestation: In the common direct-mint flow, destination_caller is the transaction sender and usually matches payer. If the attestation sets a non-zero destinationCaller, it must match the signer that submits the mint transaction.

Full attestation mode (gateway_mint)

Pass the full reduced attestation bytes and signature returned by the Transfer API. Refer to the onchain IDL for the canonical static argument definitions for gateway_mint and gateway_mint_with_params.

Parameter mode (gateway_mint_with_params)

Saves transaction space by assuming certain fields or reading them from the account list. Refer to the onchain IDL for the canonical static argument definitions for gateway_mint_with_params and MintAttestationParams.

deposit

Deposits tokens into the Gateway Wallet system.
  • Deposit mode: Deposits tokens on behalf of the signer. The tokens are transferred from the signer’s token account to the Gateway Wallet custody and tracked in the signer’s balance.
  • Deposit For mode: Deposits tokens on behalf of another depositor. The tokens are transferred from the signer’s token account to the Gateway Wallet custody and tracked in the specified depositor’s balance.
Refer to the onchain GatewayWallet IDL for the canonical static account and argument definitions for deposit and depositFor.

initiateWithdrawal

Starts the withdrawal process. After a program-defined withdrawal_delay (in slots), withdraw may be called to complete the withdrawal. Repeated calls add to the amount and reset the delay timer. Refer to the onchain GatewayWallet IDL for the canonical static account and argument definitions for initiateWithdrawal.

withdraw

Completes a withdrawal that was initiated at least withdrawal_delay earlier. The full pending amount is withdrawn to the depositor’s token account. Refer to the onchain GatewayWallet IDL for the canonical static account definitions for withdraw.

addDelegate

Allows a delegate to transfer the caller’s balance for the specified token. Refer to the onchain GatewayWallet IDL for the canonical static account and argument definitions for addDelegate.

removeDelegate

Revokes a previously granted delegate for the caller’s balance of the specified token.
Revocation is respected by the Gateway API, which refuses BurnIntents signed by a revoked delegate. However, revocation does not prevent a BurnIntent signed by the delegate from being executed onchain. This design prevents malicious users from blocking a burn transaction by pre-emptively revoking a signer.
Refer to the onchain GatewayWallet IDL for the canonical static account and argument definitions for removeDelegate.