Skip to main content
Sauce turns a program into one atomic onchain execution. The SDK supplies chain and protocol knowledge, the compiler turns SauceScript into bytecode, and an onchain engine executes that bytecode. An Eco intent describes a destination execution and the reward for fulfilling it.

​
Three layers

Both compiler targets emit Sauce bytecode, interpreted by the selected engine. EVM output is not Solidity deployment bytecode, and SVM output is not a Solana ELF program. EVM programs travel in calldata. Solana programs can be included inline or staged in code accounts for later execution.

​
How a program executes

​
EVM

Pot.cook(address engine, bytes program) runs one program. The Kitchen, a UUPS proxy, mints Pots and gates every cook; the Pot is a per-owner account that delegatecalls the engine named in each call, so a Pot’s address survives an engine release. Under that delegatecall ctx.self() is the Pot, so token balances and approvals in a program refer to the Pot. The Router is the DEX swap surface a program reaches by self-call. Only canonical Pots deployed through the configured Kitchen are accepted. cook is owner-only. For a direct Eco intent route, the caller and required owner is the destination Portal’s Executor; for a program you run yourself, the owner is your wallet. A multi-statement route body compiles to one program and one cook.

​
Solana

The compiler returns an account manifest with the bytecode: Account parameters name attached slots, with Writable and Signer modifiers for required roles. The Kitchen program invokes the engine by cross-program invocation, and can stage a program’s bytecode in a finalized code account for larger programs. Engine program IDs vary by release. Check the deployed program’s upgrade authority rather than inferring immutability from its version. The Kitchen can be upgraded in place, preserving its program ID and Pot addresses. Devnet and mainnet interpreters are different binaries because the chain id is compiled in.

​
The execution fee

Each cook pays the Kitchen’s current execution fee in the chain’s native token (wei on the EVM, lamports on Solana). The fee is a fixed native amount set per chain by Eco, and does not automatically track a US dollar value. Eco can change it with a configuration update; existing Pots read the current value on every execution. Read executionFee() (or the Kitchen’s fee configuration account on Solana) before each cook, because an increase above the value or cap you supplied makes the cook revert.

​
Compiler and engine compatibility

Compiler 2.3.0 labels its output isaRevision: "stack-compact-v2" and reports the entry-argument encoding, abi-v1 or compact-v1. Those fields describe the artifact; they do not inspect an address. The release policy from 1.0.0 versions the opcode set and semantics (EVM) and wire contract (SVM): incompatible changes require a major bump, and release addresses are derived per version. This policy does not establish onchain immutability. Solana engine 1.2.0 currently has an upgrade authority, as recorded below. Check the actual deployed code and authority when relying on a pinned engine. A compiler change can alter bytecode without changing the source-level API, so keep the compiler version, target, ISA revision and argument format with any cached or staged artifact, and recompile after upgrading. Compiler 2.3.0 fixed silent mis-encoding of scalar arrays in EVM abi.encode present in compilers 0.3.0 through 2.2.1; recompile EVM programs built with those versions.
Compiler 2.3.0 still has an EVM encoding defect for some scalar values in tuples, including external-call argument lists and multi-value abi.encode. The scalar-array fix in 2.3.0 does not fix that case. Compilation alone does not validate runtime results; check the encoded calls and simulate your exact inputs before execution.

​
Deployments

The table below records 16 EVM mainnet deployments and the Solana mainnet programs checked on 2026-09-29. It does not establish testnet availability or Routes API chain support; see supported chains for the API list. Addresses are the same on every EVM chain: each contract is placed through the CreateX factory (0xba5Ed099633D3B313e4D5F7bdc1305d3c28ba5Ed) by deployer 0x6Ab56944462222A2405ffb87d01A29e37890abC3. The SDK returns them as v12EngineAddress(), v12KitchenAddress(), v12RouterAddress(), v12SvmEngineProgramId() and v12SvmKitchenProgramId() from @eco-incorp/sauce/deployments. Release addresses do not by themselves prove deployment on a chain; check code on the target chain before use, as the SDK’s prepareDestinationPot example does.

​
EVM contracts

A Pot’s address is CREATE2(kitchen, keccak256(abi.encode(owner, salt)), initCodeHash) with init code hash 0x47913cfa9c7a1dcfe6b69ea8f3ab25a579befbcb732fa65498e6be8be6613739. Kitchen 1.0.0 is deployed on every chain above.

​
Solana programs

Engine 1.2.0 includes direct paid cook entrypoints and a code-hash-pinned staged variant; the SDK clients use Kitchen-mediated cooks. On 2026-09-29, Solana mainnet RPC reported engine 1.2.0 as executable with the upgrade authority shown above; engines 1.0.0 and 1.0.1 had no upgrade authority. Check the engine 1.2.0 program account for current state.

​
Versioning and access

Engines and Kitchens follow the v1 compatibility contract described above since release 1.0.0. The compiler is versioned separately and follows semver; on the 0.x SDK a breaking change is a minor bump. Sauce v1 is closed access; contact Eco to integrate.