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

> Print the unsigned cook transaction, or the plan that deploys the Pot first, for any wallet to sign

`sauce tx` compiles a program and prints the unsigned transaction that runs it on a Pot, for a wallet or signer of your choice to sign.

## Synopsis

```bash theme={null}
sauce tx <file | -> --chain <slug|id> (--owner <address> | --pot <address>) [options]
sauce tx <file | -> --chain solana --owner <pubkey> [--account NAME=<value>]… [options]
```

## Description

`sauce tx` compiles the file (a `.sauce.ts` program or an [actions document](https://docs.eco.com/sauce-sdk/cli/actions.md)) and prints the [cook](https://docs.eco.com/sauce/cook.md) unsigned, as JSON: `{ chainId, to, data, value }`, where `to` is the Pot and `data` is `Pot.cook(engine, program ++ arguments)`. It never takes a key and signs nothing.

The value is `--value`, else the Kitchen's execution fee read from the chain. Reading the fee also reads the Pot.

* **A Pot with no code yet.** The command prints a plan instead, `{ chainId, pot, transactions }`: `Kitchen.deployPot` first (marked `deploysPot`; any account may send it), then the cook. Send them in that order.
* **Gas.** Each transaction of a plan carries a `gas` limit the command simulated: the cook's is estimated as if the transactions before it had landed, with 30% room. When the cook would revert on the chain as it is (an unfunded Pot), the transactions carry no `gas`, and stderr says why.
* **Batches.** Each transaction is in the shape a wallet's send call takes (`value` and `gas` in hex), and `sendCalls` holds all of them as one batch, for a wallet that sends a batch.
* **`--fund TOKEN:amount`** plans a plain transfer of each token from the owner into the Pot before the cook. With an endpoint, an EVM Pot that has no code yet is deployed first, so the transfer comes after the deployment. With `--offline` the command cannot check whether the Pot is deployed, and the plan has no deployment step: deploy the Pot first. `ETH:<amount>` adds to the cook's value instead. Sent as one batch, a smart wallet deploys, funds and cooks with one approval, or nothing happens. [Funding a Pot](https://docs.eco.com/sauce-sdk/cli/funding.md) covers the amount syntax.
* **`--format cast`** prints each transaction as a `cast send` line with placeholders.

What must hold for the transaction to land goes to stderr: on an EVM chain, the Pot funded after its deployment, and the cook sent from its owner (`cook()` is `onlyOwner`). On Arc and Arc Testnet, stderr also says that a transaction is included only with a `maxFeePerGas` of at least 20 gwei, the chain's minimum base fee; the printed transactions carry no fee fields.

**On Solana** it prints `{ chain, via, feePayer, pot, fee, maxExecutionFee, createsPot, transaction }`: the Kitchen's cook as a base64 transaction signed by no one, for `--owner` to sign, or with `--via engine` the engine's own paid cook, with no Pot. A Pot not created yet is created by the same transaction, ahead of the cook (`createsPot`). The command reads the cluster for the blockhash and the fee. [Solana](https://docs.eco.com/sauce-sdk/cli/solana.md) covers the account forms and the plan a cook too large for one transaction becomes.

`sauce tx` prints a transaction only on a supported chain: Ethereum, Base, Arc and Solana, and the testnets Arc Testnet, Base Sepolia, Ethereum Sepolia, Solana Devnet and Solana Testnet. On a preview chain it is refused before anything is read, with a message that names the supported chains and how to request the refused one.

## Prerequisites

On an EVM chain, the release's engine must be deployed on the chain for the cook to run. `sauce pot --chain <chain> --owner <address>` reports whether it is.

## Options

| Option | Description |
| - | - |
| `--chain <slug\|id>` | The chain the program runs on (`base`, `8453`, `solana`) |
| `--target <evm\|svm>` | Checked against the chain. `svm` with no `--chain` means Solana |
| `--source-dir <dir>` | The directory the program's relative imports resolve from. Default: beside the file; for stdin, the current directory |
| `--owner <address>` | The Pot's owner, which derives the Pot with the salt (default salt 0) |
| `--salt <label>` | Name one of the owner's Pots: the salt is `keccak256(label)` |
| `--salt-hex <bytes32>` | Give the Pot's salt exactly |
| `--args-json <json\|file>` | `main`'s arguments as one JSON array, inline or in a file |
| `--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. `--value` is then required |
| `--format <json\|cast>` | `json` (default), or a `cast send` line with placeholders |
| `-h, --help` | Show the help |
| `--no-update-check` | Print no notice of a newer `sauce`, and read no registry for one |
| `--args <value>…` | `main`'s arguments in order: an integer as digits, a negative one too (`-5`), JSON for an array or a tuple. Put `--` before a word that starts like a flag |

### EVM chains only

| Option | Description |
| - | - |
| `--pot <address>` | The Pot itself, by address |
| `--value <wei>` | The cook's value: the Kitchen fee plus native coin the program spends. Default: the fee, read from the chain |
| `--fund <TOKEN:amount>` | Transfer tokens from the owner into the Pot before the cook: `USDC:1.5` (whole tokens). `ETH:0.01` adds to the cook's value |

### Solana only

| Option | Description |
| - | - |
| `--account NAME=<address>` | An account `main` takes, by name: an address, `pot`, `owner`, `authority` (the account that signs the engine call: the Pot, or the owner with `--via engine`), `system` (the System Program), `pot:USDC` (the Pot's USDC account), `@to:USDC` (the USDC account of `main`'s argument `to`), `mint:USDC`, `program:USDC` (its token program), `slot:@pool:USDC.vaultA` (a pool's account) or `pda:<program>:<seeds>`. Accounts the token methods and venue namespaces add, and those a program derives where it uses them (`Account.pda(…)`), need no flag. A slot derived from the Pot, the owner or the authority takes only the account its derivation gives |
| `--accounts <json\|file>` | The accounts `main` takes as one JSON object of name to value, in `--account`'s forms, inline or in a file |
| `--via <kitchen\|engine>` | The Kitchen's cook on the Pot (default), or the engine's own cook, with no Pot |
| `--max-execution-fee <lamports>` | Refuse a cook whose execution fee is above this |
| `--lookup-table <address>` | An address lookup table holding the cook's accounts |

### Low-level options

`--help` lists these apart, with the note "a program's inputs are main's parameters, given with --args".

| Option | Description |
| - | - |
| `--define NAME=VALUE` | A compile-time value for a name the program leaves undeclared: an integer, `0x` hex, `true` or `false`; base58 on Solana |
| `--defines <file.json>` | Compile-time values from a JSON object of name to value. `--define` takes precedence |

## Output

stdout carries the JSON (there is no `--json` flag: JSON is the default format), or the `cast send` lines with `--format cast`. stderr carries the Pot and its owner, the conditions for the transactions to land, and notes on gas and balances.

| Field | Contents |
| - | - |
| `chainId` | The chain id |
| `to`, `data`, `value` | The cook, when the Pot exists or the chain is not read |
| `pot`, `transactions` | The plan, when the Pot has no code yet or `--fund` adds transfers: each with `what`, `chainId`, `to`, `data`, `value`, and `gas` where estimated; the deployment is marked `deploysPot` |
| `sendCalls` | `{ chain, calls }`: every transaction as one batch |

Exit codes: `0` when the transaction or plan is printed, `1` on a preview chain or a compile failure, `2` for a usage error.

## Examples

The examples build the cook of [`pay.sauce.ts`](https://docs.eco.com/sauce-sdk/cli/compile#compile-for-base) on Base for the arbitrary owner `0x1111…1111`, whose Pot has no code on Base. Calldata is cut short, and the Kitchen's address is shown as `<kitchen address>` (see [deployments](https://docs.eco.com/sauce-sdk/reference/deployments.md)).

### Build the plan for a Pot with no code

```bash theme={null}
sauce tx pay.sauce.ts --chain base --owner 0x1111111111111111111111111111111111111111 \
  --args 0x2222222222222222222222222222222222222222 1000000
```

```json theme={null}
{
  "chainId": 8453,
  "pot": "0x6c9175d272D49e6C8C139A3FE6BC6fDb422eD3Fe",
  "transactions": [
    {
      "what": "Kitchen.deployPot(0x1111111111111111111111111111111111111111, 0x0000000000000000000000000000000000000000000000000000000000000000): deploys the Pot, which has no code yet",
      "deploysPot": "0x6c9175d272D49e6C8C139A3FE6BC6fDb422eD3Fe",
      "chainId": 8453,
      "to": "<kitchen address>",
      "data": "0xff9763ac…",
      "value": "0x0"
    },
    {
      "what": "cook on Pot 0x6c9175d272D49e6C8C139A3FE6BC6fDb422eD3Fe",
      "chainId": 8453,
      "to": "0x6c9175d272D49e6C8C139A3FE6BC6fDb422eD3Fe",
      "data": "0xb38dbf14…",
      "value": "0x367e69a4b6e"
    }
  ],
  "sendCalls": {
    "chain": "base",
    "calls": [
      { "to": "<kitchen address>", "value": "0x0", "data": "0xff9763ac…" },
      { "to": "0x6c9175d272D49e6C8C139A3FE6BC6fDb422eD3Fe", "value": "0x367e69a4b6e", "data": "0xb38dbf14…" }
    ]
  }
}
```

stderr explains why the cook carries no `gas`:

```text theme={null}
The cook is given no gas: simulated after the deployment, on the chain as it is, it would revert (the program threw "not enough USDC"). Fund the Pot first (its address takes tokens before it is deployed) and build it again for its gas, or sign the cook with a gas limit that has room, or once the deployment has landed: a signer's own estimate, taken while the Pot has no code, is far too low.
Send from 0x1111111111111111111111111111111111111111: cook() is onlyOwner.
```

On an EVM chain, fund the Pot once its deployment has landed, not before: until then its address is the Kitchen's prediction ([Funding a Pot](https://docs.eco.com/sauce-sdk/cli/funding.md)). With an endpoint, `--fund`, below, plans the transfer after the deployment and before the cook. With `--offline` the command cannot check whether the Pot is deployed, so the plan has no deployment step: deploy the Pot first. The note quoted above says the Pot's address takes tokens before it is deployed; follow this paragraph instead.

### Fund the Pot in the same batch

```bash theme={null}
sauce tx pay.sauce.ts --chain base --owner 0x1111111111111111111111111111111111111111 \
  --fund USDC:100 --args 0x2222222222222222222222222222222222222222 1000000
```

```json theme={null}
{
  "chainId": 8453,
  "pot": "0x6c9175d272D49e6C8C139A3FE6BC6fDb422eD3Fe",
  "transactions": [
    { "what": "Kitchen.deployPot(…): deploys the Pot, which has no code yet", "deploysPot": "0x6c9175d272D49e6C8C139A3FE6BC6fDb422eD3Fe", "chainId": 8453, "to": "<kitchen address>", "data": "0xff9763ac…", "value": "0x0", "gas": "0xd3b1f" },
    { "what": "transfer 100000000 USDC to the Pot", "chainId": 8453, "to": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", "data": "0xa9059cbb…", "value": "0x0", "gas": "0x13ba6" },
    { "what": "cook on Pot 0x6c9175d272D49e6C8C139A3FE6BC6fDb422eD3Fe", "chainId": 8453, "to": "0x6c9175d272D49e6C8C139A3FE6BC6fDb422eD3Fe", "data": "0xb38dbf14…", "value": "0x367e69a4b6e", "gas": "0x1bf56" }
  ],
  "sendCalls": { "chain": "base", "calls": [ … ] }
}
```

With the transfer planned first, the cook simulates and gets a gas limit, `0x1bf56` (114518): 88091 used, with 30% room.

### Build offline

```bash theme={null}
sauce tx pay.sauce.ts --chain base --owner 0x1111111111111111111111111111111111111111 \
  --value 0 --offline --args 0x2222222222222222222222222222222222222222 1000000
```

```json theme={null}
{
  "chainId": 8453,
  "to": "0x6c9175d272D49e6C8C139A3FE6BC6fDb422eD3Fe",
  "data": "0xb38dbf14…",
  "value": "0x0",
  "sendCalls": {
    "chain": "base",
    "calls": [{ "to": "0x6c9175d272D49e6C8C139A3FE6BC6fDb422eD3Fe", "value": "0x0", "data": "0xb38dbf14…" }]
  }
}
```

With no endpoint the command cannot see whether the Pot exists, so it prints the cook alone and says on stderr that the Pot must be deployed and funded. A cook with a value below the Kitchen's fee reverts on chain.

### Refuse a preview chain

```bash theme={null}
sauce tx pay.sauce.ts --chain arbitrum --owner 0x1111111111111111111111111111111111111111 \
  --args 0x2222222222222222222222222222222222222222 1000000
```

```text theme={null}
sauce tx: building the cook transaction is refused: it involves arbitrum (Arbitrum One, chain id 42161), a preview chain. The sauce command and its MCP server build and send transactions only on Ethereum, Base, Arc and Solana, and the testnets Arc Testnet, Base Sepolia, Ethereum Sepolia, Solana Devnet and Solana Testnet. On a preview chain they build and send none. A program still compiles there and globals, price, pools and pot's prediction still read; simulate runs wherever the release is deployed on the chain, and says so where it is not.
To ask for Arbitrum One: …
```

The command exits `1`.

## Next steps

* [`sauce send`](https://docs.eco.com/sauce-sdk/cli/send): broadcast what your signer signed.
* [`sauce run`](https://docs.eco.com/sauce-sdk/cli/run): compile, sign and send in one command.
* [`sauce simulate`](https://docs.eco.com/sauce-sdk/cli/simulate): the same cook, simulated.
* [External wallets](https://docs.eco.com/sauce-sdk/mcp/external-wallets.md): signing outside the `sauce` command.
* [Funding a Pot](https://docs.eco.com/sauce-sdk/cli/funding.md): `--fund` and the amount syntax.


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