pub struct FinalizeSettle<'a> {
pub program_id: Pubkey,
pub state_pda: Pubkey,
pub begin_ix_index: u16,
pub source_buffers: &'a [Pubkey],
pub destinations: &'a [Pubkey],
pub bumps: &'a [u8],
pub amounts: &'a [u64],
}Expand description
Builder for a FinalizeSettle instruction pushing the funds described by the
parallel lists:
source_buffers[i]is the buffer token account the funds come from,destinations[i]is the account the funds go to (an order’s buy token account),bumps[i]is the canonical bump ofsource_buffers[i], so the program re-derives the buffer PDA with one hash instead of searching,amounts[i]is the amount to push.
This instruction comes in pair with a BeginSettle instruction. The slices
are assumed to be built in parallel with the order information specified in
BeginSettle. Notably, (1) the source buffer is the one corresponding to
the order’s buy token, and (2) the destinations must be the buy token
accounts specified in the corresponding order.
The slices are assumed to have the same length but this is not enforced by
the builder.
Wire format (with n total pushes):
[discriminator=1][begin_ix_index: u16 LE][bump: u8 ×n][amount: u64 LE ×n].
Required accounts:
[instructions_sysvar (R), state_pda (R), token_program (R)] followed, per
push, by [source_buffer (W), destination (W)].
FinalizeSettle validates that each source is the canonical buffer for its
destination’s mint and executes the transfers; the order correspondence and
that each destination is an order’s buy token account are BeginSettle’s
checks. So a push isn’t aware of what orders are being paid, just the accounts
to move funds between, the source’s bump, and the amount. The same buffer may
legitimately fund several pushes.
Fields§
§program_id: Pubkey§state_pda: Pubkey§begin_ix_index: u16§source_buffers: &'a [Pubkey]§destinations: &'a [Pubkey]§bumps: &'a [u8]§amounts: &'a [u64]