> ## 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: Instructions

> Instructions: the declaration and description of each of the 12 exports of @eco-incorp/sauce/svm, @eco-incorp/sauce/svm/engine.

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

### `buildExecuteInstruction`

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

Builds the engine execute instruction. The supplied account list defines the program's account indices. The first signer supplies the caller context (`ctx.msgSender()`); a list with no signer fails only if the program reads it. Include `buildHeapFramePrepend()` exactly once in the transaction.

```typescript theme={null}
export declare function buildExecuteInstruction({ programId, bytecode, accounts, }: ExecuteInstructionInput): Instruction;
```

### `buildExecuteFromAccountInstruction`

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

`executeFromAccount`: account 0 is the code, the caller's tail follows at its natural indices,
and the program is that account's data verbatim.

No payload beyond the discriminator. The pre-release engine took `[flags][pin][offset,len][args]`
so a caller could pin the staged bytes at execute time; the released engine has no such grammar
and the pin moved to the kitchen - `buildCookFromAccountInstruction`'s `pin` refuses unless the
staged bytes hash to it. Needs RequestHeapFrame, like `execute` - see `buildHeapFramePrepend`.

```typescript theme={null}
export declare function buildExecuteFromAccountInstruction({ programId, code, accounts, }: ExecuteFromAccountInstructionInput): Instruction;
```

### `assertNoExecutePin`

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

Rejects a would-be execute-time content pin, naming where the enforceable one lives.

Lives here because the reason is this module's: `executeFromAccount` above emits the discriminator
and nothing else, so a pin handed to a caller of it has no destination. The surfaces that used to
accept one - `StagedBufferRef.expectedSha256`, `SimulateStagedOpts.expectedSha256` - forwarded it
and dropped it while documenting it as engine-verified, which is the failure this converts into a
loud one.

```typescript theme={null}
export declare function assertNoExecutePin(expectedSha256: Uint8Array | undefined): void;
```

### `buildCookAndPayInstruction`

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

`cookAndPay` - the engine called directly, bytecode inline, paying the Kitchen's execution fee
itself: `[discriminator | max_execution_fee u64 LE | bytecode]`.

No Kitchen, so no Pot: nothing signs for one, and the program acts with the signatures the
transaction gave its tail - the wallet that signs is the authority a token transfer names. In
exchange the program's own CPIs start one level higher on the invoke stack than under a Kitchen
cook, which CPIs the engine.

Needs the same RequestHeapFrame as every cook - see `buildHeapFramePrepend`.

```typescript theme={null}
export declare function buildCookAndPayInstruction({ engineProgram, bytecode, tail, ...payment }: CookAndPayInput): Instruction;
```

### `buildCookAndPayFromAccountInstruction`

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

`cookAndPayFromAccount` - the staged direct cook: `[discriminator | max_execution_fee u64 LE]`,
the program being the code account's data.

**Unpinned.** The engine checks nothing about the code account - not its owner, not a finalized
flag, not a digest - and runs it with the tail's signatures. Whoever can change those bytes before
the transaction lands chooses what the signer's authority is used for. Prefer
`buildCookAndPayFromAccountPinnedInstruction` unless the account is one only the signer controls.

```typescript theme={null}
export declare function buildCookAndPayFromAccountInstruction({ engineProgram, code, tail, ...payment }: CookAndPayFromAccountInput): Instruction;
```

### `buildCookAndPayFromAccountPinnedInstruction`

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

Builds `cookAndPayFromAccountPinned`, the pinned staged direct cook: `[discriminator | max_execution_fee u64 LE | expected_sha256]`. It verifies the code account's SHA-256 digest before charging the fee and executes exactly those bytes. A mismatch fails with `CodeHashMismatch`.

```typescript theme={null}
export declare function buildCookAndPayFromAccountPinnedInstruction({ expectedSha256, engineProgram, code, tail, ...payment }: CookAndPayFromAccountPinnedInput): Instruction;
```

### `ExecuteInstructionInput`

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

```typescript theme={null}
export interface ExecuteInstructionInput {
    programId: Address;
    bytecode: Uint8Array;
    accounts: readonly ResolvedAccountMeta[];
}
```

### `ExecuteFromAccountInstructionInput`

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

```typescript theme={null}
export interface ExecuteFromAccountInstructionInput {
    programId: Address;
    code: Address;
    accounts: readonly ResolvedAccountMeta[];
}
```

### `DirectCookPayment`

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

What a direct cook pays with - the three accounts the engine reads LAST and strips before the
program sees its tail, so bytecode indices and `MSG_SENDER` keep their meanings.

```typescript theme={null}
export interface DirectCookPayment {
    feeConfig: Address;
    feePayer: Address;
    maxExecutionFee: bigint;
}
```

### `CookAndPayInput`

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

```typescript theme={null}
export interface CookAndPayInput extends DirectCookPayment {
    engineProgram: Address;
    bytecode: Uint8Array;
    tail?: readonly DirectTailAccount[];
}
```

### `CookAndPayFromAccountInput`

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

```typescript theme={null}
export interface CookAndPayFromAccountInput extends DirectCookPayment {
    engineProgram: Address;
    code: Address;
    tail?: readonly DirectTailAccount[];
}
```

### `CookAndPayFromAccountPinnedInput`

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

```typescript theme={null}
export interface CookAndPayFromAccountPinnedInput extends CookAndPayFromAccountInput {
    expectedSha256: Uint8Array;
}
```


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