Conventions

Every method in the gem follows the same handful of rules. Learn them once here and the per-operation pages stay short.

The three layers

The gem mirrors Solace's layering. You can drop down a level whenever you need more control:

Layer	What it is	When to use
Program client — Solace::Programs::ZarTrustlessEscrow	High-level methods that derive accounts, build, sign, and send.	Almost always.
Composers — Solace::Composers::ZarTrustlessEscrow*Composer	Declare an instruction's accounts + permissions; resolve indices.	Custom fee payer/signing, or batching several instructions in one transaction.
Instructions — Solace::ZarTrustlessEscrow::Instructions::*	Raw byte encoding (discriminator + Borsh args + account indices).	Advanced; you manage the AccountContext yourself.

Each operation page documents all three for that instruction.

get_ vs fetch_

Method names tell you whether they touch the network:

• get_* — pure, local derivation. No RPC. These return a [address, bump] pair (Program Derived Addresses): get_escrow_deposit_address, get_mediated_escrow_deposit_address, get_vault_address.
• fetch_* — a remote RPC call that reads and deserializes an account: fetch_escrow_deposit, fetch_mediated_escrow_deposit.

Derivation and fetching are separate steps. A fetch_* method takes the account address, not a seed — derive it first, then fetch:

address, = program.get_escrow_deposit_address(claim_authority: claim_authority.address)
deposit  = program.fetch_escrow_deposit(address:)

Existence checks follow the same shape: escrow_deposit_exists?(address:) and mediated_escrow_deposit_exists?(address:). See PDA Derivation & Fetchers.

The send-and-sign trio: payer, sign, execute

Every write operation (deposit, claim, mediated_release, …) accepts the same three controls:

Parameter	Type	Default	Description
payer	Keypair	—	The transaction fee payer. Threaded into the instruction as its fee_payer account, set as the transaction fee payer, and always a signer.
sign	Boolean	true	Sign the transaction with payer and the operation's other required signer(s).
execute	Boolean	true	Submit the signed transaction to the cluster.

Each method returns a Solace::Transaction. Submission does not block on confirmation — wait explicitly when you need the result on chain:

tx = program.deposit(payer: depositor, mint:, depositor:, claim_authority:, amount:)
connection.wait_for_confirmed_signature { tx.signature }

Pass execute: false to build and sign without sending, or sign: false to get an unsigned transaction. Every write method also has a compose_* counterpart returning a Solace::TransactionComposer if you'd rather drive signing and sending yourself.

Extra signers per operation

Beyond payer, each operation requires the relevant authority to sign. The program method takes that authority as a Keypair and co-signs with it:

Operation	Extra signer (besides payer)
deposit	depositor
claim	claim_authority
reclaim	— (the depositor/sponsor pays as payer)
token_account_init	—
mediated_deposit	depositor
mediated_release	mediator
mediated_reclaim	depositor

Pubkey vs. keypair arguments

• Accounts that must sign are passed as Solace::Keypair (e.g. depositor in deposit, mediator in mediated_release).
• Accounts that are only referenced can be anything that responds to #to_s with a base58 address — a String, Solace::PublicKey, or Solace::Keypair (e.g. claimant, recipient, claim_authority when it isn't the signer).

Token program (SPL vs Token-2022)

The program uses the SPL TokenInterface, so it works with both token programs. Every method accepts token_program_id:, defaulting to Solace::Constants::TOKEN_PROGRAM_ID (legacy SPL Token). For a Token-2022 mint, pass Solace::Constants::TOKEN_2022_PROGRAM_ID — it is used both to derive associated token accounts and as the token program in the instruction.