> ## 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. # Kitchen > The Kitchen is the contract on EVM chains and the program on Solana that creates Pots and charges the fee every cook pays. The Kitchen creates Pots and sets the fee every cook pays. On EVM chains it is a contract, deployed deterministically at the same address on every chain it is on. It is an upgradeable proxy: you call the Kitchen's address, and its implementation sits behind it. On Solana the Kitchen is a program with the same id on every cluster, and it also stages programs too large for one transaction. [Deployments](https://docs.eco.com/sauce-sdk/reference/deployments.md) lists the addresses. `sauce pot` reads a chain's Kitchen, its fee and an owner's Pot: ```bash theme={null} sauce pot --chain base --owner
``` ```text theme={null} On base: the engine 0x0F50…0f67 is deployed; the Kitchen 0x1984…506b is deployed, its execution fee 3744785386350 wei (0.00000374478538635 ETH); the Pot 0x6c91…D3Fe is NOT deployed. This is Kitchen.deployPot on the released Kitchen. Any account may send it: the Pot is 0x1111…1111's either way, and it deploys once. ``` That read was on a local fork of Base at block 52965000 with the current contracts. The JSON on stdout carries the unsigned `deployPot` transaction. ## Creating a Pot `deployPot(owner, salt)` creates the Pot of `owner` under a 32-byte `salt`, at an address that follows from the Kitchen, the owner and the salt ([Pot](https://docs.eco.com/sauce/pot.md#its-address)). * Anyone may send it. The Pot belongs to `owner`, whoever pays for the deployment. * It deploys once. Sending it again for the same owner and salt returns the Pot already there. * It carries no fee: the deployment costs its gas. On a local fork of Base at block 52965000 with the current contracts, a simulated deployment used 667,003 gas. * The Kitchen's ABI declares the event `PotDeployed(owner, salt, pot)`. Signed cooks are a feature of the Pots this Kitchen creates, not of the Kitchen ([Signed cooks](https://docs.eco.com/sauce/pot.md#signed-cooks)). `sauce run` deploys an owner's Pot before the first cook that needs it, and `sauce tx` puts the deployment first in the plan it prints. `sauce pot --deploy` sends it on its own. The Kitchen's functions that create and find Pots: | Function | What it does | | - | - | | `deployPot(address owner, bytes32 salt) returns (address pot)` | creates a private Pot whose Router can be changed by its owner | | `deployPot(address owner, bytes32 salt, bool routerFixed) returns (address pot)` | with `routerFixed` true, creates a private Pot whose Router never changes | | `deploySharedPot(bytes32 salt) returns (address pot)` | creates a [Shared Pot](#shared-pots) | | `predictPot(owner, salt)`, `predictPot(owner, salt, routerFixed)`, `predictSharedPot(salt)` | the address such a Pot has, deployed or not | | `potInitCodeHash()` | the Pot init-code hash in the address derivation | | `router()` | the Router that Pots created from now on start on | | `executionFee()` | the fee each cook pays, in the native coin's smallest unit | ## The fee Every cook pays the Kitchen a flat fee. It does not depend on what the program does. * **It is paid in the chain's native coin.** For a `cook`, it is paid out of the cook's value, and the Pot forwards it to the Kitchen: what the Pot already holds does not pay it, and native coin the program spends comes on top. For a [signed cook](https://docs.eco.com/sauce/pot.md#signed-cooks), the Pot pays it from its own balance, which includes the value the submitter sent, never more than the signed `maxExecutionFee`. * **It is on-chain state.** The Kitchen's owner sets it with `setExecutionFee` (event `ExecutionFeeSet`) and withdraws what the Kitchen collected with `withdrawExecutionFees`. * **It is read when the cook is built.** `sauce tx`, `sauce simulate` and `sauce run` read `executionFee()`; in TypeScript, `kitchenExecutionFee()` from `@eco-incorp/sauce` builds that read and decodes it. * **A cook below the fee reverts** with the Pot's error `FeeNotPaid(uint256 required, uint256 provided)`: a `cook` whose value is below it, or a signed cook whose fee is above the smaller of the Pot's balance and its signed ceiling. A fee raised between building a cook and its landing fails that cook only if the new fee exceeds that bound: the `cook`'s value, or the smaller of the Pot's balance and the signed ceiling. Then nothing moves. `sauce tx` sets the value, and `sauce sign` the ceiling, to the fee it read, so any increase fails a cook built with those defaults. * **A cook that reverts pays no fee.** The fee transfer reverts with the rest of the transaction. The fee as `sauce pot` read it, on local forks with the current contracts, and on Solana as `sauce simulate` read it from the cluster: | Chain | Fee | Read at | | - | - | - | | Ethereum | 37289431242950 wei (0.00003728943124295 ETH) | a fork at block 26252095 | | Base | 3744785386350 wei (0.00000374478538635 ETH) | a fork at block 52965000 | | Arc | 10000000000000000 wei (0.01 USDC) | a fork at block 27376858 | | Solana | 85672 lamports | slot 460261665 | On Arc the native coin is USDC, so the fee is paid in USDC: as native value it has 18 decimals, and it is drawn from the same balance as the 6-decimal `USDC` token. `sauce simulate` refuses a `--value` below the fee before it simulates: ```text theme={null} sauce simulate: --value 1 is below the Kitchen's execution fee on base, 3744785386350 wei (0.00000374478538635 ETH): the cook would revert with FeeNotPaid ``` ## What the Kitchen's owner controls On EVM chains the Kitchen has an owner, separate from every Pot's owner. The table and the paragraph after it describe the EVM Kitchen. On Solana the Kitchen's upgrade authority holds a wider power: see [Trust on Solana](#trust-on-solana). | The Kitchen's owner can | The Kitchen's owner cannot | | - | - | | set the fee, and withdraw the fees collected | change a deployed Pot's code, owner or Router | | set the Router that Pots created afterwards start on (`setRouter`) | move anything a Pot holds | | upgrade the Kitchen's implementation, and transfer the Kitchen's ownership | cook on a Pot | The fee has no cap. A fee no cook can pay, or an upgrade whose fee collection reverts, stops every Pot's cooks, and a Pot has no withdraw function, so what Pots hold stays in them until cooks can run again. The Kitchen's owner can stop cooks this way, but cannot move what a Pot holds. Changing the Kitchen's Router moves no Pot address and no deployed Pot. A deployed Pot keeps its Router until its own owner changes it ([The Pot's Router](https://docs.eco.com/sauce/pot.md#the-pots-router)). Only a change of the Pot init-code hash moves the addresses of Pots created afterwards. A release that keeps the Kitchen moves no Pot. ## Shared Pots Every Pot the `sauce` command and the SDK's helpers use is a private Pot: one owner, who alone may cook on it. The Kitchen also creates Shared Pots with `deploySharedPot(salt)`. * A Shared Pot has no owner. Anyone can cook on it and spend what it holds. * So a Shared Pot is funded and emptied within one transaction. * Its Router is always fixed. Encode these calls with `v12KitchenAbi` from `@eco-incorp/sauce/evm/engine`, the Kitchen's complete ABI. ## The Kitchen on Solana On Solana the Kitchen is a program. The engine is named on each call as an account, `engine_program`; the Kitchen does not check it, and the `sauce` command names the released engine. | Instruction | Signed by | What it does | | - | - | - | | `create_pot(salt, space)` | the owner, who pays the rent | creates the Pot account at the Kitchen's program-derived address for `"pot"`, the owner and the salt; `space` is at most 10,240 bytes | | `close_pot(salt)` | the owner | closes the Pot account through the engine that owns it and returns its lamports to the owner; its storage is erased. `create_pot` at the same salt creates it again, empty, at the same address. The Pot's token accounts are separate accounts and stay open. A salt naming no live Pot is `PotNotFound`, and an `engine_program` that does not own the Pot is `PotNotOwnedByEngine` | | `cook(pot_salt, pot_bump, bytecode, max_execution_fee)` | the owner | charges the fee, then runs `bytecode`, carried in the instruction, on the engine, signing for the Pot | | `cook_from_account(pot_salt, pot_bump, pin, max_execution_fee)` | the owner | the same, with the program read from a finalized code buffer; an optional `pin` is the SHA-256 the staged bytes must hash to | | `create_code_buffer(nonce, capacity)`, `grow_code_buffer`, `write_code_buffer(offset, chunk)` | the owner | create a code buffer of up to 1,048,576 bytes, grow it by up to 10,240 bytes per instruction, and write the program into it in pieces | | `finalize_code_buffer(len, expected_sha256)` | the owner | shrinks the buffer to `len` bytes and refuses it unless they hash to `expected_sha256` (`CodeBufferHashMismatch`) | | `close_code_buffer(expected_sha256)` | the owner | closes the buffer and returns its rent | | `set_execution_fee(fee)`, `withdraw_execution_fees(amount)` | the Kitchen program's upgrade authority | price the cooks, and collect the fees | Both cooks name the Pot by its salt and then its bump, the byte that makes its address a valid program-derived address, and take the Pot as an account the Kitchen checks against them. The SDK's builders derive the bump. An instruction serialized for the Kitchen before the current one lacks the bump: build cooks with the installed SDK. The fee lives in one account of the Kitchen, derived from the seed `"execution_fee"`. It is both the price and the treasury: a cook through the Kitchen and a cook directly on the engine read the same fee and pay into the same account. * Every cook signs a `max_execution_fee`, in lamports. A fee above it refuses the cook before anything runs or is paid; the Kitchen's error is `ExecutionFeeExceedsMaximum`. * A fee payer short of lamports fails a Kitchen cook with `ExecutionFeeNotPaid`. * The fee instructions check the Kitchen program's live upgrade authority, so whoever can upgrade the Kitchen sets its price (`NotFeeAuthority` for anyone else). `sauce pot --chain solana` prints the Pot's address, the `create_pot` instruction, the engine and the Kitchen with its fee, and the Pot's token accounts: ```bash theme={null} sauce pot --chain solana --owner ``` ```text theme={null} The Pot's USDC account, --account NAME=pot:USDC: 6Cz6…RSGs, not created yet (a wallet's SPL transfer to the Pot creates it) ``` That is one line of its output for the owner's default Pot, `BjFS…Xo9T` (abridged). The lines after it name the Pot's PYUSD, USDT and WSOL accounts. ### Trust on Solana The Solana Kitchen is an upgradeable program, and it signs for every Pot. The limits of the EVM Kitchen's owner do not carry over: * **The Kitchen's code decides who cooks on a Pot.** The current Kitchen requires the Pot's owner to sign each cook, and then signs for the Pot, so the program can spend what the Pot's authority covers, its token accounts included. * **Its upgrade authority can replace that code.** A replaced Kitchen could sign for any Pot and run any program on it, so it could move anything a Pot holds. Using a Pot on Solana trusts the Kitchen's upgrade authority with those funds. * **The engine has no upgrade authority**, so its code cannot change. That does not make the Kitchen immutable: the check of the Pot's owner, and the signature for the Pot, are the Kitchen's. * **The same authority prices the cooks**, with `set_execution_fee`, and collects the fees. `solana program show ` prints a program's upgrade authority, or `none`. Read on Solana at slot 461689935, the Kitchen's program data named an upgrade authority, last deployed at slot 460549585; read at slot 461689940, the engine's named none. [Deployments](https://docs.eco.com/sauce-sdk/reference/deployments.md) lists both program ids. ## Next steps * [Pot](https://docs.eco.com/sauce/pot.md): what the Kitchen creates, and who can do what with it. * [cook()](https://docs.eco.com/sauce/cook.md): the call that pays the fee and runs a program. * [`sauce pot`](https://docs.eco.com/sauce-sdk/cli/pot): reading and deploying Pots from the command line. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.