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

> Intents: 14 exports of the svm module of @eco-incorp/sauce, including decodePortalCalldataWithAccounts, encodePortalCalldataWithAccounts, extractSvmSettleFromCalls, extractSvmSettleFromIntent, PortalAccountMeta, PortalCalldataWithAccounts.

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

### `decodePortalCalldataWithAccounts`

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

Decodes a Portal `CalldataWithAccounts` envelope (the form of every SVM `route.calls[].data`) into the
wrapped instruction data and its account list. Accepts the envelope as raw bytes, `0x`-hex (the viem
`Hex` a call carries), or base64. Throws on a truncated / malformed envelope.

```typescript theme={null}
export declare function decodePortalCalldataWithAccounts(data: BytesInput): PortalCalldataWithAccounts;
```

### `encodePortalCalldataWithAccounts`

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

Encodes a Portal `CalldataWithAccounts` envelope - the exact inverse of
`decodePortalCalldataWithAccounts`, sharing its codec byte-for-byte (both are built from the
same field list above), so encoder and decoder cannot drift apart. This is what a route `Call.data`
for a staged SVM Sauce execution looks like on the wire.

```typescript theme={null}
export declare function encodePortalCalldataWithAccounts(input: PortalCalldataWithAccountsInput): `0x${string}`;
```

### `extractSvmSettleFromCalls`

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

Return the first recognized raw-engine settlement in Portal envelopes, or null.
Staged identity depends on each call's independently trusted pin. The caller must also
require a readable target matching v12SvmEngineProgramId(), validate gate/account roles,
and inspect every other call. Kitchen cook envelopes are not handled here.

```typescript theme={null}
export declare function extractSvmSettleFromCalls(calls: readonly SvmIntentCallLike[], options: ExtractSvmSettleOptions): ExtractedSvmSettle | null;
```

### `extractSvmSettleFromIntent`

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

Inspect the route's calls with the same trust boundaries as extractSvmSettleFromCalls.

```typescript theme={null}
export declare function extractSvmSettleFromIntent(intent: SvmIntentLike, options: ExtractSvmSettleOptions): ExtractedSvmSettle | null;
```

### `PortalAccountMeta`

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

One attached account, as the Portal `SerializableAccountMeta` struct serializes it.

```typescript theme={null}
export interface PortalAccountMeta {
    pubkey: Address;
    isSigner: boolean;
    isWritable: boolean;
}
```

### `PortalCalldataWithAccounts`

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

The decoded Portal `CalldataWithAccounts` envelope: the wrapped CPI instruction data and its accounts.

```typescript theme={null}
export interface PortalCalldataWithAccounts {
    instructionData: Uint8Array;
    accountCount: number;
    accounts: PortalAccountMeta[];
}
```

### `PortalCalldataWithAccountsInput`

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

Input to `encodePortalCalldataWithAccounts` - the mirror of `PortalCalldataWithAccounts`.

```typescript theme={null}
export interface PortalCalldataWithAccountsInput {
    instructionData: Uint8Array;
    accounts: readonly PortalAccountMeta[];
    accountCount?: number;
}
```

### `BytesInput`

*Type* · `sdk/dist/svm/intent.d.ts`

An opaque byte payload: `Uint8Array` as-is; a `0x`-prefixed hex string (the viem `Hex` form
`route.calls[].data` uses); or a base64 string (the Solana convention) for anything not 0x-prefixed.
A BARE STRING IS BASE64 HERE. For an address, use `UniversalAddressInput` - same three carriage
forms, but a bare string there is base58, and the two must never be handed to the same reader.

```typescript theme={null}
export type BytesInput = Uint8Array | string;
```

### `UniversalAddressInput`

*Type* · `sdk/dist/svm/intent.d.ts`

A 32-byte universal address, in the forms one arrives in: raw bytes, `0x`-hex (what
`buildSauceSvmCall` emits into `route.calls[].target`), or the base58 program id itself. Deliberately
NOT `BytesInput`, whose bare-string form is base64 - only a branded `Address` may be spent as the
base58 form, so an unvalidated `string` does not typecheck and the two encodings cannot be confused
at a call site.

```typescript theme={null}
export type UniversalAddressInput = Uint8Array | `0x${string}` | Address;
```

### `SvmIntentCallLike`

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

An intent call, duck-typed: only `data` (the Portal envelope) is required; `target` (the callee
program) is carried through when present. Matches eco-solver's `Call` / persisted `IntentCall` (both
carry `data` as viem `Hex`).

```typescript theme={null}
export interface SvmIntentCallLike {
    data: BytesInput;
    target?: UniversalAddressInput;
    pin?: BytesInput;
}
```

### `SvmIntentLike`

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

An intent, duck-typed to just the SVM route calls this reads.

```typescript theme={null}
export interface SvmIntentLike {
    route: {
        calls: readonly SvmIntentCallLike[];
    };
}
```

### `ExtractSvmSettleOptions`

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

```typescript theme={null}
export interface ExtractSvmSettleOptions extends SvmSettleExpectation {
    wireFormat?: SvmExecutionWireFormat;
    bytecode?: BytesInput;
}
```

### `ExtractedSvmSettle`

*Type* · `sdk/dist/svm/intent.d.ts`

The extracted settle for a call: the full `verifySvmSettleExecution` verdict (resolved accounts and
the `genuine` / `verifiedBy` genuineness fields), extended with the call's index and callee.

```typescript theme={null}
export type ExtractedSvmSettle = SvmSettleExecutionVerification & {
    callIndex: number;
    target: SvmSettleTarget;
};
```

### `SvmSettleTarget`

*Type* · `sdk/dist/svm/intent.d.ts`

The callee of an extracted settle - three states a caller must keep apart. `program`: the call's
`target`, resolved to a program id to compare against the engine you trust. `absent`: the call carried
no `target` at all. `unreadable`: it carried one that is not a 32-byte universal address, so there is
nothing to compare it to.

Collapsing `unreadable` into `absent` is the bypass this shape exists to prevent. A caller may
legitimately skip the callee check for a call that named no callee; skipping it because the callee it
named was garbage accepts a settle whose callee is unknown. Only `program` is ever safe to clear.

```typescript theme={null}
export type SvmSettleTarget = {
    readonly kind: "program";
    readonly address: Address;
} | {
    readonly kind: "absent";
} | {
    readonly kind: "unreadable";
    readonly reason: string;
};
```