> ## 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: the declaration and description of each of the 39 exports of @eco-incorp/sauce/svm.

`@eco-incorp/sauce/svm` is the Solana side: the client (`createSauceSvmClient`), clusters, PDAs, account resolution against the compiler's account manifest, Kitchen and engine instructions, transactions and sending, token accounts, and compute planning for `@sauce/router`'s Solana venues. `@eco-incorp/sauce/svm/engine` exports the engine's wire format and instruction builders, `@eco-incorp/sauce/svm/verify` verifies settle programs and engine CPI data, and `@eco-incorp/sauce/svm/engine-artifacts` (Node only) returns file paths to the packaged engine and Kitchen binaries.

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

Generated from the type declarations of `@eco-incorp/sauce`.

### `derivePotPda`

*Function* · `@eco-incorp/sauce/svm`

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 (a hash, say) passes it directly.

```typescript theme={null}
export declare function derivePotPda(kitchen: Address, owner: Address, salt: Uint8Array): Promise<KitchenPda>;
```

### `deriveExecutionFeeConfigPda`

*Function* · `@eco-incorp/sauce/svm`

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>;
```

### `decodeExecutionFeeConfig`

*Function* · `@eco-incorp/sauce/svm`

The fee in an `ExecutionFeeConfig` account's data: 8 discriminator bytes, then the fee as a u64
LE - exactly 16 bytes, the length the engine requires too. Anything else throws: a lookalike
account is not a fee of zero.

```typescript theme={null}
export declare function decodeExecutionFeeConfig(data: Uint8Array): bigint;
```

### `fetchExecutionFee`

*Function* · `@eco-incorp/sauce/svm`

The Kitchen's execution fee in lamports, read from its `["execution_fee"]` config - what a cook
through the Kitchen and a direct engine cook both pay. Throws when the config is absent, is not
owned by `kitchen`, or does not decode: every cook is refused on chain then, so there is no fee to
report.

```typescript theme={null}
export declare function fetchExecutionFee(rpc: Rpc<GetAccountInfoApi>, kitchen: Address): Promise<bigint>;
```

### `deriveProgramDataPda`

*Function* · `@eco-incorp/sauce/svm`

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* · `@eco-incorp/sauce/svm`

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* · `@eco-incorp/sauce/svm`

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* · `@eco-incorp/sauce/svm`

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

### `buildClosePotInstruction`

*Function* · `@eco-incorp/sauce/svm`

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

### `buildCookInstruction`

*Function* · `@eco-incorp/sauce/svm`

Builds a Kitchen cook with the program in the instruction data. Include `buildHeapFramePrepend()` exactly once; omitting it makes the cook fail with `ProgramFailedToComplete`. Pot and code-buffer lifecycle instructions do not require it. The Pot account must match the supplied salt, and any Pot the program writes must also appear in the unsigned tail.

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

### `buildCookFromAccountInstruction`

*Function* · `@eco-incorp/sauce/svm`

`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* · `@eco-incorp/sauce/svm`

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* · `@eco-incorp/sauce/svm`

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* · `@eco-incorp/sauce/svm`

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

### `buildFinalizeCodeBufferInstruction`

*Function* · `@eco-incorp/sauce/svm`

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* · `@eco-incorp/sauce/svm`

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* · `@eco-incorp/sauce/svm`

`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* · `@eco-incorp/sauce/svm`

`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* · `@eco-incorp/sauce/svm`

`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* · `@eco-incorp/sauce/svm`

One entry of a program's own account tail, in the shape a kit `Instruction` carries.

```typescript theme={null}
export type TailAccount = AccountLookupMeta | AccountMeta;
```

### `KITCHEN_DISCRIMINATORS`

*Variable* · `@eco-incorp/sauce/svm`

Each Kitchen instruction's discriminator, by name: what tells an instruction read back what it is.

```typescript theme={null}
KITCHEN_DISCRIMINATORS: Readonly<Record<keyof typeof DISCRIMINATOR, Uint8Array>>
```

### `CODE_BUFFER_SEED`

*Variable* · `@eco-incorp/sauce/svm`

The kitchen's own `#[constant]`s, from the same IDL.

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

### `CODE_SEED`

*Variable* · `@eco-incorp/sauce/svm`

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

### `POT_SEED`

*Variable* · `@eco-incorp/sauce/svm`

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

### `EXECUTION_FEE_SEED`

*Variable* · `@eco-incorp/sauce/svm`

```typescript theme={null}
EXECUTION_FEE_SEED = "execution_fee"
```

### `GROWTH_STEP`

*Variable* · `@eco-incorp/sauce/svm`

One `grow_code_buffer` step: `MAX_PERMITTED_DATA_INCREASE`, the most a CPI-created account can
grow in a single instruction.

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

### `MAX_CODE_LEN`

*Variable* · `@eco-incorp/sauce/svm`

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

### `MAX_POT_LEN`

*Variable* · `@eco-incorp/sauce/svm`

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

### `svmRentExempt`

*Variable* · `@eco-incorp/sauce/svm`

Rent-exempt lamports for an account of `bytes` of data, at mainnet's rent: 3,480 lamports per
byte-year, two years, over the data and the 128 bytes every account carries.

```typescript theme={null}
svmRentExempt: (bytes: number) => bigint
```

### `SALT_BYTES`

*Variable* · `@eco-incorp/sauce/svm`

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* · `@eco-incorp/sauce/svm`

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* · `@eco-incorp/sauce/svm`

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

### `EXECUTION_FEE_CONFIG_DISCRIMINATOR`

*Variable* · `@eco-incorp/sauce/svm`

The Anchor account discriminator of `ExecutionFeeConfig`, `sha256("account:ExecutionFeeConfig") [..8]` - the release IDL's own, and the bytes the
engine's direct cooks check before trusting the account.

```typescript theme={null}
EXECUTION_FEE_CONFIG_DISCRIMINATOR: Uint8Array<ArrayBuffer>
```

### `CreatePotInput`

*Interface* · `@eco-incorp/sauce/svm`

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

### `ClosePotInput`

*Interface* · `@eco-incorp/sauce/svm`

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

### `CookInput`

*Interface* · `@eco-incorp/sauce/svm`

```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* · `@eco-incorp/sauce/svm`

```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* · `@eco-incorp/sauce/svm`

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

### `ExecutionFeeAdminInput`

*Interface* · `@eco-incorp/sauce/svm`

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;
}
```


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.