> ## 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. # Solana from the CLI > What differs when the sauce commands target Solana instead of an EVM chain, for anyone running programs on Solana. On Solana the `sauce` commands are the ones you use on Base: `compile`, `simulate`, `tx`, `run`, `pot`. This page covers what differs: the accounts a transaction lists, the two ways a cook reaches the engine, the execution fee, programs too large for one transaction, Token-2022 tokens, and the accounts a run leaves open. ## Prerequisites * The `sauce` command: `npm install -g @eco-incorp/sauce` ([Installation](https://docs.eco.com/sauce-sdk/installation.md)). * A Solana signer for `run`: a Solana wallet ([`sauce wallet new --solana`](https://docs.eco.com/sauce-sdk/cli/wallet)) or a keypair file for `--keypair`. `compile` and `tx` need only the owner's public key. * For `simulate` and `run`, the release's engine must be deployed on the cluster: `sauce pot --chain solana --owner ` reports whether it is. `sauce tx` on Solana does not check for the engine, as it does on an EVM chain: without it, its simulation of the cook fails with `AccountNotFound` and it builds no cook. ## Accounts A Solana transaction lists every account it touches. For most programs you pass none: compiling adds each account the program needs to `main`, with how to derive it, and `simulate`, `tx` and `run` derive each one from the owner, the Pot and `main`'s arguments. This program pays PYUSD with the token method: ```ts pay-pyusd.sauce.ts theme={null} // Pays PYUSD, a Token-2022 mint, from the Pot to a recipient. // sauce tx pay-pyusd.sauce.ts --chain solana --owner --args // to: Address, the recipient's wallet // amount: Uint256, PYUSD in base units (1000000 is 1 PYUSD) function main(to: Address, amount: Uint256) { PYUSD.transfer(to, amount); } ``` `sauce compile --json` lists the accounts in its `manifest`, in order, each with its role and derivation: ```bash theme={null} sauce compile pay-pyusd.sauce.ts --chain solana --json ``` ```json theme={null} { "manifest": { "accounts": [ { "kind": "slot", "index": 0, "name": "token2022Program", "requires": "readonly", "derive": "TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb" }, { "kind": "slot", "index": 1, "name": "pot", "requires": "readonly_signer", "derive": "authority" }, { "kind": "slot", "index": 2, "name": "mintPYUSD", "requires": "readonly", "derive": "mint:PYUSD" }, { "kind": "slot", "index": 3, "name": "potPYUSD", "requires": "writable", "derive": "authority:PYUSD" }, { "kind": "slot", "index": 4, "name": "toPYUSD", "requires": "writable", "derive": "@to:PYUSD" } ] }, "accountsToGive": [] } ``` A recipient with no token account for the mint gets one, created before the cook; the owner pays its rent. This program never names `pot`, so its accounts derive from `authority`, the account that signs the engine call: the Pot through the Kitchen, and the owner with `--via engine`. A program that names `pot` anywhere derives them from the Pot (`pot`, `pot:USDC`), as [`payout.sauce.ts`](#large-programs-and-lookup-tables) does, and runs through the Kitchen only. The `tx` outputs on this page were built against Solana mainnet, where the engine and Kitchen are deployed. Nothing was signed or sent. ### Name an account with --account A program can take an account as a parameter of type `Account`, `Account` or `Account`. You name each one with `--account NAME=`, or give them all at once with `--accounts `, a JSON object of names to values. | Value | The account | | - | - | | an address | That account, in base58 or as the same 32 bytes in `0x` hex | | `pot` | Your Pot, which the Kitchen signs for | | `owner` | You, the signer | | `authority` | The account that signs the engine call: the Pot through the Kitchen, you with `--via engine` | | `system` | The System Program | | `pot:USDC` | Your Pot's token account for a token: a symbol or a mint | | `owner:USDC` | Your own token account for the token | | `authority:USDC` | The token account of `authority` for the token | | `@to:USDC` | The token account of `main`'s argument `to` | | `:USDC` | The token account of a base58 key | | `mint:USDC`, `program:USDC` | The token's mint, and the token program that owns it (SPL Token or Token-2022) | | `slot:@pool:USDC.vaultA` | One of the nine accounts a venue's swap takes at a pool, paying the token: `program`, `pool`, `config`, `vaultA`, `vaultB`, `extra`, `ticks0` to `ticks2` | | `pda::` | The program-derived address of a program over comma-separated seeds | A token account is the holder's associated token account for the mint, under the token program that owns the mint. A tokenized stock is named by its symbol in any case (`pot:TSLAx`). Every account a derivation needs must be known when the transaction is built. Through the Kitchen, an account given for a slot the program derives from the Pot, the owner or `authority` must be the account that derivation gives, or the command exits `2`. Giving the owner for `pay-pyusd.sauce.ts`'s `pot` slot: ```bash theme={null} sauce tx pay-pyusd.sauce.ts --chain solana --owner CEJT6RKEqjgbg7rCpnPZwxNCDie1PmdEWKrRZzqJHyCK \ --account pot=owner --args CEJT6RKEqjgbg7rCpnPZwxNCDie1PmdEWKrRZzqJHyCK 1000000 ``` ```text theme={null} sauce tx: --account pot=owner: the account pot is derived from the Pot, as authority (CBbaW8YhkhjyVn7rKLa7a9XNo4gaSffeQzMoo9vbMom4), and owner (CEJT6RKEqjgbg7rCpnPZwxNCDie1PmdEWKrRZzqJHyCK) is another account. Through the Kitchen nothing stands in for the Pot: give authority or CBbaW8YhkhjyVn7rKLa7a9XNo4gaSffeQzMoo9vbMom4, or leave the account out to derive it. ``` The same check holds a slot derived from the owner (`owner`, `owner:USDC`, a `pda:` the owner seeds) to the owner's account, on `simulate`, `run` and `tx`, `--account` and `--accounts` alike. A program that takes accounts and leaves them out is refused before anything is read, with the values that suit each slot and the JSON to save as an `--accounts` file: ```bash theme={null} sauce tx sweep.sauce.ts --chain solana --owner CEJT6RKEqjgbg7rCpnPZwxNCDie1PmdEWKrRZzqJHyCK \ --args 2b1kV6DkPAnxd5ixfnxCpjxmKwqjjaYmCZfHsFu24GXo 1000000 6 ``` ```text theme={null} sauce tx: main takes 5 accounts the cook cannot derive, so each is given by name: tokenProgram (readonly) program: (a token's program),
source (writable) pot: (the Pot's account for a token), owner:, authority: (that account's account for a token), @:,
mintAccount (readonly)
, pot: (the Pot's account for a token), owner:, authority: (that account's account for a token), @:, mint: (a token's mint), program: (a token's program) dest (writable) pot: (the Pot's account for a token), owner:, authority: (that account's account for a token), @:,
authority (readonly_signer) pot (the Pot, which the Kitchen signs for), owner (the signer), authority (the account that signs the engine call: the Pot, or the owner with --via engine) Give each with --account NAME=, or all at once with --accounts , a JSON object of each name to its value: {"tokenProgram":"program:","source":"pot:","mintAccount":"
","dest":"pot:","authority":"pot"} A token is a symbol (sauce globals --chain solana) or a mint's address. Or name the account where the program uses it, and every cook derives it: USDC.accountOf(pot).writable(), USDC.mint, USDC.tokenProgram, Account.pda(program, [seeds]). … ``` `sauce compile --json` lists the same as `accountsToGive`. A wallet is not a token account: where a program writes a token account, give the wallet's (`dest=:USDC`), not the wallet itself. ## Kitchen or engine: --via `simulate`, `tx` and `run` take `--via `: | `--via` | The cook | Use it when | | - | - | - | | `kitchen` (default) | The Kitchen's `cook` on the owner's Pot, which the Kitchen signs for | The program holds or spends what the Pot owns, or writes the Pot's storage | | `engine` | The engine's own paid cook, `cookAndPay`, with no Kitchen and no Pot | The program acts for the signer's wallet, with the signer's authority (`--account NAME=owner`), or needs one more level of calls into other programs | With `--via engine` nothing is created and there is no Pot, so a `pot` or `pot:` account cannot be attached, and a program that uses `pot`, `pot.balance` or `pot.` needs the Kitchen. A program that reads only `pot.owner` does not bind a Pot: it names the signing owner and runs with either route. ```bash theme={null} sauce tx payout.sauce.ts --chain solana --owner CEJT6RKEqjgbg7rCpnPZwxNCDie1PmdEWKrRZzqJHyCK \ --via engine --args CEJT6RKEqjgbg7rCpnPZwxNCDie1PmdEWKrRZzqJHyCK 1000000 ``` ```text theme={null} sauce tx: the program uses the Pot (potUSDC: pot:USDC, pot: pot, potUSDT: pot:USDT, potPYUSD: pot:PYUSD), and --via engine cooks with no Pot, so there is no Pot to attach: cook through the Kitchen. It names `pot` at line 6, column 11, and a program that names the Pot anywhere acts as the Pot throughout, its token writes and `ctx.self()` included. To cook it directly, write the signer's own account (`pot.owner`, or `ctx.self()` as a token holder) where it names `pot` ``` The engine's direct cook is a smaller transaction: no Kitchen, Pot or salt. ```bash theme={null} sauce tx sweep.sauce.ts --chain solana --owner CEJT6RKEqjgbg7rCpnPZwxNCDie1PmdEWKrRZzqJHyCK \ --via engine --max-execution-fee 100000 \ --account tokenProgram=program:PYUSD --account source=owner:PYUSD --account mintAccount=mint:PYUSD \ --account dest=8CZ95CfrKaPCwLPnt23CJqv887ojdtkgvCFf57JxWp9t:PYUSD --account authority=owner \ --args 2b1kV6DkPAnxd5ixfnxCpjxmKwqjjaYmCZfHsFu24GXo 1000000 6 ``` ```text theme={null} the engine's direct cook (cookAndPay): no Kitchen and no Pot. CEJT6RKEqjgbg7rCpnPZwxNCDie1PmdEWKrRZzqJHyCK is the authority the program acts with, so the accounts it spends from are the signer's own. ``` ```json theme={null} { "chain": "solana", "via": "engine", "feePayer": "CEJT6RKEqjgbg7rCpnPZwxNCDie1PmdEWKrRZzqJHyCK", "fee": "85672", "maxExecutionFee": "85672", "step": "setup", "transactions": [ { "what": "creating the token accounts", "transaction": "AQAAAAAAAAAA…", "feePayer": "CEJT6RKEqjgbg7rCpnPZwxNCDie1PmdEWKrRZzqJHyCK" } ], "plan": [ { "step": "setup", "what": "create the owner's PYUSD account, 8CZ95CfrKaPCwLPnt23CJqv887ojdtkgvCFf57JxWp9t's PYUSD account where missing", "state": "next" }, { "step": "cook", "what": "the engine's direct cook", "state": "later" } ], "expiresAtBlockHeight": "", "cursor": "sauce-plan-1.…" } ``` The token accounts did not exist yet, so the plan creates them before the cook. ## The execution fee Every cook pays the Kitchen's execution fee in lamports, read from the cluster, through the Kitchen or directly on the engine alike. Each output prints it as `fee`. The cook signs that fee as its `max_execution_fee`, so it pays that amount or fails if the fee rises before it lands. `--max-execution-fee ` sets your own ceiling, checked before anything is signed: ```bash theme={null} sauce tx pay-pyusd.sauce.ts --chain solana --owner CEJT6RKEqjgbg7rCpnPZwxNCDie1PmdEWKrRZzqJHyCK \ --max-execution-fee 1000 --args CEJT6RKEqjgbg7rCpnPZwxNCDie1PmdEWKrRZzqJHyCK 1000000 ``` ```text theme={null} sauce tx: the execution fee is 85672 lamports, above --max-execution-fee 1000: nothing was signed or sent ``` The command exits `1`. A first run also pays rent for the Pot and for each new token account, and transaction fees. [`sauce pot --chain solana`](https://docs.eco.com/sauce-sdk/cli/pot) prints the current fee. ## Large programs and lookup tables A Solana transaction holds at most 1,232 bytes. `sauce compile --json` with `--args` reports the cook's size as `cook`, as `sauce run` would build it, through the Kitchen or with `--via engine`: ```bash theme={null} sauce compile pay-pyusd.sauce.ts --chain solana --json --args CEJT6RKEqjgbg7rCpnPZwxNCDie1PmdEWKrRZzqJHyCK 1000000 ``` ```json theme={null} { "via": "kitchen", "size": 1152, "limit": 1232, "fits": true, "assumed": [], "remaining": false } ``` With `--via engine`, the same cook is 1,048 bytes. **Staging.** A cook past the limit stages its program in a Kitchen **code buffer** first, written over a few transactions, and runs from there. This program compiles to 1,421 bytes: ```ts payout.sauce.ts theme={null} // Pays three stablecoins from the Pot to one recipient, each only when the Pot holds enough. // sauce tx payout.sauce.ts --chain solana --owner --args // to: Address, the recipient's wallet // amount: Uint256, base units of each token (1000000 is 1 of each: all three have 6 decimals) function main(to: Address, amount: Uint256) { require(pot.USDC >= amount, "USDC short"); require(pot.USDT >= amount, "USDT short"); require(pot.PYUSD >= amount, "PYUSD short"); USDC.transfer(to, amount); USDT.transfer(to, amount); PYUSD.transfer(to, amount); } ``` ```bash theme={null} sauce compile payout.sauce.ts --chain solana --json --args CEJT6RKEqjgbg7rCpnPZwxNCDie1PmdEWKrRZzqJHyCK 1000000 ``` ```text theme={null} the cook is a 2190-byte transaction, past Solana's 1232: `sauce run` stages the program in a code buffer first, `sauce simulate` simulates it staged, and `sauce tx` prints the plan of transactions that stages it, for a signer ``` `sauce tx` prints the plan's first step, unsigned, with a cursor for the next: ```bash theme={null} sauce tx payout.sauce.ts --chain solana --owner CEJT6RKEqjgbg7rCpnPZwxNCDie1PmdEWKrRZzqJHyCK \ --args CEJT6RKEqjgbg7rCpnPZwxNCDie1PmdEWKrRZzqJHyCK 1000000 ``` ```json theme={null} { "chain": "solana", "via": "kitchen", "feePayer": "CEJT6RKEqjgbg7rCpnPZwxNCDie1PmdEWKrRZzqJHyCK", "pot": "CBbaW8YhkhjyVn7rKLa7a9XNo4gaSffeQzMoo9vbMom4", "fee": "85672", "maxExecutionFee": "85672", "step": "setup", "transactions": [ { "what": "creating the Pot", … }, { "what": "creating the token accounts", … }, { "what": "creating the code buffer", … }, { "what": "writing bytes 0… of the program", … }, { "what": "writing bytes 900… of the program", … }, { "what": "finalizing the code buffer", … } ], "plan": [ { "step": "setup", "what": "create the Pot; create the Pot's USDC account, the Pot's USDT account, the Pot's PYUSD account, main's argument to's USDC account, main's argument to's USDT account, main's argument to's PYUSD account where missing; stage the 1485-byte program in a code buffer", "state": "next" }, { "step": "cook", "what": "the cook, through the Kitchen, from the code buffer", "state": "later" }, { "step": "close", "what": "close the code buffer, its rent back to the owner", "state": "later" } ], "expiresAtBlockHeight": "", "cursor": "sauce-plan-1.…" } ``` The owner signs each transaction; their blockhash expires in about a minute. [`sauce send`](https://docs.eco.com/sauce-sdk/cli/send) with `--cursor` sends a step and builds the next one from what the cluster shows. `sauce run` does every step itself, and closes the code buffer after the cook so its rent comes back. **Lookup tables.** Each account a transaction lists costs 32 bytes; one taken through an address lookup table costs one byte. When a staged cook's accounts do not fit, `sauce run` creates a lookup table, paid by the signer, prints its address, and keeps it for the next cook that names the same accounts. `--lookup-table
` on `run`, `simulate` and `tx` takes a cook's accounts through a table that holds them. ## Swaps at a price and compute units A Solana transaction has 1,400,000 compute units, and a concentrated-liquidity swap spends units for every initialized tick it crosses, so a wide price limit can run a cook out of units, and a cook that runs out fails whole. For a program that swaps at a price through the venue namespaces (`Orca.Whirlpool.swap(…)`, `Raydium.CLMM.swap(…)` and the rest), `simulate`, `run` and `tx` read each pool's tick arrays and work out how far each swap may walk, the pool buying the most per unit first: * **Held or skipped.** A pool the cook's units do not cover is held short of its limit, or skipped when it cannot be paid for at all. Its swap is compiled to the venue's Stopped form, with the stop added to `main`'s values. * **Walked on.** A venue's swap walks only the tick arrays the cook gives it. On Raydium's code (Raydium CLMM, PancakeSwap CLMM, Byreal, Stabble CLMM) and Crema, that window ends where the furthest of those arrays begins. Where a pool's limit takes its walk past there, the command reads that array's last initialized tick the walk's way, its deep tick, and compiles the swap to its Stopped form with it; the swap then walks on to a tick inside that array. The Stopped form reads the tick in its array as the cook runs: a tick no longer initialized leaves the swap where it would have stopped, and an array not laid out as read reverts (`deep: the tick array is not laid out as Raydium's`, or `Crema's`). * **Every other swap** stays the plain one, and a program no stop binds is the same program, byte for byte. Each command prints a line for a pool it held or skipped, and `--json` gives every pool's stop in `computeStops`, with `deepTick` for a walk on. `tx` works the stops out from a table of each venue's costs alone, so the cook it builds can differ from the one `simulate` reports; `simulate` and `run` check them in a simulation first, and tighten them if the cook would still run out. A price that moves between building the cook and landing it can still run the cook out of units. The [Solana distributed swap](https://docs.eco.com/quickstarts/sauce/solana-distributed-swap.md) with a budget of 100,000 USDC, simulated at slot 460512539, walked its PancakeSwap CLMM pool on into its furthest tick array: ```json theme={null} { "pool": "JB9r54vk2cS9RjKDJmxnMNDNVcmvLYNwkq392cwKpxRc", "label": "Pancakeswap.CLMM.pool(USDC, SPCX_US, 800)", "venue": "PancakeSwap CLMM", "stop": "57897396174704415307659678751144296394759923110144472823708414690145578516480", "held": false, "skipped": false, "deepTick": 50132, "ticksToLimit": 3, "estimatedUnits": 150800, "share": 150800, "rank": 2 } ``` A stop is one 256-bit word: its low 192 bits are a tighter price limit (`0` for none), bits 192 to 223 a start bound past which the swap skips the pool, and bits 224 to 255 the deep tick, each tick stored with its sign bit flipped. This stop carries only the deep tick: 50132 in bits 224 to 255, and no limit or start bound. [`@sauce/router`](https://docs.eco.com/sauce-libraries/router#the-venue-functions-by-name) lists the Stopped forms. ## Token-2022 checked writes A Solana mint belongs to the SPL Token program or to Token-2022. USDC and USDT are SPL Token mints; PYUSD and the tokenized stocks are Token-2022 mints. * **Token methods** pick the write for the mint. `PYUSD.transfer(to, amount)` compiles to a checked transfer, with the registry's decimals and the mint as one more account. The manifest above shows it: `token2022Program` and `mintPYUSD`. * **Explicit checked writes** work with either token program: `transferChecked(mint, tokenProgram, source, mintAccount, dest, authority, amount, decimals)` and `approveChecked(mint, tokenProgram, source, mintAccount, delegate, authority, amount, decimals)`. The program requires `tokenProgram` to be one of the two token programs and to own the source, the destination and the mint; `mintAccount` to be `mint`; and `decimals` to be the mint's. * **Legacy writes**, `transfer`, `transferFrom` and `approve` with explicit accounts, are SPL Token only. Token-2022 refuses its plain transfer for a mint with a transfer fee, a transfer hook or a pause. A mint whose transfer hook names a program is refused with `transfer hook`. A transfer fee is withheld from what the destination receives, so measure the balance that arrived rather than the amount sent. This program moves a Token-2022 amount between accounts named on the command line: ```ts sweep.sauce.ts theme={null} // Moves a Token-2022 (or SPL Token) amount between two token accounts given on the command line. // sauce tx sweep.sauce.ts --chain solana --owner \ // --account tokenProgram=program:PYUSD --account source=pot:PYUSD --account mintAccount=mint:PYUSD \ // --account dest= --account authority=pot --args // mint: Address, the token's mint // amount: Uint256, base units of the token // decimals: Uint256, the mint's decimals function main( tokenProgram: Account, source: Account, mintAccount: Account, dest: Account, authority: Account, mint: Address, amount: Uint256, decimals: Uint256, ) { transferChecked(mint, tokenProgram, source, mintAccount, dest, authority, amount, decimals); } ``` ```bash theme={null} sauce tx sweep.sauce.ts --chain solana --owner CEJT6RKEqjgbg7rCpnPZwxNCDie1PmdEWKrRZzqJHyCK \ --account tokenProgram=program:PYUSD --account source=pot:PYUSD --account mintAccount=mint:PYUSD \ --account dest=owner:PYUSD --account authority=pot \ --args 2b1kV6DkPAnxd5ixfnxCpjxmKwqjjaYmCZfHsFu24GXo 1000000 6 ``` ```json theme={null} { "chain": "solana", "via": "kitchen", "pot": "CBbaW8YhkhjyVn7rKLa7a9XNo4gaSffeQzMoo9vbMom4", "fee": "85672", "step": "setup", "plan": [ { "step": "setup", "what": "create the Pot's PYUSD account, the owner's PYUSD account where missing", "state": "next" }, { "step": "cook", "what": "the cook, through the Kitchen, creating the Pot ahead of it", "state": "later" } ], … } ``` ## Building a cook Build cooks with the installed `sauce` command or SDK, which use the engine and Kitchen on [Deployments](https://docs.eco.com/sauce-sdk/reference/deployments.md). The Kitchen validates the named `pot` account with the salt and the Pot's canonical bump. The command and the SDK's high-level client add the 262,144-byte heap frame request every cook needs. A cook you assemble yourself in TypeScript prepends `buildHeapFramePrepend()` from `@eco-incorp/sauce/svm` exactly once ([Solana from TypeScript](https://docs.eco.com/sauce-sdk/typescript/solana.md)). ## Leftovers and sauce reclaim A run closes the code buffer it staged. A run that was stopped, or a plan never finished, can leave a buffer open, and lookup tables stay open for later cooks. [`sauce reclaim`](https://docs.eco.com/sauce-sdk/cli/reclaim) lists both, with the rent they hold, and closes them: ```bash theme={null} sauce reclaim --chain solana --owner CEJT6RKEqjgbg7rCpnPZwxNCDie1PmdEWKrRZzqJHyCK ``` ```text theme={null} there is nothing to close now CEJT6RKEqjgbg7rCpnPZwxNCDie1PmdEWKrRZzqJHyCK has 0 code buffers and 0 Sauce lookup tables open, holding 0 SOL in rent ``` With `--owner` alone it prints the closing transactions unsigned; with `--keypair` or `--wallet` it sends them. A lookup table closes in two steps, about three and a half minutes apart. ## Next steps * [`sauce run`](https://docs.eco.com/sauce-sdk/cli/run): sign and send a Solana cook. * [Solana distributed swap](https://docs.eco.com/quickstarts/sauce/solana-distributed-swap.md): a program that takes pools' accounts. * [Solana from TypeScript](https://docs.eco.com/sauce-sdk/typescript/solana.md): build the same cooks in code. * [Kitchen](https://docs.eco.com/sauce/kitchen.md): the program that runs cooks on Pots. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.