> ## 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: 5 exports of the svm module of @eco-incorp/sauce, including buildExecuteInstruction, buildExecuteFromAccountInstruction, assertNoExecutePin, ExecuteInstructionInput, ExecuteFromAccountInstructionInput.

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

### `buildExecuteInstruction`

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

Builds the engine execute instruction. The account list IS the user-account
index space: accounts\[i] is user index i (no fixed prefix - interpreter
memory lives in the transaction's heap frame, not accounts). MSG\_SENDER is
the first in-list signer, resolved LAZILY: a signerless list is valid unless
the program reads MSG\_SENDER/TX\_ORIGIN (NoSigner then). Every transaction
carrying this instruction MUST also carry RequestHeapFrame(262144) - see
buildHeapFramePrepend.

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

### `buildExecuteFromAccountInstruction`

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

`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* · `sdk/dist/svm/instructions.d.ts`

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

### `ExecuteInstructionInput`

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

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

### `ExecuteFromAccountInstructionInput`

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

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