EVM and Solana

SauceScript is one language for EVM and Solana. The compiler has two targets, and the chain you compile for picks one:

Target	Chains	Runs on
`evm`	Ethereum, Base, Arc, the testnets Arc Testnet, Base Sepolia and Ethereum Sepolia, and every EVM preview chain in the registry	the V12 engine, through the owner’s Pot
`svm`	Solana, Solana Devnet and Solana Testnet	the V12 engine, through the Kitchen or directly

A program that uses only what both targets have compiles for both. The calls into other contracts and the accounts a program touches are where the targets differ.

pay.sauce.ts

// Pays `amount` USDC from the Pot to `to` and returns what `to` received.
function main(to: Address, amount: Uint256): Uint256 {
  require(pot.USDC >= amount, "not enough USDC");
  const before = to.USDC;
  USDC.transfer(to, amount);
  return to.USDC - before;
}

This file compiles for Base, Ethereum, Arc and Solana. On the EVM chains the compiled program is 328 bytes. On Solana it is 792 bytes, and the compiler also returns the four accounts the transfer moves through (below).

What compiles on each target

Something that exists on only one target is a compile error on the other, never a silent difference.

Feature	EVM	Solana
Types, operators, control flow, functions, `require`, `throw`, `revert`	yes	yes
`Int256`, signed operators, `Int256(…)`/`Uint256(…)` conversions	yes	yes
`program(closure, …args)`	yes	yes
`crypto.keccak256`, `crypto.ecdsaVerify`, `crypto.findPDA`, `Math`	yes	yes
`ctx.self()`	the Pot	the engine’s program id
`ctx.msgSender()`	the immediate caller	the first signer among the engine’s accounts
`ctx.blockNumber()`	the block number	the slot
`ctx.msgValue()`, `ctx.gasLeft()`, `ctx.codeSize()`, `ctx.isContract()`, `ctx.txOrigin()`, `ctx.baseFee()`, `ctx.blockHash()` and the other block and transaction reads	yes	compile error
`log(data, topic, …)`	up to 4 topics	`log(data)` only
`abi.encode`, `abi.decode`	yes	compile error
`evm.call`, `evm.static`, `evm.delegate`, `evm.sload`/`sstore`, `evm.tload`/`tstore`, `evm.create*`	yes	compile error
`svm.call`, `svm.sload`, `svm.sstore`, `svm.remainingAccounts()`	compile error	yes
ABI bindings, protocol namespaces, `.catch()`, `.gas(n)`	yes	compile error
Atomic `try { … } catch (error) { … }`	yes	compile error
Venue namespaces (`Orca.Whirlpool.swap(…)`)	compile error	yes
`Account` parameters with roles (`Account<Writable>`, `Account<Signer>`)	bare `Account` only, an address	yes
`acct.owner`, `acct.dataLen`	compile error	yes
`Account(key)`, `Account.pda(…)`, `Account.systemProgram` and the other programs	compile error	yes; accounts added to `main`
`pot.owner`	the Pot’s owner, read from the Pot’s `owner()`	the Pot’s owner’s account, which signs the cook
Token symbols, `pot.<TOKEN>`, `pot.balance`, `Token(…)`, the token methods	yes	yes; accounts added to `main`
`@sauce/token`	the ERC-20 arm	the SPL Token and Token-2022 arm
`@sauce/router`	one function per EVM venue	one function per Solana venue

The error names the target and, where there is one, the replacement:

Refused	Compiled for	Compiler message
`evm.static(ctx.self(), data)`	Solana	`evm.static` is not available on the svm target
`svm.call(program, [], data)`	an EVM chain	`svm.call` is not available on the evm target; an EVM external call is evm.call(...) or Contract.at().method()
`return ctx.msgValue();`	Solana	`ctx.msgValue` is not available on the svm target; pass the amount as an argument and move the lamports with a system-program transfer through svm.call

Builtins lists every builtin with its targets.

Accounts on Solana

A Solana transaction lists every account it reads or writes before it runs, each with a role: read-only, writable or signer. A program cannot reach an account the transaction did not list. When you compile for Solana, the compiler returns an account manifest: every account the program needs, in order, with its role and how to find it. sauce compile pay.sauce.ts --chain solana --json gives this manifest for the program above:

{
  "accounts": [
    { "kind": "slot", "index": 0, "name": "potUSDC", "requires": "writable", "derive": "pot:USDC" },
    { "kind": "slot", "index": 1, "name": "pot", "requires": "readonly_signer", "derive": "pot" },
    { "kind": "slot", "index": 2, "name": "toUSDC", "requires": "writable", "derive": "@to:USDC" },
    { "kind": "slot", "index": 3, "name": "tokenProgram", "requires": "readonly", "derive": "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA" }
  ]
}

Each slot’s derive says where the account comes from: pot is the Pot, pot:USDC the Pot’s USDC account, @to:USDC the USDC account of main’s argument to, and the last slot is the SPL Token program. sauce run, sauce simulate and sauce tx derive every such slot from the owner, the Pot and main’s arguments, so the program runs with --args alone. An account given with --account for a slot derived from the Pot, the owner or the authority must be the one its derivation gives; another key is refused. A program that does not use the Pot derives the accounts its token methods move through from authority instead (authority, authority:USDC): the Pot through the Kitchen, the signer in a direct cook on the engine. Reading pot, pot.USDC or pot.balance binds the program to the Pot, so --via engine cannot run it. Reading only pot.owner does not bind a Pot and works with --via engine. A program gets its accounts three ways:

The account	Write
A token account a token method moves through	nothing: `USDC.transfer(to, amount)` adds it
An account derivable from values known when the cook is built	an expression where it is used: `Account(key)`, `Account.pda(program, [seeds])`, `USDC.accountOf(holder)`, `Account.systemProgram`
An account computed while the program runs, or chosen by the caller	an `Account` parameter of `main`, attached with `--account NAME=<value>`

Derived accounts

derived.solana.sauce.ts

// Reads a program-derived account of `program` for the seed "state", and `to`'s
// associated USDC account.
function main(program: Address, to: Address): Uint256 {
  const state = Account.pda(program, ["state"]);
  const toUsdc = USDC.accountOf(to);
  return state.dataLen + balanceOf(USDC, toUsdc);
}

A program-derived address (PDA) is an address a program computes from seeds, with no key behind it. Only that program can sign for it. The Pot is one, derived by the Kitchen.
An associated token account (ATA) is the token account the token program derives for a holder and a mint. It is where that holder’s balance of that token lives.
Every holder and seed must be known when the cook is built: pot, pot.owner, ctx.self(), an Address parameter of main, a key written out, or a program account. For an account computed while the program runs, take an Account parameter instead.
.writable() and .signer() give an account the role a call needs, and chain: pot.owner.writable().signer(). Account expressions are read-only unless given a role; uses of the same account combine their roles.

Account parameters

accounts.solana.sauce.ts

// Moves `amount` of `mint` from `source` to `destination` and returns what arrived.
function main(
  tokenProgram: Account,
  source: Account<Writable>,
  destination: Account<Writable>,
  authority: Account<Signer>,
  mint: Address,
  amount: Uint256
): Uint256 {
  const before = balanceOf(mint, destination);
  transfer(mint, tokenProgram, source, destination, authority, amount);
  return balanceOf(mint, destination) - before;
}

Account is read-only; Account<Writable> and Account<Signer> declare the role the transaction must grant. The manifest records readonly, writable, readonly_signer or writable_signer per slot. Roles are what you declare; the compiler does not infer them from a call.
Account parameters are not encoded as arguments. sauce compile --json lists them as accountsToGive, and a cook missing one is refused before anything is read.
An Account exposes .address, .owner (the program that owns it) and .dataLen. Check .owner before trusting an account’s bytes: anyone can create an account with any layout. pot.owner is not this property: it is the Pot’s owner, described under ctx.self() and pot below.
An account passed as a parameter is used as attached. Nothing checks whose token account destination is; check it with ownerOf(mint, destination) when it matters, or take an Address and let the token method derive the account.

A program checks its accounts

A transaction built by someone else could attach a different account in a slot, so every derived account is checked on chain at the top of main, before the program’s own code. A wrong account fails the whole cook with a reason: wrong recipient account, wrong holder account, wrong program-derived address, wrong mint or wrong program. The Pot and the owner are pinned by their signatures.

Token programs

Every Solana token belongs to one of two token programs, and so does each of its token accounts:

Program	Mints in the registry	Moved by
SPL Token	`USDC`, `USDT`, `WSOL`	`transfer`, `approve`
Token-2022	`PYUSD`, every tokenized stock	`transferChecked`, `approveChecked`

The token methods pick the write by the mint’s program, so USDC.transfer(…) and PYUSD.transfer(…) look the same in a program. Token(mint) reads the mint’s program from the cluster when the cook is built, and refuses a mint whose program cannot be read. Token-2022’s transfer fee is withheld from what arrives, and a mint whose transfer hook names a program is refused. @sauce/token lists both of its arms.

Protocol calls

On an EVM chain a program calls a contract through a protocol namespace or an ABI binding, typed by the ABI: UniswapV3.Factory.getPool(WETH, USDC, 500). See Contracts and ABIs. Solana has no protocol namespaces. A program calls another program with svm.call(program, [accounts], data), a cross-program invocation (CPI) with accounts the transaction already lists. A failed svm.call fails the whole transaction; Solana has neither .catch() nor try/catch. Swaps use the venue namespaces, which compile to @sauce/router’s Solana functions and derive the pool’s accounts:

venue.solana.sauce.ts

// Swaps `amountIn` USDC for WSOL at Orca's USDC/WSOL whirlpool at tick spacing 4; the WSOL lands
// in the Pot's WSOL account.
function main(amountIn: Uint256, priceLimit: Uint256, minOut: Uint256): Uint256 {
  return Orca.Whirlpool.swap(Orca.Whirlpool.pool(USDC, WSOL, 4), USDC, WSOL, amountIn, priceLimit, minOut);
}

ctx.self(), pot and pot.owner

Expression	EVM	Solana
`ctx.self()`	the Pot, the executing contract	the engine’s program id
`pot`	the Pot’s address	the Pot’s key; its signer slot (`Account<Signer>`) where an `Account` is taken
`pot.USDC`	the Pot’s USDC	the Pot’s USDC
`pot.balance`	the Pot’s native coin, in wei	the Pot’s lamports
`pot.owner`	the address returned by the Pot’s `owner()`; zero for a Shared Pot	the owner’s account, which signs the cook
`ctx.self()` as a token holder (`USDC.transfer`, `balanceOf(USDC, ctx.self())`)	the Pot	the Pot

On Solana only a Kitchen cook makes the Pot sign, so a use of pot that signs as the Pot, such as a token write or pot.signer() in svm.call, fails with another account in its slot. pot.owner is the owner’s account, not the program that owns the Pot account. Write Account(pot.address).owner for that program. On Solana the engine’s program id owns every Pot account, and other accounts too, so acct.owner == ctx.self() does not prove an account is the Pot. To bind a slot to the Pot, re-derive the Pot’s address with crypto.findPDA from the Kitchen’s program id, "pot", the owner and the salt, and require the slot to be it. The Kitchen’s program id is on Deployments; see also Pot.

Transaction size and staging

A Solana transaction holds at most 1,232 bytes. A cook carries the program, its arguments (32 bytes for each Uint256 or Address), the accounts, the signatures and the transaction’s setup. sauce compile --json --chain solana reports the program’s size, and sauce tx reports whether the cook fits in one transaction. Compiled for Solana:

Program	Size	Accounts	One transaction
`USDC.transfer(to, amount)` alone	361 bytes	4	yes
`pay.sauce.ts` above (checks and measures what arrived)	792 bytes	4	no: staged
`venue.solana.sauce.ts` (one Orca swap)	2,128 bytes	17	no: staged

A program too large for one transaction is staged: uploaded first, over several transactions, into a code buffer account of the Kitchen, then cooked from that buffer. The Kitchen runs only a buffer that was finalized, and finalizing checks the SHA-256 digest of the upload. After the cook the buffer is closed and its rent returned. sauce run stages a program when it does not fit, and sauce tx returns the steps as a plan for another signer. Every account a transaction lists takes 32 bytes. An address lookup table lets a transaction refer to an account with one byte. sauce run creates one when a cook’s accounts do not fit. On EVM chains the program travels as the calldata of the cook; there is no staging. A Solana cook is built for one release set’s engine and Kitchen: the engine’s program id and the Kitchen’s instruction format are part of it. Build every cook, staged or not, with the installed SDK, and never replay a serialized cook or staging instruction built by another SDK release.

Compute and memory on Solana

Compute budget: a transaction has 1,400,000 compute units, and every instruction spends from it, the engine’s and each called program’s. A cook that runs out fails whole. A concentrated-liquidity swap spends units for every initialized tick it crosses, so a wide price limit on a deep pool can exhaust the budget. sauce holds each Solana pool’s swap short of its limit where the budget would not cover it, and on Raydium’s code and Crema walks a swap on into the furthest tick array its accounts give (Swaps at a price and compute units).
Memory: a program has 64 KiB of working memory per run. Every cook requests a 256 KiB heap frame, larger than Solana’s default. sauce and the TypeScript client add that request. A cook built by hand prepends buildHeapFramePrepend() from @eco-incorp/sauce/svm once.

CPI depth

Solana allows 4 levels of CPI below a transaction’s instruction, and 8 on a cluster where SIMD-0268 is active. Through the Kitchen, the Kitchen’s call into the engine uses one of them:

Cook	CPI levels left for the program’s own calls
Through the Kitchen (default)	3 on mainnet; 7 where SIMD-0268 is active
Directly to the engine	4 on mainnet; 8 where SIMD-0268 is active

A direct cook (--via engine) runs with no Pot. The program acts with the signer’s authority and spends the signer’s own token accounts, so a program that names pot is refused there. A program that calls an aggregator, which calls a pool, which calls a token program, can need the extra level.

Native coins

Chain	Native coin	Balance in a program
Ethereum, Base	ETH, 18 decimals	`pot.balance` (`ctx.selfBalance()`), `holder.balance`
Arc	USDC, 18 decimals	`pot.balance` (`ctx.selfBalance()`), `holder.balance`
Solana	SOL, in lamports (9 decimals)	`pot.balance`, `holder.balance`

On an EVM chain only evm.call(address, value, data) sends native value with a call; ABI bindings send none. On Solana a program moves lamports with a System Program transfer through svm.call. On Arc the native coin and the ERC-20 USDC are one balance at two scales: 18 decimals natively, 6 for the token. Sending native value and calling USDC.transfer move the same money, and the gas and the Kitchen’s fee are paid from it too. pot.USDC reads the 6-decimal token and pot.balance the 18-decimal native coin:

arc-pay.sauce.ts

// Pays `amount` of Arc's USDC token (6 decimals) from the Pot to `to`, and returns the Pot's
// native balance afterwards (18 decimals).
function main(to: Address, amount: Uint256): Uint256 {
  require(pot.USDC >= amount, "not enough USDC");
  USDC.transfer(to, amount);
  return pot.balance;
}

Native fees paid by the program, such as bridge or messenger fees, spend the Pot’s balance, so leave enough USDC for them. The ordinary cook’s Kitchen fee comes from the owner’s attached transaction value and is forwarded before the program runs; a signed cook can pay it from existing Pot funds.

Next steps

Names: what each name resolves to on each chain.
@sauce libraries: @sauce/token and @sauce/router on both targets.
Kitchen and Pot: how a cook runs on each target.
Chains: every chain, its target and its support.

Start here

Integration guides

Language reference

SauceScript libraries

Runtime and security

Troubleshooting and production

Chains and protocols

@eco-incorp/sauce

@eco-incorp/sauce-compiler

What compiles on each target

Accounts on Solana

Derived accounts

Account parameters

A program checks its accounts

Token programs

Protocol calls

ctx.self(), pot and pot.owner

Transaction size and staging

Compute and memory on Solana

CPI depth

Native coins

Next steps

​What compiles on each target

​Accounts on Solana

​Derived accounts

​Account parameters

​A program checks its accounts

​Token programs

​Protocol calls

​ctx.self(), pot and pot.owner

​Transaction size and staging

​Compute and memory on Solana

​CPI depth

​Native coins

​Next steps

What compiles on each target

Accounts on Solana

Derived accounts

Account parameters

A program checks its accounts

Token programs

Protocol calls

ctx.self(), pot and pot.owner

Transaction size and staging

Compute and memory on Solana

CPI depth

Native coins

Next steps