> ## Documentation Index
> Fetch the complete documentation index at: https://docs.eco.com/llms.txt
> Use this file to discover all available pages before exploring further.

# svm: Kitchen

> Kitchen: 34 exports of the svm module of @eco-incorp/sauce, including derivePotPda, deriveExecutionFeeConfigPda, deriveProgramDataPda, deriveCodeBufferPda, deriveCodePda, buildCreatePotInstruction.

`@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.

```typescript theme={null}
import { createSauceSvmClient } from "@eco-incorp/sauce/svm";
```

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

<Note>
  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](/programmable-transactions/sauce/architecture-and-deployments).
</Note>

### `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.

```typescript theme={null}
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.

```typescript theme={null}
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.

```typescript theme={null}
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]`.

```typescript theme={null}
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.

```typescript theme={null}
export declare function deriveCodePda(kitchen: Address, codeBuffer: Address): Promise<KitchenPda>;
```

### `buildCreatePotInstruction`

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

```typescript theme={null}
export declare function buildCreatePotInstruction({ kitchen, owner, engineProgram, pot, salt, space, }: CreatePotInput): Instruction;
```

### `buildClosePotInstruction`

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

```typescript theme={null}
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**.

```typescript theme={null}
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.

```typescript theme={null}
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`.

```typescript theme={null}
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.

```typescript theme={null}
export declare function buildGrowCodeBufferInstruction({ kitchen, owner, codeBuffer, code, }: CodeBufferAccounts): Instruction;
```

### `buildWriteCodeBufferInstruction`

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

```typescript theme={null}
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.

```typescript theme={null}
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.

```typescript theme={null}
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.

```typescript theme={null}
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.

```typescript theme={null}
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.

```typescript theme={null}
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.

```typescript theme={null}
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.

```typescript theme={null}
CODE_BUFFER_SEED = "buffer"
```

### `CODE_SEED`

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

```typescript theme={null}
CODE_SEED = "code"
```

### `POT_SEED`

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

```typescript theme={null}
POT_SEED = "pot"
```

### `EXECUTION_FEE_SEED`

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

```typescript theme={null}
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`.

```typescript theme={null}
GROWTH_STEP = 10240
```

### `MAX_CODE_LEN`

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

```typescript theme={null}
MAX_CODE_LEN = 1048576
```

### `MAX_POT_LEN`

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

```typescript theme={null}
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.

```typescript theme={null}
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.

```typescript theme={null}
BPF_LOADER_UPGRADEABLE: Address
```

### `KitchenPda`

*Interface* · `sdk/dist/svm/kitchen.d.ts`

```typescript theme={null}
export interface KitchenPda {
    address: Address;
    bump: number;
}
```

### `CreatePotInput`

*Interface* · `sdk/dist/svm/kitchen.d.ts`

```typescript theme={null}
export interface CreatePotInput {
    kitchen: Address;
    owner: Address;
    engineProgram: Address;
    pot: Address;
    salt: Uint8Array;
    space: number;
}
```

### `ClosePotInput`

*Interface* · `sdk/dist/svm/kitchen.d.ts`

```typescript theme={null}
export interface ClosePotInput {
    kitchen: Address;
    owner: Address;
    engineProgram: Address;
    pot: Address;
    salt: Uint8Array;
}
```

### `CookInput`

*Interface* · `sdk/dist/svm/kitchen.d.ts`

```typescript theme={null}
export interface CookInput {
    kitchen: Address;
    owner: Address;
    engineProgram: Address;
    potSalt: Uint8Array;
    pot: Address;
    feeConfig: Address;
    bytecode: Uint8Array;
    maxExecutionFee: bigint;
    feePayer?: Address;
    tail?: readonly TailAccount[];
}
```

### `CookFromAccountInput`

*Interface* · `sdk/dist/svm/kitchen.d.ts`

```typescript theme={null}
export interface CookFromAccountInput {
    kitchen: Address;
    owner: Address;
    codeBuffer: Address;
    code: Address;
    engineProgram: Address;
    potSalt: Uint8Array;
    pot: Address;
    feeConfig: Address;
    pin?: Uint8Array;
    maxExecutionFee: bigint;
    feePayer?: Address;
    tail?: readonly TailAccount[];
}
```

### `CodeBufferAccounts`

*Interface* · `sdk/dist/svm/kitchen.d.ts`

```typescript theme={null}
export interface CodeBufferAccounts {
    kitchen: Address;
    owner: Address;
    codeBuffer: Address;
    code: Address;
}
```

### `ExecutionFeeAdminInput`

*Interface* · `sdk/dist/svm/kitchen.d.ts`

The three fee instructions authorize against the kitchen's LIVE upgrade authority, read from its
`ProgramData` - so the party that can replace the code is the party that can price it, and an
immutable kitchen has a frozen fee and an uncollectable balance. Each therefore takes the kitchen
program and its `ProgramData` as accounts; the constraint links the two, so a foreign program's
`ProgramData` cannot be substituted.

```typescript theme={null}
export interface ExecutionFeeAdminInput {
    kitchen: Address;
    authority: Address;
    programData: Address;
    feeConfig: Address;
}
```