Pot

​

Its address

CREATE2(kitchen, keccak256(abi.encode(owner, salt)), potInitCodeHash)

• On EVM, it is known before the Pot exists, as the prediction of the Kitchen the chain runs. Tokens sent to a predicted address that no Pot is deployed at are out of reach of every cook. Deploy the Pot before you send it funds, with sauce pot --chain <chain> --deploy and the owner’s signer, or with sauce run --fund, which deploys the Pot before it funds it (Funding a Pot). sauce tx --fund plans the deployment first only when its endpoint shows the Pot has no code; with --offline it cannot check, so deploy first. Without --offline, sauce pot also reports whether the chain has the Kitchen, and refuses the deployment on a chain the sauce command does not send on.
• A deployed Pot’s address never changes.
• The Kitchen has the same address on every EVM chain it is on, so where each chain runs the same Kitchen release, an owner’s Pot under one salt has the same address on each of them.

sauce pot --chain base --owner <address> --salt treasury --offline
sauce pot --chain ethereum --owner <address> --salt treasury --offline

​

Salts

• The default salt is zero: the owner’s default Pot. In TypeScript it is DEFAULT_POT_SALT.
• --salt <label> names another Pot: its salt is the keccak256 of the label’s UTF-8 bytes. In TypeScript, potSalt(label).
• --salt-hex <bytes32> gives the salt exactly.

import { potSalt, v12PredictPot } from "@eco-incorp/sauce";
import type { Hex } from "viem";

export function potsOf(owner: Hex) {
  return {
    main: v12PredictPot(owner), // salt DEFAULT_POT_SALT, 32 zero bytes
    treasury: v12PredictPot(owner, potSalt("treasury")), // salt keccak256("treasury")
  };
}

​

Deploying it

• sauce run deploys the Pot before the first cook that needs it, as a transaction of its own, after asking (or with --yes).
• sauce tx prints a plan when the Pot has no code yet: deployPot first, marked deploysPot, then the cook.
• sauce simulate deploys the Pot inside the simulation first.
• sauce pot --deploy sends the deployment alone.

​

What it holds

// Supplies `amount` of the Pot's USDC to Aave V3 for `onBehalfOf`, who receives the aUSDC.
//
//   sauce simulate supply.sauce.ts --chain base --owner <address> --assume-balance USDC:100 --args <onBehalfOf> 100000000
//
//   onBehalfOf: Address   who receives the aUSDC: your wallet, or the Pot itself to keep the position there
//   amount: Uint256       in USDC's smallest unit (6 decimals): 100000000 is 100 USDC
function main(onBehalfOf: Address, amount: Uint256) {
  USDC.approve(AaveV3.Pool, amount);
  AaveV3.Pool.supply(USDC, amount, onBehalfOf, 0);
}

​

No withdraw function

// Sends all of the Pot's USDC to `to`.
//
//   sauce run sweep.sauce.ts --chain base --wallet <name> --args <to>
//
//   to: Address   the recipient, such as your wallet
function main(to: Address) {
  USDC.transfer(to, pot.USDC);
}

​

Who can do what

​

Signed cooks

function cookSigned(
    address engine,
    bytes program,
    uint256 maxExecutionFee,
    uint256 nonce,
    uint256 deadline,
    address submitter,
    bytes signature
) payable returns (bytes);

function invalidateNonces(uint256 word, uint256 mask);

​

The Pot’s interface

​

The Pot’s Router

• A new Pot starts on the Router the Kitchen names in router() when the Pot is created.
• After that, only the Pot’s owner can change it, with the Pot’s setRouter. A call from anyone else reverts with NotOwner().
• A Pot created with deployPot(owner, salt, true) keeps its Router for good, and so does every Shared Pot.
• The Kitchen’s owner changes the Router that Pots created afterwards start on, and nothing else. A Router change moves no Pot address.

​

A Pot on Solana

• Address. A Pot is a program-derived address of the Kitchen program, from the seeds "pot", the owner and a 32-byte salt. It is known before the Pot exists, and the default salt is zero, as on EVM chains.
• Creation. The Kitchen’s create_pot creates it. The owner signs that instruction and pays the rent, Solana’s deposit for storing an account. sauce run asks before creating it, and sauce tx puts it in the setup it prints.
• Storage. A Pot keeps 10,240 bytes of storage for programs, fixed when it is created. In a simulation in the sauce command’s local copy (LiteSVM) of the cluster at slot 460261665, its rent was 52,669,440 lamports, and the rent of the Pot’s USDC token account 1,488,440 lamports.
• Cook instructions. The Kitchen’s cook and cook_from_account carry the Pot’s salt and then its bump, the byte that makes the Pot’s address a valid program-derived address. The SDK’s builders and the sauce command derive the bump. An instruction serialized for the Kitchen before the current one has the earlier format and names the earlier engine: build cooks with the installed SDK.
• Signing. The current Kitchen requires the owner to sign each cook, and signs for the Pot, so the program can spend tokens whose authority is the Pot. The Kitchen program is upgradeable: its upgrade authority can replace that check, and must be trusted with what the Pot holds (Trust on Solana).
• Token balances. The Pot’s tokens sit in its token accounts, one per mint, at the associated token account under the mint’s token program. sauce pot --chain solana lists them.
• pot and ctx.self(). In a program on Solana, ctx.self() is the engine program’s id, not the Pot. pot is the Pot: its key, its signer slot where an Account is taken, and the holder in pot.USDC. pot.owner is the owner’s account; pot.owner.writable().signer() gives it both roles. Account(pot.address).owner reads the program that owns the Pot account instead.
• No Pot. A cook sent directly to the engine runs with no Pot, and has only the signers its transaction gives it. A program that uses pot, pot.balance or pot.<TOKEN> is refused there; one that reads only pot.owner is not.

sauce pot --chain solana --owner <public key>

​

Next steps

• cook(): the call that runs a program on a Pot.
• Kitchen: who creates Pots and sets the fee.
• Security considerations: what to check before you sign a cook.
• sauce pot: reading and deploying a Pot.