svm: Kitchen

@eco-incorp/sauce/svm is the Solana side: staging a program through the kitchen, resolving accounts against the compiler’s account manifest, building and sending transactions, and verifying settle programs. Solana execution goes through the Kitchen client here; the SDK’s SVM route helpers emit a legacy instruction that the released engine does not accept.

import { createSauceSvmClient } from "@eco-incorp/sauce/svm";

This page covers sdk/dist/svm/kitchen.d.ts.

Generated from the type declarations shipped in @eco-incorp/sauce 0.99.4. Each entry shows the package authors’ JSDoc and declaration for this SDK version. For runtime compatibility and deployed addresses, see architecture and deployments.

`derivePotPda`

Function · sdk/dist/svm/kitchen.d.ts A Pot: ["pot", owner, salt]. The salt is what lets one owner hold many - it is raw bytes, not a counter, so a caller with a natural 32-byte id (an intent hash, say) passes it directly.

export declare function derivePotPda(kitchen: Address, owner: Address, salt: Uint8Array): Promise<KitchenPda>;

`deriveExecutionFeeConfigPda`

Function · sdk/dist/svm/kitchen.d.ts The execution-fee config: ["execution_fee"], one per kitchen. It is both the fee’s source of truth and the treasury the fees accumulate in, so every cook takes it writable even when the configured fee is zero.

export declare function deriveExecutionFeeConfigPda(kitchen: Address): Promise<KitchenPda>;

`deriveProgramDataPda`

Function · sdk/dist/svm/kitchen.d.ts A program’s ProgramData under the upgradeable loader: [program]. The fee instructions authorize against the authority recorded there rather than a stored admin key, so whoever can upgrade the kitchen is whoever can price it.

export declare function deriveProgramDataPda(program: Address): Promise<KitchenPda>;

`deriveCodeBufferPda`

Function · sdk/dist/svm/kitchen.d.ts A code buffer’s metadata account: ["buffer", owner, nonce_le].

export declare function deriveCodeBufferPda(kitchen: Address, owner: Address, nonce: bigint): Promise<KitchenPda>;

`deriveCodePda`

Function · sdk/dist/svm/kitchen.d.ts The bytes account for a buffer: ["code", code_buffer]. Seeded on the METADATA account’s address, so the pair is bound by derivation and neither needs to store a pointer to the other for the kitchen to validate.

export declare function deriveCodePda(kitchen: Address, codeBuffer: Address): Promise<KitchenPda>;

`buildCreatePotInstruction`

Function · sdk/dist/svm/kitchen.d.ts

export declare function buildCreatePotInstruction({ kitchen, owner, engineProgram, pot, salt, space, }: CreatePotInput): Instruction;

`buildClosePotInstruction`

Function · sdk/dist/svm/kitchen.d.ts

export declare function buildClosePotInstruction({ kitchen, owner, engineProgram, pot, salt, }: ClosePotInput): Instruction;

`buildCookInstruction`

Function · sdk/dist/svm/kitchen.d.ts cook - stage-free execution: the bytecode travels in the instruction data. The transaction MUST carry a RequestHeapFrame(HEAP_FRAME_BYTES). The kitchen CPIs into the engine, whose interpreter memory lives in the transaction’s heap frame and not in accounts, so without it the ENGINE access-violates before any opcode runs - surfacing from the kitchen as an opaque ProgramFailedToComplete. Use buildHeapFramePrepend() (./prepends.js). Pot and code-buffer lifecycle instructions need no such thing; only the two cooks execute. Note there is no pot account here. The kitchen derives it from pot_salt and owner and signs for it, so a Pot the program touches belongs in tail unsigned.

export declare function buildCookInstruction({ kitchen, owner, engineProgram, potSalt, pot, feeConfig, bytecode, maxExecutionFee, feePayer, tail, }: CookInput): Instruction;

`buildCookFromAccountInstruction`

Function · sdk/dist/svm/kitchen.d.ts cook_from_account - the staged transport: the bytecode is read from a finalized code account. Needs the same RequestHeapFrame as cook - see there.

export declare function buildCookFromAccountInstruction({ kitchen, owner, codeBuffer, code, engineProgram, potSalt, pot, feeConfig, pin, maxExecutionFee, feePayer, tail, }: CookFromAccountInput): Instruction;

`buildCreateCodeBufferInstruction`

Function · sdk/dist/svm/kitchen.d.ts Creates the codeBuffer metadata account and its code data account, sized for capacity. capacity must be 1..=MAX_CODE_LEN; the kitchen rejects anything else with CapacityOutOfRange, and this throws first so the bound is visible without a simulation. A create allocates at most ONE GROWTH_STEP. The runtime caps how much an account can grow per instruction, so a capacity above that is only partly allocated here and needs Math.ceil(capacity / GROWTH_STEP) - 1 further buildGrowCodeBufferInstruction calls before the code account is the full size. The cap resets per instruction, so those repeats can share one transaction. Writing before the account is fully grown fails with WriteOutOfBounds.

export declare function buildCreateCodeBufferInstruction({ kitchen, owner, codeBuffer, code, nonce, capacity, }: CodeBufferAccounts & {
    nonce: bigint;
    capacity: number;
}): Instruction;

`buildGrowCodeBufferInstruction`

Function · sdk/dist/svm/kitchen.d.ts One growth step. A CPI-created account cannot be allocated more than GROWTH_STEP at once, so a larger buffer repeats this - the runtime’s limit resets per instruction, so the repeats fit in one transaction.

export declare function buildGrowCodeBufferInstruction({ kitchen, owner, codeBuffer, code, }: CodeBufferAccounts): Instruction;

`buildWriteCodeBufferInstruction`

Function · sdk/dist/svm/kitchen.d.ts

export declare function buildWriteCodeBufferInstruction({ kitchen, owner, codeBuffer, code, offset, chunk, }: CodeBufferAccounts & {
    offset: number;
    chunk: Uint8Array;
}): Instruction;

`buildFinalizeCodeBufferInstruction`

Function · sdk/dist/svm/kitchen.d.ts Seals the buffer at len and pins its digest. The kitchen shrinks the code account to exactly len here, which is the security property: the engine executes the account’s whole data slice and bounds jumps only by that slice’s length, so any byte past len would be jump-reachable but outside the hash.

export declare function buildFinalizeCodeBufferInstruction({ kitchen, owner, codeBuffer, code, len, expectedSha256, }: CodeBufferAccounts & {
    len: number;
    expectedSha256: Uint8Array;
}): Instruction;

`buildCloseCodeBufferInstruction`

Function · sdk/dist/svm/kitchen.d.ts Closes both accounts and refunds their rent. expectedSha256 gates the close on the staged bytes.

export declare function buildCloseCodeBufferInstruction({ kitchen, owner, codeBuffer, code, expectedSha256, }: CodeBufferAccounts & {
    expectedSha256?: Uint8Array;
}): Instruction;

`buildInitializeExecutionFeeInstruction`

Function · sdk/dist/svm/kitchen.d.ts initialize_execution_fee - creates the config PDA. The initial fee must be greater than zero; a kitchen is unusable until it is priced, and a later set may take it back to zero.

export declare function buildInitializeExecutionFeeInstruction({ kitchen, authority, programData, feeConfig, payer, initialFee, }: ExecutionFeeAdminInput & {
    payer?: Address;
    initialFee: bigint;
}): Instruction;

`buildSetExecutionFeeInstruction`

Function · sdk/dist/svm/kitchen.d.ts set_execution_fee - repricing, including back to zero.

export declare function buildSetExecutionFeeInstruction({ kitchen, authority, programData, feeConfig, fee, }: ExecutionFeeAdminInput & {
    fee: bigint;
}): Instruction;

`buildWithdrawExecutionFeesInstruction`

Function · sdk/dist/svm/kitchen.d.ts withdraw_execution_fees - collect what the config PDA holds. amount omitted sweeps everything ABOVE the account’s rent-exempt minimum, which the withdrawal never spends: that same account is the config every cook reads, and a zero balance would have the runtime reap it. The recipient must already be rent-exempt, or the runtime refuses the transaction for leaving it rent-paying.

export declare function buildWithdrawExecutionFeesInstruction({ kitchen, authority, programData, feeConfig, recipient, amount, }: ExecutionFeeAdminInput & {
    recipient: Address;
    amount?: bigint;
}): Instruction;

`TailAccount`

Type · sdk/dist/svm/kitchen.d.ts One entry of a program’s own account tail, in the shape a kit Instruction carries.

export type TailAccount = AccountLookupMeta | AccountMeta;

`CODE_BUFFER_SEED`

Variable · sdk/dist/svm/kitchen.d.ts The kitchen’s own #[constant]s, from the same IDL.

CODE_BUFFER_SEED = "buffer"

`CODE_SEED`

Variable · sdk/dist/svm/kitchen.d.ts

CODE_SEED = "code"

`POT_SEED`

Variable · sdk/dist/svm/kitchen.d.ts

POT_SEED = "pot"

`EXECUTION_FEE_SEED`

Variable · sdk/dist/svm/kitchen.d.ts

EXECUTION_FEE_SEED = "execution_fee"

`GROWTH_STEP`

Variable · sdk/dist/svm/kitchen.d.ts One grow_code_buffer step: MAX_PERMITTED_DATA_INCREASE, the most a CPI-created account can grow in a single instruction. IDL-guarded by engine-wire-drift.test.ts.

GROWTH_STEP = 10240

`MAX_CODE_LEN`

Variable · sdk/dist/svm/kitchen.d.ts

MAX_CODE_LEN = 1048576

`MAX_POT_LEN`

Variable · sdk/dist/svm/kitchen.d.ts

MAX_POT_LEN = 10240

`SALT_BYTES`

Variable · sdk/dist/svm/kitchen.d.ts A Pot’s salt and a code buffer’s expected_sha256 are both exactly 32 bytes.

SALT_BYTES = 32

`BPF_LOADER_UPGRADEABLE`

Variable · sdk/dist/svm/kitchen.d.ts The loader that owns every upgradeable program’s ProgramData, which is where the fee instructions read the kitchen’s live upgrade authority from.

BPF_LOADER_UPGRADEABLE: Address