svm: Account resolution

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

`resolveAccounts`

Function · sdk/dist/svm/resolve.d.ts Resolves an AccountManifest into ordered account metas: metas[i] is user-account index i of the execute instruction (inline: instruction account i; staged: i + 1, after the buffer). The base role comes from the slot’s requires; the resolution entry’s signer flag then replaces it (see AccountResolution), and a TransactionSigner or the reserved PAYER_REF sets it. An attached TransactionSigner rides on the meta so the transaction builder signs with it. Duplicate addresses across refs are fine - Solana dedupes at message compile. A remaining entry is a POSITION, not an account: it marks where the caller’s own variable-length tail begins, so resolution stops there and the caller appends its tail itself. It must be the LAST entry, and one that is not throws - stopping early would drop the slots after it from metas and shift the index of every account the caller then appends. MSG_SENDER/TX_ORIGIN is the first in-list signer, resolved LAZILY by the engine (NoSigner only when the program actually reads the sender) - so no signer is auto-appended; a MSG_SENDER-reading program whose manifest declares no signer slot passes appendPayerSigner: true.

export declare function resolveAccounts(manifest: AccountManifest, resolution: AccountResolution, payer: Address, { appendPayerSigner }?: ResolveAccountsOptions): ResolvedAccountMeta[];

`AccountResolution`

Interface · sdk/dist/svm/resolve.d.ts Maps each declared slot of the compiler’s AccountManifest to a concrete address. signer REPLACES the manifest’s requirement rather than only raising it: omit it to keep the manifest’s own value, true to make a non-signer slot sign, and false to attach a slot the program treats as a signer WITHOUT a transaction signature - which is what a PDA the program signs for via invoke_signed needs. Pass the TransactionSigner itself to also sign with it (required for any signer ref other than the reserved fee-payer ref - the send layer has no other way to obtain that signature). The two sides describe different things: the manifest states what the PROGRAM requires of the slot, this states what the TRANSACTION provides.

export interface AccountResolution {
    [ref: string]: Address | {
        address: Address;
        signer?: boolean | TransactionSigner;
    };
}

`PAYER_REF`

Variable · sdk/dist/svm/resolve.d.ts Reserved ref: resolves to the fee payer with signer:true (use it when bytecode reads MSG_SENDER). A resolution entry under this key is a conflict and throws - rename the plan ref if it must resolve to another address.

PAYER_REF = "payer"

`ResolveAccountsOptions`

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

export interface ResolveAccountsOptions {
    appendPayerSigner?: boolean;
}

`ResolvedAccountMeta`

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

export interface ResolvedAccountMeta {
    address: Address;
    role: AccountRole;
    signer?: TransactionSigner;
}

Sauce SDK

@eco-incorp/sauce

@eco-incorp/sauce-compiler

svm: Account resolution

`resolveAccounts`

`AccountResolution`

`PAYER_REF`

`ResolveAccountsOptions`

`ResolvedAccountMeta`

​resolveAccounts

​AccountResolution

​PAYER_REF

​ResolveAccountsOptions

​ResolvedAccountMeta

`resolveAccounts`

`AccountResolution`

`PAYER_REF`

`ResolveAccountsOptions`

`ResolvedAccountMeta`