sauce run compiles a program, builds the cook on the signer’s Pot, simulates it, signs it, sends it and waits for the receipt.
Synopsis
Description
sauce run compiles the file (a .sauce.ts program or an actions document) and builds the cook on the signer’s Pot, or on the Pot --pot names. The signer is the owner. It simulates the cook first and sends nothing when the simulation fails: it prints the decoded reason and exits 1. It then signs the cook, sends it, waits for the receipt and prints the transaction hash, status and gas used, the explorer and trace links, what it cost and what moved, or the decoded reason it reverted (exit 1).
The cook’s value defaults to the Kitchen’s execution fee, read from the chain. When the program also spends native coin, pass --value with the fee plus what it spends; a --value below the fee is refused.
The signer is one of --wallet (a wallet made with sauce wallet), --keystore, --private-key or, on Solana, --keypair. A wallet’s <name>.policy.json, when present, limits what each transaction moves (Wallets and policy).
What it sends before the cook
You do not deploy the Pot as a separate step: a run deploys it when it first needs it, before it moves any--fund tokens in. On an EVM chain, if you send tokens to the Pot yourself instead, deploy it first with sauce pot --deploy: until it is deployed, its address follows the Kitchen (Funding a Pot). Each transaction the run sends before its cook is a transaction of its own, and the run asks you to approve it at the terminal first:
- deploying your Pot, when it has no code yet (asked as
[deploy/cancel], with its gas); - approving Permit2 for a token
--fundpulls, the first time (--fund-mode permit2); a wallet whose policy limits the token refuses it; - approving the Pot for the amount
--fundpulls (--fund-mode allowance).
-y (--yes, or its older name --auto-approve) approves each of them without asking and prints auto-approved: <action> for each. With no terminal to ask on (CI, a pipe, a program read from stdin with no terminal), or with --json, the run sends nothing until they are approved: it names each approval it needs and --yes, and exits 1.
On Solana a missing Pot is created in the cook’s own transaction, with nothing asked, when the two fit in one transaction. Otherwise it is asked for like the rest.
On an EVM chain the run holds its whole plan to the Pot guard before it sends the first of these: the Pot must be where the deployed Kitchen puts it, or a deployed Pot the Kitchen created, and a step the guard refuses stops the run before anything is sent. It checks the rest of the plan again before each transaction, since an answer at the terminal can take a while.
Funding
--fund TOKEN:amount gets tokens from your wallet into the Pot in the same cook: the program is wrapped so it first pulls each amount, then runs, then, with --sweep, returns what is left. Funding a Pot covers the amount syntax and each --fund-mode.
Solana
On Solana the run signs with--keypair (or a Solana wallet) and reads the Kitchen’s fee from the cluster. A missing Pot, and a pot:<token> or owner:<token> account the cook names that the cluster does not have yet, are created, the owner paying the rent. A program too large for one transaction is staged in a code buffer first and the buffer is closed after the cook. The cook signs the fee it read as its maximum execution fee; --max-execution-fee refuses a higher fee before anything is sent. A failure prints the program logs. Solana covers --via engine and the account forms.
Supported chains
sauce run sends 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 or signed, with a message that names the supported chains and how to request the refused one. sauce compile works there, and sauce simulate runs wherever the release’s engine and Kitchen are deployed.
Prerequisites
- A signer that holds the chain’s native coin for gas and the Kitchen’s fee.
- On an EVM chain, the release’s engine deployed on the chain.
sauce pot --chain <chain> --owner <address>reports whether it is.
Options
EVM chains only
Solana only
Low-level options
--help lists these apart, with the note “a program’s inputs are main’s parameters, given with —args”.
Output
On success, stdout carries the cook’s hash, status, gas used and block, its explorer and trace links, its cost (gas, an OP-stack chain’s L1 data fee, and the value it carried), and what moved. Questions, notes andauto-approved: lines go to stderr. With --json, stdout carries one JSON object instead.
Exit codes: 0 when the cook lands and succeeds; 1 when the simulation or the cook reverts, when an approval is needed and was not given, or on a preview chain; 2 for a usage error.
Examples
The examples use a throwaway wallet,docs, made in a scratch directory with sauce wallet new docs --wallets ./wallets --password-file ./pw.txt. It holds nothing, and nothing in these examples is sent.
Stop where approval is needed
With no terminal to ask on, the run names the transaction it would send before the cook, and sends nothing:1. With --json, the same run prints this run needs an approval, and --json asks nothing, writes nothing to stdout and exits 1. Without --password-file or another password source, the run stops before that, with no terminal to ask for the password on: pass --password-env <NAME>, --password-file <path> or --password-command <command>, and exits 2.
Refuse a funded run the wallet cannot pay
1.
Refuse a preview chain
1 before it reads the chain or the wallet’s key.
Next steps
sauce simulate: the same cook, with no key.sauce txandsauce send: sign with another signer.- Funding a Pot:
--fund,--fund-modeand--sweep. sauce walletand Wallets and policy: signers and spending limits.sauce pot: the Pot’s address and the Pot store.