svm: Instructions

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

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

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.

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.

export declare function assertNoExecutePin(expectedSha256: Uint8Array | undefined): void;

`ExecuteInstructionInput`

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

export interface ExecuteInstructionInput {
    programId: Address;
    bytecode: Uint8Array;
    accounts: readonly ResolvedAccountMeta[];
}

`ExecuteFromAccountInstructionInput`

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

export interface ExecuteFromAccountInstructionInput {
    programId: Address;
    code: Address;
    accounts: readonly ResolvedAccountMeta[];
}

Sauce SDK

@eco-incorp/sauce

@eco-incorp/sauce-compiler

svm: Instructions

`buildExecuteInstruction`

`buildExecuteFromAccountInstruction`

`assertNoExecutePin`

`ExecuteInstructionInput`

`ExecuteFromAccountInstructionInput`

​buildExecuteInstruction

​buildExecuteFromAccountInstruction

​assertNoExecutePin

​ExecuteInstructionInput

​ExecuteFromAccountInstructionInput

`buildExecuteInstruction`

`buildExecuteFromAccountInstruction`

`assertNoExecutePin`

`ExecuteInstructionInput`

`ExecuteFromAccountInstructionInput`