> ## 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. # Sauce architecture and deployments > How Sauce fits together: the SDK, the SauceScript compiler and the onchain engines, Kitchen and Pot; how a program executes on the EVM and Solana; the Kitchen execution fee; compiler and engine compatibility; and the release addresses on 16 EVM mainnets and Solana mainnet. 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 | Layer | Published as | Responsibility | | - | - | - | | SDK | `@eco-incorp/sauce` | Protocol and token registries, route syntax and intent builders, program builders, account planning, transaction helpers, settlement verification | | Compiler | `@eco-incorp/sauce-compiler`, exposed in Node as `@eco-incorp/sauce/compiler` | Parse and check SauceScript, resolve modules and ABIs, apply compile-time parameters, emit EVM or SVM bytecode | | Runtime | The Sauce EVM and SVM engines with the Kitchen and Pot contracts and programs | Execute compatible bytecode against the chain's accounts and contracts | 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 | Component | Pinned release | | - | - | | Compiler | `@eco-incorp/sauce-compiler` 2.3.0 | | EVM engine | 1.0.1 (1.0.0 remains deployed on eight chains) | | SVM engine | 1.2.0 (1.0.0 and 1.0.1 remain deployed) | | EVM and SVM Kitchens | 1.0.0 | 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](/resources/supported-chains-tokens) 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 | Contract | Address | | - | - | | Engine 1.0.1 | `0x9745fdfaB1be84a0003f0472A842A0b91E5A323c` | | Engine 1.0.0 | `0x7d6FB016aa99425b6b490aDB520839b3A2342d3F` | | Kitchen 1.0.0 (UUPS proxy) | `0x19845b22989150E6B09dE55a661295Dd9188506b` | | Kitchen implementation | `0x07E7dfc8389269EC5cd796E55e408aDB98D365c2` | | Router | `0xB820759EDD59318C2BD8B303C51Ad0E5176B608D` | A Pot's address is `CREATE2(kitchen, keccak256(abi.encode(owner, salt)), initCodeHash)` with init code hash `0x47913cfa9c7a1dcfe6b69ea8f3ab25a579befbcb732fa65498e6be8be6613739`. | Chain | Chain ID | Engines deployed | | - | - | - | | Ethereum | 1 | 1.0.1 | | Optimism | 10 | 1.0.0, 1.0.1 | | BSC | 56 | 1.0.0, 1.0.1 | | Unichain | 130 | 1.0.1 | | Polygon | 137 | 1.0.1 | | Monad | 143 | 1.0.1 | | Sonic | 146 | 1.0.0, 1.0.1 | | World Chain | 480 | 1.0.1 | | HyperEVM | 999 | 1.0.1 | | Robinhood Chain | 4663 | 1.0.1 | | Arc | 5042 | 1.0.1 | | Base | 8453 | 1.0.0, 1.0.1 | | Plasma | 9745 | 1.0.0, 1.0.1 | | Arbitrum | 42161 | 1.0.1 | | Celo | 42220 | 1.0.0, 1.0.1 | | Ink | 57073 | 1.0.0, 1.0.1 | Kitchen 1.0.0 is deployed on every chain above. ### Solana programs | Program | Program ID | Upgrade authority | | - | - | - | | Engine 1.2.0 | `HB8b1oD5PB2ptkLH6EV56Rr9RHevutEfvG2YdA7an6rK` | `AAtikhEUPsLnCjvgBmV4oJrz9jdZxU6RwUUKoJQfYAY5` | | Engine 1.0.1 | `8Sgwi8N7JykC3K19ReY8aZzYXmWxKcDTedtQ6r1y6iwH` | None: deployed final | | Engine 1.0.0 | `DnR2g6w9gVhqcR68QEpuw7Wm7MuoKxRVEtKZDXGes3Nj` | None: deployed final | | Kitchen 1.0.0 | `SauceYLdWyabKFwtevSAgsSDoMjCoTKtx1HTb63eJot` | Eco's deploy authority; upgraded in place | 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](https://explorer.solana.com/address/HB8b1oD5PB2ptkLH6EV56Rr9RHevutEfvG2YdA7an6rK) 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](mailto:partners@eco.com) to integrate.