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

# sauce verify

> Confirm that a payload or transaction runs the settle program the package ships before you sign or accept it. For integrators of the settle recipe.

`sauce verify` checks that a payload, a cook or a transaction carries the settle program the package ships, and prints the parameters it was given.

## Synopsis

```bash theme={null}
sauce verify <payload | calldata | tx-hash> [--pin <hash:bytes>]… [--engine <address>]… [--chain <slug|id>]
```

## Description

The **settle program** ships in the package as `@eco-incorp/sauce/recipes/settle.sauce.ts`. On an EVM chain it sweeps the Pot's entire balance of each listed token to one recipient, after checking that the balance of the first token is at least `minOut` (`0` turns that floor off). [Verification](https://docs.eco.com/sauce-sdk/typescript/verification.md) covers the same checks in TypeScript.

The command takes one of:

* a settle **payload**: the program followed by its ABI-encoded arguments;
* **`Pot.cook` calldata** that carries a settle payload;
* a **transaction hash**, with `--chain`: the transaction is fetched, and its cook is checked.

It checks the settle with the SDK's `validateSettleProgram`:

* the program must hash to the current pin, the 410-byte settle program the pinned compiler produces, or to a `--pin` you add;
* the arguments must be the one canonical encoding;
* a cook must name the released engine, or an `--engine` you add.

On success it prints the tokens, `minOut` and recipient. A rejection exits `1` with its code: one of the SDK's `SettleFailureCode` values, such as `PROGRAM_HASH` or `PROGRAM_TRUNCATED`, or `UNKNOWN_ENGINE`.

**On Solana**, give `--chain solana` and a transaction signature. A Solana settle has its floor and its split between the two token programs compiled into it, so give them with `--min-out` and `--spl-count`. The engine invocation the cook made is checked by the SDK's `verifySvmSettleExecution` against the settle recompiled for those values. A rejection is `NO_SETTLE` or `NOT_GENUINE`. The command checks a cook through the Kitchen; a settle cooked with `--via engine` is not one it checks.

**Other pins.** A payload with another hash or length is a different program and is rejected unless you accept it explicitly with `--pin <hash:bytes>`. Accept another pin only for a program you have decided to accept.

Verification identifies the program and decodes its arguments. It does not check the chain, the Pot the cook targets, or any other call in the same transaction or batch; those remain yours to check.

## Options

| Option | Description |
| - | - |
| `--pin <hash:bytes>` | Also accept this historical settle program, given as `keccak256:length` |
| `--engine <address>` | Also accept a cook on this engine, besides the released one |
| `--chain <slug\|id>` | The chain a transaction hash is on |
| `--min-out <amount>` | Solana: the floor the settle must enforce on its first escrow |
| `--spl-count <n>` | Solana: how many escrows the settle sweeps with its first token program |
| `--rpc-url <url>` | Your own RPC endpoint for the chain. Default: a built-in public one |
| `--config <file>` | A file of your own endpoints: `{ "rpcUrls": { "<chain id>": "<url>" } }` |
| `--offline` | Read no chain: no endpoint, built-in ones included |
| `--json` | Print one JSON object instead of text |
| `-h, --help` | Show the help |
| `--no-update-check` | Print no notice of a newer `sauce`, and read no registry for one |

## Output

With `--json`, a valid settle prints:

| Field | Contents |
| - | - |
| `valid` | `true` |
| `tokens` | The tokens the settle sweeps, in order |
| `floorToken` | The first token, whose balance `minOut` is checked against |
| `minOut` | The floor, in the first token's base units |
| `recipient` | Where every token goes |
| `programHash` | The keccak256 of the program |
| `engine` | For a cook, the engine it names |

A rejection prints `rejected (<CODE>): <reason>` and exits `1`. Exit code `2` is a usage error.

## Examples

### Verify a payload

This script builds a settle payload for 1 USDC on Base:

```ts settle-payload.mts theme={null}
import { SETTLE_PROGRAM, encodeSettleProgram } from "@eco-incorp/sauce/verify";

const payload = encodeSettleProgram(
  ["0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"], // Base USDC
  1_000_000n,
  "0x1111111111111111111111111111111111111111",
  SETTLE_PROGRAM,
);
console.log(payload);
```

```bash theme={null}
sauce verify $(node --experimental-strip-types settle-payload.mts) --json
```

```json theme={null}
{
  "valid": true,
  "tokens": ["0x833589fcd6edb6e08f4c7c32d4f71b54bda02913"],
  "floorToken": "0x833589fcd6edb6e08f4c7c32d4f71b54bda02913",
  "minOut": "1000000",
  "recipient": "0x1111111111111111111111111111111111111111",
  "programHash": "<program hash>"
}
```

### Verify a cook

`sauce tx` built this cook from the settle program the package ships, with `--args '["0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"]' 1000000 0x1111111111111111111111111111111111111111` on Base:

```bash theme={null}
sauce verify 0x<cook calldata> --json
```

```json theme={null}
{
  "valid": true,
  "tokens": ["0x833589fcd6edb6e08f4c7c32d4f71b54bda02913"],
  "floorToken": "0x833589fcd6edb6e08f4c7c32d4f71b54bda02913",
  "minOut": "1000000",
  "recipient": "0x1111111111111111111111111111111111111111",
  "programHash": "<program hash>",
  "engine": "<engine address>"
}
```

### Read a rejection

A cook of any other program is rejected. This is the cook of `pay.sauce.ts` from [`sauce inspect`](https://docs.eco.com/sauce-sdk/cli/inspect):

```bash theme={null}
sauce verify 0x<cook calldata>
```

```text theme={null}
rejected (PROGRAM_TRUNCATED): decodeSettleProgram: payload is 218 bytes, shorter than the 410-byte settle program
```

The command exits `1`.

### Accept a historical settle program

A payload built with the settle program of compiler 2.5 is rejected by default:

```bash theme={null}
sauce verify 0x<compiler 2.5 settle payload>
```

```text theme={null}
rejected (TOKENS_OFFSET): decodeSettleProgram: tokens pointer is 102620023567536966936345448835016621874639083536077733878070129376109831127040, not the canonical 96 — the token array must follow the head immediately
```

The decoder reads it at the current program's length, so the reason names the arguments rather than the program. With that program's pin from `SETTLE_WIRE`, given as its hash and its length in bytes, the same payload verifies:

```bash theme={null}
sauce verify 0x<compiler 2.5 settle payload> --pin <hash>:<bytes> --json
```

```json theme={null}
{
  "valid": true,
  "tokens": ["0x833589fcd6edb6e08f4c7c32d4f71b54bda02913"],
  "floorToken": "0x833589fcd6edb6e08f4c7c32d4f71b54bda02913",
  "minOut": "1000000",
  "recipient": "0x1111111111111111111111111111111111111111",
  "programHash": "<hash>"
}
```

## Next steps

* [Verification in TypeScript](https://docs.eco.com/sauce-sdk/typescript/verification.md): `validateSettleProgram`, historical pins and Solana account checks.
* [`sauce inspect`](https://docs.eco.com/sauce-sdk/cli/inspect): decode any cook, not only a settle.
* [Security considerations](https://docs.eco.com/sauce/security-considerations.md): what a verified program does and does not establish.


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