@eco-incorp/sauce 0.99.1 → 0.99.2

package/LICENSE.md

@@ -0,0 +1,29 @@
+Eco Proprietary License 1.0
+License text copyright (c) 2025-2026 Eco, Inc., All Rights Reserved.
+-----------------------------------------------------------------------------
+Parameters
+Licensor:             	Eco, Inc.
+Licensed Work:        	Sauce v1.0
+                      	The Licensed Work is (c) 2025-2026 Eco, Inc.
+Authorized Contracts:   The onchain contract addresses (if any) implementing the Licensed Work that       
+                        Eco, Inc. publishes and may update at docs.eco.com
+Additional Use Grant:   None
+Change Licenses:	      None
+-----------------------------------------------------------------------------
+Terms
+Subject to these terms, the Licensor grants you a limited, non-exclusive, non-transferable, revocable license to (i) view the Licensed Work; and (ii) interact with the Authorized Contracts by submitting transactions on supported networks (the "Permitted Uses"). No other rights are granted or implied. All rights not expressly granted are reserved.
+
+You may not (and may not permit or enable others to: (i) copy, publish, distribute, host, mirror, or sublicense the Licensed Work, in whole or in part; (ii) modify, translate, adapt, or create derivative works of the Licensed Work; (iii) deploy, verify, or cause to be deployed any smart contract or other software that includes, is based on, or is a modified form of the Licensed Work; (iv) use any portion of the Licensed Work for any product or service, including as-a-service offerings, other than interacting with the Authorized Contracts as permitted above; (v) remove or alter copyright, license, or attribution notices; or (vi) use the Licensor's trademarks or logos except as required to reproduce notices.
+
+Portions of the Licensed Work may include or reference third-party components under their own licenses. Those components remain governed by their respective licenses; nothing here limits your rights under those licenses, and nothing in those licenses expands your rights to the Licensed Work.
+
+If your intended use falls outside the Permitted Uses you must obtain a separate commercial license from the Licensor or refrain from using the Licensed Work.
+
+Any breach of this License immediately terminates your rights. Upon termination, you must cease all use and destroy all copies in your possession or control. Termination is without prejudice to any other remedies available to the Licensor, including injunctive relief.
+
+For any Permitted Uses, you must retain this License text and all copyright notices.
+
+THE LICENSED WORK IS UNDER DEVELOPMENT AND ACCESS TO AND USE OF IT IS SUBJECT TO LICENSOR'S APPROVAL. THE LICENSED WORK IS PROVIDED "AS IS" AND "AS AVAILABLE," WITHOUT WARRANTY OF ANY KIND. TO THE MAXIMUM EXTENT PERMITTED BY LAW, LICENSOR DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT. LICENSOR WILL NOT BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, EXEMPLARY, OR PUNITIVE DAMAGES, OR FOR LOST PROFITS, LOST DATA, OR BUSINESS INTERRUPTION, ARISING OUT OF OR RELATED TO THIS LICENSE OR THE LICENSED WORK, EVEN IF ADVISED OF THE POSSIBILITY.
+-----------------------------------------------------------------------------
+Notice
+This is a proprietary license and is not an open source license. Permission to interact with the Authorized Contracts does not grant any right to copy, modify, distribute, or deploy the Licensed Work or derivative works.

package/README.md

@@ -1,276 +1,96 @@
 # Sauce
 
-**Sauce** — write transaction logic in TypeScript, compile it to bytecode, and execute it atomically
-against live on-chain state in a single transaction. Sauce is a Turing-complete runtime for the EVM
-and SVM: a program can read from many contracts, branch on what it finds, and take the best path _at
-execution time_ — no contract to deploy, no second block. This one package builds, compiles and
-verifies those programs for both targets, and assembles them into cross-chain intents. Published as
-`@eco-incorp/sauce`.
+Write programmable transactions and Eco intents with **`@eco-incorp/sauce`**. The SDK compiles
+SauceScript into bytecode for the Sauce EVM and Solana runtimes, resolves protocol contracts and
+tokens, and builds the calls that execute your program.
 
 ```sh
 npm install @eco-incorp/sauce
 ```
 
-Full documentation, guides and the protocol overview: **[sauce.eco.com](https://sauce.eco.com)**.
+[Documentation](https://unpkg.com/@eco-incorp/sauce@0.99.2/docs/README.md) · [Quick start](https://unpkg.com/@eco-incorp/sauce@0.99.2/docs/guides/quick-start.md) ·
+[Examples](https://unpkg.com/@eco-incorp/sauce@0.99.2/docs/examples/README.md) · [API reference](https://unpkg.com/@eco-incorp/sauce@0.99.2/docs/api/README.md)
 
-> The runtime **engine** (the on-chain interpreter these programs execute on) lives in the separate
-> `eco-incorp/v12` repo. This repo — `eco-incorp/sauce` — is the developer-facing Sauce package that
-> _targets_ it. The EVM target is fully featured (audit planned); the SVM target is in active
-> development, so a few paths below are EVM-only and say so.
+Use Node.js **24 or newer**. The links open the Markdown manual and examples included in this package version. After installation, you can also open `node_modules/@eco-incorp/sauce/docs/README.md` locally.
 
-**Node only.** The compiler is loaded through `createRequire` (its `node` build is CommonJS reading a
-sibling `.wasm` off disk), and the route path imports `node:fs`/`node:path`, so the Quickstart, the
-builders and `/compiler` all require a Node runtime. The registry and decoding subpaths import no
-Node builtin and work anywhere: `/verify`, `/chains`, `/deployments`, `/protocols/*`, `/evm/engine`
-and `/svm/engine`. The
-compiler package does ship a browser build, but this package does not expose it.
+## Programs with protocol and token globals
 
-The SauceScript compiler comes with it as a dependency. There are no optional peers.
-
-## How it works
-
-A Sauce program is ordinary TypeScript — a `main()` function — that the compiler lowers to compact
-bytecode. That bytecode runs on the Sauce engine inside a **single transaction**, so the whole
-program is atomic: it reads live state from any number of contracts, branches on what it finds
-(`if`/`else`, loops, arithmetic), and either commits or reverts as a whole. Nothing is deployed — the
-program travels in calldata and executes once.
-
-Because the decision happens at execution time, not at signing time, **best execution is a property
-of the program**: it can read several venues and take the winner in the same transaction that
-settles. The shipped recipes show the shape — `cctp-split` splits an amount across capped burns with
-a loop; `settle` reads a Pot's balance and reverts the whole cook when an output would fall short of
-a floor.
-
-## Quickstart
-
-A **route** packages a program as a cross-chain intent. Hand `openRoute` the destination chain and
-the program source; the SDK compiles it and assembles the `Intent`:
+This complete example builds an intent offline. The repeated-digit addresses and fee are fixtures;
+no transaction is sent. Select a destination chain, then use its contracts and tokens in the program:
 
 ```ts
-import { routes } from "@eco-incorp/sauce";
-
-// Both deadlines are ABSOLUTE unix timestamps, not durations: the chain compares
-// `block.timestamp > route.deadline`. And rewardDeadline must be >= deadline — a solver may fulfil
-// right up to the route deadline, so an earlier reward deadline is already refundable by then.
-// pot, portal, sourcePortal, creator, prover and recipient are addresses for YOUR deployment (as
-// bigints); the package ships no defaults for those. Token addresses it does ship — see the registry
-// note below.
-const now = BigInt(Math.floor(Date.now() / 1000));
-
-const built = routes
-  // the program: move 1 USDC on the destination chain, atomically, once the intent is filled
-  .openRoute("base", `function main() { USDC.transfer(${recipient}n, 1_000_000n); return 0n; }`, {
-    source: "ethereum", // the SOURCE chain — where the reward is posted
-    pot, // the Pot on the destination chain, which runs the program
-    portal, // the DESTINATION Portal — lands in route.portal
-    sourcePortal, // the SOURCE Portal — where the intent is published
-    creator,
-    prover,
-    deadline: now + 3600n,
-    rewardDeadline: now + 7200n,
-  })
-  .reward([{ token: usdc, amount: 1_000_000n }]);
-
-built.compiled.bytecode[0]; // the program
-built.intent; // the assembled Intent
-built.publishCalldata(); // calldata for sourcePortal — omit sourcePortal above and this throws
-```
-
-Common token addresses are already there: `routes.TOKEN_REGISTRY` carries probe-verified `USDC` and
-`WETH` for ethereum, optimism, polygon, base and arbitrum, the wrapped native under whatever symbol
-it actually reports (polygon's is `WPOL`), and `USDT` on ethereum and optimism only. `USDT` is absent
-elsewhere because a row is registered under a ticker only when the deployed contract's own `symbol()`
-string-equals it: the Tether-migrated polygon and arbitrum deployments return `USDT0`/`USD₮0` and
-fail that gate, and base's was never probed. So a missing row means "not provenance-verified under
-that ticker", NOT "not deployed" — `tokenDefines` overrides any key when you want one anyway.
-Ask `routes.knownTokenSymbols(requireChain('polygon'))` for what a chain actually carries. Look one up
-with `routes.registryTokenAddress(requireChain('base'), 'USDC')` (`requireChain` is a root export --
-see [Registries](#registries)), which returns a **`bigint`**, or `undefined` when that chain does not
-carry the symbol -- not a `0x` string, so format it yourself if you need one:
-`'0x' + address.toString(16).padStart(40, '0')` gives base USDC as
-`0x833589fcd6edb6e08f4c7c32d4f71b54bda02913`. `openRoute` also folds them in as
-ambient defines, so a route body can write `USDC.transfer(to, amount)` with no configuration at all.
-
-`routes.openRoute(destination, …)` is what the chain globals forward to, so
-`Base(sauce, options).reward(…)` is the same call. Those globals are installed on `globalThis` as a
-side effect of importing the package — they are **not** exports, so `import { Base }` fails. Opt out by setting `globalThis.__ECO_ROUTES_NO_GLOBALS__ = true` **before the first import** — it is
-read at module evaluation, so setting it afterwards is too late and silently does nothing. After the
-fact, `uninstallRouteGlobals()` is the one that works. Or just use `routes.openRoute` and ignore
-them.
-
-`.reward()` takes a token-amount array as above. A **bare bigint** is a NATIVE reward —
-`.reward(1_000_000n)` posts 1e6 wei of the source chain's gas token, not 1 USDC.
-
-> **Route bodies are unannotated SauceScript.** The SDK runs source rewrites over the body before
-> compiling, and those parse plain JS — `function main(): Uint256 { … }` is rejected. Annotated
-> SauceScript is fine when you call the compiler directly (below), just not through a route.
-
-## Building programs without writing SauceScript
-
-The `token`, `swap` and `deposit` namespaces emit SauceScript for you. `token` returns the source
-and its base dirs together; `swap` and `deposit` return a bare string, with base dirs as separate
-constants:
-
-```ts
-import { routes, token } from "@eco-incorp/sauce";
-
-// toSauceScript returns the baseDirs the program's own imports need, alongside the source
-const { source, baseDirs } = token.Token.transfer({
-  token: usdc,
-  to: recipient,
-  amount: 1_000_000n,
-}).toSauceScript("evm");
-
-const built = routes
-  .openRoute("base", source, { ...options, compile: { baseDirs: [...baseDirs] } })
-  .reward(reward);
-```
-
-The `baseDirs` matter: the emitted program does `import { IERC20 } from "./artifacts/IERC20.json"`,
-and a route supplies token base dirs automatically only when its own `USDC.transfer(…)` rewrite
-fires — which it does not for source a builder already emitted. Without them the compile fails on
-that import. Spread them: `toSauceScript`'s array is `readonly`, the option is not.
-
-`.source(target)` gives you the source alone if you are supplying `baseDirs` yourself.
-
-`swap` and `deposit` have no `toSauceScript`. They return the source directly, so pair each with its
-own constant:
-
-```ts
-import { routes, swap, deposit } from "@eco-incorp/sauce";
-
-routes
-  .openRoute("base", swap.swapSource(spec), {
-    ...options,
-    compile: { baseDirs: [...swap.SWAP_BASE_DIRS] },
-  })
-  .reward(reward);
-
-routes
-  .openRoute("base", deposit.depositSource(spec), {
-    ...options,
-    compile: { baseDirs: [...deposit.DEPOSIT_BASE_DIRS] },
-  })
-  .reward(reward);
-```
-
-`routes.compileSauceRoute` is the lower level underneath, if you want the compiled call without an
-intent — it returns `{ calls, compiled, source }` and has no `.reward()`.
-
-**On the SVM target this route path does not work.** `toSauceScript('svm')` emits `main` with typed
-account parameters — that parameter list _is_ the account manifest, so it cannot be dropped — and a
-route runs an acorn-based accessor rewrite that rejects annotations. `compile: { accessors: false }` gets past the parse, but a route then still requires
-`execution.code` naming an already-staged code account, so unless you have staged one, compile
-the source directly instead.
-
-## The compiler
-
-`/compiler` re-exports the published Rust/wasm SauceScript compiler:
-
-```ts
-import { compile } from "@eco-incorp/sauce/compiler";
-
-const { bytecode } = compile({
-  target: "evm", // or 'svm'
-  entry: "main.js",
-  resolve: (path) => bytesFor(path), // module BYTES (Uint8Array), or undefined
+import "@eco-incorp/sauce";
+import type { routes } from "@eco-incorp/sauce";
+
+// Offline fixtures. Read the destination Kitchen fee and use an Executor-owned Pot before use.
+const executionFee = 1_000n;
+const options: routes.IntentOptions = {
+  execution: {
+    pot: "0x1111111111111111111111111111111111111111",
+    engine: "0x2222222222222222222222222222222222222222",
+    value: executionFee,
+  },
+  nativeAmount: executionFee,
+  portal: "0x3333333333333333333333333333333333333333",
+  deadline: 2_000_000_000n,
+};
+
+const built = Base(() => {
+  USDC.approve(Uniswap.UniversalRouter, 1_000_000n);
+}, options).reward({
+  source: "ethereum",
+  creator: "0x4444444444444444444444444444444444444444",
+  prover: "0x5555555555555555555555555555555555555555",
+  deadline: 2_000_003_600n,
+  nativeAmount: 0n,
 });
-```
-
-`main` may take parameters. They arrive at run time as 32-byte big-endian words appended after the
-program, on **both** targets, so one program serves many argument sets — compile-time substitution is
-`defines` instead.
-
-That applies to a **direct `compile`**. A route slots `compiled.bytecode[0]` in as the whole cook
-ingredient and appends no argument tail, so a parameterized `main` in a route body reads past the end
-of its own ingredient. Use `defines` for routes, parameters for programs you assemble yourself.
-
-A `bytes` parameter is not padded — it occupies its fixed compile-time length, so the tail is not
-uniformly 32-byte words once one is present.
-
-Neither call returns an argument layout, so callers build the tail themselves. Mind which
-`CompileResult` you have — there are two, and they are not the same shape:
 
-|                | shape                                            | from                                  |
-| -------------- | ------------------------------------------------ | ------------------------------------- |
-| the compiler's | `{ bytecode: Uint8Array; manifest? }`            | a direct `compile`                    |
-| the SDK's      | `{ bytecode: Uint8Array[]; warnings: string[] }` | `built.compiled`, `compileSauceRoute` |
-
-The SDK's `bytecode` is a list of SEGMENTS, so `compiled.bytecode[0]` is the first segment, not the
-first byte. On **SVM** an `Account`-typed parameter is not a payload argument at all: it becomes the
-account manifest in the COMPILER's `CompileResult.manifest` — the route seam drops it
-(`rs-compile.ts`), so `built.compiled.manifest` is `undefined` with no error. An SVM caller that
-needs the manifest compiles through `svm/` directly.
-
-A `main` that falls off the end has no return type of its own, and a raw `compile` rejects it
-(`` `main` does not return on every path ``). Generated programs hit this whenever they fall through
-— which most do, though not all: a trailing `Token.balanceOf` emits a `return`, and annotating that
-one `: void` would break it. Either annotate it yourself (`function main(): void { … }`) or go through
-`routes.compileSauceRoute`, which annotates it for you. Note that one takes
-`(destination, sauce, execution, options)`: the execution seam is required, and an SVM destination
-needs an already-staged buffer, so it is the route path rather than a bare compile helper.
-
-## Registries
-
-129 protocols and 40 canonical chains ship with the package — 39 EVM plus Solana:
-
-```ts
-import { listProtocols, getProtocol, requireChain } from "@eco-incorp/sauce";
-
-listProtocols().length; // 129
-getProtocol("uniswap-v3"); // metadata: category, per-chain deployments, audit status
-// (ABIs live on the subpath: '@eco-incorp/sauce/protocols/uniswap-v3')
+console.log(built.hash().intentHash);
 ```
 
-`requireChain` and `getChain` read different registries: `CANONICAL_CHAINS` has all 40, while the
-`chains` export has 33 of the 39 EVM ones — `unichain`, `monad`, `sonic`, `ronin`, `plasma` and `ink`
-are canonical but absent from it, so `getChain(130)` is `undefined` where `requireChain('unichain')`
-resolves.
+The [quick start](https://unpkg.com/@eco-incorp/sauce@0.99.2/docs/guides/quick-start.md) explains the setup, and the [examples](https://unpkg.com/@eco-incorp/sauce@0.99.2/docs/examples/README.md) are checked
+against the SDK. The callback is compiled as source. Token and protocol names resolve on Base;
+values from surrounding JavaScript must be supplied through compile-time `defines`.
 
-```ts
-requireChain("base").id; // 8453 — reads CANONICAL_CHAINS (all 40)
-```
+Use `USDC.transfer(...)`, `USDC.balanceOf(...)`, `Token(address).approve(...)`, and linked protocol
+methods in the same program. `Uniswap.UniversalRouter` is the family alias for
+`UniswapV4.UniversalRouter`; available contracts and methods come from the
+[accessor registry](https://unpkg.com/@eco-incorp/sauce@0.99.2/docs/api/coverage.md). The compiler checks chain availability and ABI fidelity.
 
-## Subpaths
+## From a program to an intent
 
-| Subpath                                                    | What's there                                                               |
-| ---------------------------------------------------------- | -------------------------------------------------------------------------- |
-| `.`                                                        | routes DSL, `token`/`swap`/`deposit` builders, chain + protocol registries |
-| `/compiler`                                                | the SauceScript compiler                                                   |
-| `/actions`                                                 | routing-intent lowering (`actionsToSauce`), AMM/bridge action primitives   |
-| `/protocols/*`                                             | one protocol's ABIs and metadata, e.g. `/protocols/uniswap-v3`             |
-| `/chains`, `/deployments`                                  | canonical chain list; deployed contract addresses                          |
-| `/recipes`                                                 | shipped programs (settle, CCTP split-transfer) and their sources           |
-| `/svm`, `/svm/engine`, `/svm/verify`                       | SVM client, account resolution, engine harness, settle verification        |
-| `/recipes/settle.sauce.ts`, `/svm/recipes/settle.sauce.ts` | the settle program sources themselves, for partners reproducing bytes      |
-| `/evm/engine`                                              | EVM engine helpers                                                         |
-| `/verify`                                                  | decodes **legacy v1-grammar** settle programs. `viem`-only, browser-safe   |
-| `/skills`                                                  | AI skill files per protocol                                                |
+`Base(body, options).reward(reward)` compiles a destination program and constructs an Eco intent.
+The result exposes the intent, bytecode, hashes, and Portal transaction requests. Your application
+submits those requests. Direct Portal execution requires an Executor-owned Pot and native value for the Kitchen execution fee. Use `.nest(...)` to compose intents with separate executions and funding.
 
-`/verify` is for programs already on chain: it reads the v1 prologue that the retired TypeScript
-compiler emitted. Programs built by this SDK today are not v1-grammar, so it will refuse them.
+Use the direct Kitchen client for Solana execution. The legacy SVM intent helper is incompatible
+with the released gated engine; the Solana guide below describes this boundary.
 
-Verifying a program you built means recompiling it from the same source and comparing bytes.
-`/svm/verify` does exactly that for SVM settle programs; there is no EVM counterpart in the package
-today, so an EVM caller applies the technique themselves.
+- [Create and fund an intent](https://unpkg.com/@eco-incorp/sauce@0.99.2/docs/guides/intents.md)
+- [Compose nested intents](https://unpkg.com/@eco-incorp/sauce@0.99.2/docs/guides/nested-intents.md)
+- [Build programs with token, swap, deposit, and action helpers](https://unpkg.com/@eco-incorp/sauce@0.99.2/docs/guides/builders-and-actions.md)
+- [Execute on Solana](https://unpkg.com/@eco-incorp/sauce@0.99.2/docs/guides/solana.md)
+- [Verify settlement programs](https://unpkg.com/@eco-incorp/sauce@0.99.2/docs/guides/verification.md)
 
-## Development
+## Compiler and runtime
 
-```sh
-pnpm install
-pnpm build       # sdk + actions
-pnpm typecheck
-pnpm test
-```
+The SDK includes **`@eco-incorp/sauce-compiler`**, the Rust/WebAssembly SauceScript compiler, and
+exposes it through `@eco-incorp/sauce/compiler`. Compile directly when you need entry arguments,
+custom module resolution, or SVM account manifests. See the [compiler guide](https://unpkg.com/@eco-incorp/sauce@0.99.2/docs/guides/compiling.md)
+and [compiler API](https://unpkg.com/@eco-incorp/sauce@0.99.2/docs/api/compiler.md).
 
-## Publishing
+SauceScript supports contract calls, arithmetic, control flow, and composition within the
+[compiler's language subset](https://unpkg.com/@eco-incorp/sauce@0.99.2/docs/concepts/saucescript.md). A program executes atomically in one
+transaction on its target chain. Cross-chain intents coordinate separate transactions.
 
-Tag-driven, via [`.github/workflows/publish.yml`](.github/workflows/publish.yml):
+The root SDK and its compiler integration require Node.js **24 or newer**. The compiler dependency also has its
+own browser entry point. See [architecture](https://unpkg.com/@eco-incorp/sauce@0.99.2/docs/concepts/architecture.md) for how the SDK,
+compiler, and deployed runtime work together.
 
-```sh
-git tag v1.2.3 && git push origin v1.2.3
-```
+Current release pins: compiler **2.3.0**, EVM and SVM engines **1.0.1**, both Kitchens
+**1.0.0**. Release addresses do not establish on-chain deployment status.
 
-The workflow stamps the version from the tag inside the runner (`npm version --no-git-tag-version`)
-and publishes to **npmjs.com only**. The `version` in `package.json` is therefore not the source of
-truth and will read older than the latest release — that is expected.
+The EVM settle program compiles to **356 bytes** with a new verification hash. Recompile and
+invalidate cached programs when upgrading; to verify existing 362-byte payloads, pass their
+historical `{ hash, bytes: 362 }` pin to `validateSettleProgram` (see
+[verification](https://unpkg.com/@eco-incorp/sauce@0.99.2/docs/guides/verification.md)).

package/actions/dist/to-sauce.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"to-sauce.d.ts","sourceRoot":"","sources":["../src/to-sauce.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;GAkBG;AACH,OAAO,EAeL,KAAK,OAAO,EACZ,KAAK,IAAI,EAET,KAAK,IAAI,EACV,MAAM,WAAW,CAAC;AAInB,OAAO,KAAK,EACV,aAAa,EA2Cd,MAAM,YAAY,CAAC;AAkEpB,MAAM,WAAW,YAAY;IAC3B,oDAAoD;IACpD,QAAQ,CAAC,KAAK,EAAE,SAAS,IAAI,EAAE,CAAC;IAChC;;;;;;OAMG;IACH,QAAQ,CAAC,MAAM,EAAE,IAAI,CAAC;CACvB;AAMD,qEAAqE;AACrE,wBAAgB,oBAAoB,CAAC,OAAO,EAAE,SAAS,aAAa,EAAE,GAAG,MAAM,CAkC9E;AAED,wBAAgB,cAAc,CAAC,OAAO,EAAE,SAAS,aAAa,EAAE,GAAG,UAAU,CAI5E;AAED,wBAAgB,aAAa,CAAC,MAAM,EAAE,aAAa,GAAG,UAAU,CAE/D;AAED;;;;;;;;GAQG;AACH,wBAAgB,WAAW,CACzB,IAAI,EAAE,OAAO,EACb,MAAM,EAAE,aAAa,EACrB,QAAQ,EAAE,IAAI,EACd,WAAW,EAAE,OAAO,GACnB,YAAY,CA2Fd"}
+{"version":3,"file":"to-sauce.d.ts","sourceRoot":"","sources":["../src/to-sauce.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;GAkBG;AACH,OAAO,EAeL,KAAK,OAAO,EACZ,KAAK,IAAI,EAET,KAAK,IAAI,EACV,MAAM,WAAW,CAAC;AAInB,OAAO,KAAK,EACV,aAAa,EA2Cd,MAAM,YAAY,CAAC;AAkEpB,MAAM,WAAW,YAAY;IAC3B,oDAAoD;IACpD,QAAQ,CAAC,KAAK,EAAE,SAAS,IAAI,EAAE,CAAC;IAChC;;;;;;OAMG;IACH,QAAQ,CAAC,MAAM,EAAE,IAAI,CAAC;CACvB;AAMD,qEAAqE;AACrE,wBAAgB,oBAAoB,CAAC,OAAO,EAAE,SAAS,aAAa,EAAE,GAAG,MAAM,CAiC9E;AAED,wBAAgB,cAAc,CAAC,OAAO,EAAE,SAAS,aAAa,EAAE,GAAG,UAAU,CAI5E;AAED,wBAAgB,aAAa,CAAC,MAAM,EAAE,aAAa,GAAG,UAAU,CAE/D;AAED;;;;;;;;GAQG;AACH,wBAAgB,WAAW,CACzB,IAAI,EAAE,OAAO,EACb,MAAM,EAAE,aAAa,EACrB,QAAQ,EAAE,IAAI,EACd,WAAW,EAAE,OAAO,GACnB,YAAY,CA2Fd"}

package/actions/dist/to-sauce.js

@@ -74,12 +74,11 @@ export function actionsToSauceSource(actions) {
     for (let i = 0; i < actions.length; i++) {
         const action = actions[i];
         const amountIn = resolveAmountIn(getExplicitAmount(action), action.amountRef, lastOutputSlot);
-        // Determine if we need to store the output
+        const nextAction = actions[i + 1];
         const needsStore = action.saveOutputAs !== undefined ||
-            actions
-                .slice(i + 1)
-                .some((a) => getExplicitAmount(a) === undefined && a.amountRef === undefined) ||
-            actions.slice(i + 1).some((a) => a.amountRef === action.saveOutputAs);
+            (nextAction !== undefined &&
+                getExplicitAmount(nextAction) === undefined &&
+                nextAction.amountRef === undefined);
         const result = buildAction(emit, action, amountIn, needsStore);
         body.push(...result.stmts);
         if (needsStore) {

package/dev-tools/README.md

@@ -1,175 +1,16 @@
-# Sauce Dev Tools
+# Sauce example projects
 
-Development environment for writing and executing SauceScript programs on local or forked Ethereum networks.
+To build an application with Sauce, install the SDK:
 
-## Setup
-
-```bash
-pnpm install
-```
-
-## Quick Start
-
-```bash
-# Start a local Hardhat network with Sauce deployed
-npm run start:local
-
-# Or start a forked mainnet (requires FORK_URL env var)
-FORK_URL=https://eth-mainnet.g.alchemy.com/v2/YOUR_KEY npm run start:fork
-
-# Run a SauceScript
-npm run sauce sauce/call.js [arg1] [arg2] ...
-
-# Stop the network
-npm run stop
-```
-
-## Scripts
-
-| Command                | Description                                  |
-| ---------------------- | -------------------------------------------- |
-| `npm run start:local`  | Start local Hardhat network and deploy Sauce |
-| `npm run start:fork`   | Start forked mainnet and deploy Sauce        |
-| `npm run stop`         | Stop the running network                     |
-| `npm run sauce <file>` | Compile and execute a SauceScript            |
-| `npm run build`        | Compile TypeScript                           |
-
-## Writing SauceScript
-
-SauceScript files (`.js`) use JavaScript syntax that compiles to Sauce VM bytecode.
-
-### Basic Example
-
-```javascript
-function main() {
-  return 42;
-}
-```
-
-### With Arguments
-
-Arguments are passed as parameters to `main()`:
-
-```javascript
-function main(a, b) {
-  return a + b;
-}
-```
-
-Run with: `npm run sauce script.js 10 20`
-
-### Contract Calls
-
-Import ABIs from npm packages and call external contracts:
-
-```javascript
-import { IUniswapV3Factory } from "@uniswap/v3-core/artifacts/contracts/interfaces/IUniswapV3Factory.sol/IUniswapV3Factory.json";
-
-function main(factoryAddress, token0, token1) {
-  const factory = IUniswapV3Factory.at(factoryAddress);
-  return factory.getPool(token0, token1, 3000);
-}
+```sh
+pnpm add @eco-incorp/sauce
 ```
 
-Run with:
-
-```bash
-npm run sauce sauce/call.js \
-  0x1F98431c8aD98523631AE4a59f267346ea31F984 \
-  0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2 \
-  0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48
-```
-
-## Arguments
-
-Positional arguments are RUNTIME values for `main`'s parameters. They are appended to the compiled
-program as ABI-encoded words, so the program bytes are the same whatever you pass. They parse as:
-
-- Decimal numbers: `123`, `456`, `-1`
-- Hex values: `0x1a2b3c...` (over 32 bytes: passed as `bytes`)
-
-A `NAME=VALUE` operand is a COMPILE-TIME define instead: it replaces the module's own `const NAME`
-and is constant-folded, so a different value is a different program.
-
-```javascript
-const AMOUNT = 0n; // overridden by AMOUNT=4242
-
-function main(a) {
-  return a + AMOUNT; // `a` comes from a positional arg
-}
-```
-
-Run with: `npm run sauce script.js 10 AMOUNT=4242`. The two are told apart by shape — a define's
-name is an identifier, which no integer or hex literal can look like — so they may be interleaved.
-
-A define's VALUE is one unsigned 256-bit word. `0x`-hex is passed through as written; any other
-spelling JavaScript's `BigInt` reads (decimal, `0b`/`0o`, a leading `+`, leading zeros, surrounding
-whitespace) is normalized to decimal, because the compiler's own define grammar accepts only decimal
-or `0x`-hex. An empty, all-whitespace, negative, or non-integer value is rejected at the CLI.
-
-## Project Structure
-
-```
-dev-tools/
-├── scripts/
-│   ├── run.ts           # SauceScript runner
-│   ├── deploy.ts        # Sauce contract deployment
-│   ├── start-local.sh   # Start local network
-│   ├── start-fork.sh    # Start forked network
-│   └── stop-local.sh    # Stop network
-├── src/
-│   ├── contracts.ts     # Contract helpers
-│   └── runner.ts        # Compilation & execution
-├── sauce/
-│   ├── js/              # Example SauceScripts (JavaScript)
-│   │   ├── add.js
-│   │   ├── call.js
-│   │   ├── erc20.js
-│   │   ├── example.js
-│   │   └── fibonacci.js
-│   └── ts/              # Example SauceScripts (TypeScript)
-│       ├── add.ts
-│       ├── call.ts
-│       ├── erc20.ts
-│       ├── example.ts
-│       └── fibonacci.ts
-├── test/
-│   ├── examples.test.ts # Compilation tests for all examples
-│   └── e2e.test.ts      # End-to-end integration tests
-└── artifacts/           # Sauce engine contract artifact
-```
-
-**Note:** The Sauce contract artifact is loaded from `engine/out/Sauce.sol/Sauce.json`. Run `forge build` in the engine folder if it doesn't exist.
-
-## Local SVM e2e
-
-`src/svm-local.ts` runs a compiled SVM program through the **real gated engine** in-process — no
-validator, no credentials — using the same LiteSVM + kitchen + Pot orchestration the SDK's own suites
-use (`sdk/test/svm/engine-harness.ts`). It is a repo-dev harness: `litesvm` is a dev dependency here,
-like `hardhat` is for `start:local`. `test/svm-local.test.ts` is a runnable example.
-
-```ts
-import { compile } from "@eco-incorp/sauce/compiler";
-import { runSvmProgramLocally } from "../src/svm-local";
-
-const { bytecode, manifest } = compile({ target: "svm", entry: "main.js", resolve });
-const { err, logs } = await runSvmProgramLocally(bytecode, manifest, { resolution: {} });
-if (err) throw new Error(`cook rejected: ${err}\n${logs.join("\n")}`);
-```
-
-`resolution` maps the manifest's account refs to addresses (empty for a self-contained program). A
-released engine refuses anything that did not arrive through a kitchen cook, so this asserts the gate
-accepts what you built. It needs the engine binaries present — run
-`pnpm --filter './sdk' sync-engine-artifacts --fetch-v12-engines`, and it skips when they are absent.
-Run one program at a time (await each call): `runSvmProgramLocally` routes the client's RPC by
-swapping `globalThis.fetch` for the length of a run, so overlapping calls would collide.
-
-**Consumers** get the piece they cannot fetch themselves — the engine binaries — shipped in the
-package and located by `@eco-incorp/sauce/svm/engine-artifacts` (`svmEnginePath` / `svmKitchenPath`).
-With those plus their own `litesvm`, `svm-local.ts` is the reference harness to build local e2e tests
-of their own SVM programs.
-
-## Requirements
+Follow the [quick start](https://unpkg.com/@eco-incorp/sauce@0.99.2/docs/guides/quick-start.md)
+and [executable examples](https://unpkg.com/@eco-incorp/sauce@0.99.2/docs/examples/README.md)
+for compiling programs and constructing Eco intents in your own project. You can also open the installed manual at `node_modules/@eco-incorp/sauce/docs/README.md`.
 
-- Node.js 18+
-- pnpm
+The `sauce-dev-tools` scaffold contains older local deployment and execution scripts. Those scripts
+target an earlier EVM contract interface and are incompatible with current Kitchen/Pot deployments.
+Use the SDK's [execution guides](https://unpkg.com/@eco-incorp/sauce@0.99.2/docs/guides/compiling.md)
+for current programs.

package/docs/README.md

@@ -0,0 +1,39 @@
+# Sauce documentation
+
+Build programmable EVM and Solana transactions with `@eco-incorp/sauce`, and compose EVM
+executions into Eco intents. Solana execution uses the direct Kitchen client; the
+[legacy SVM intent helper](guides/solana.md#svm-destinations-in-eco-intents) is incompatible
+with the released engine.
+
+**New here?** Follow the [quick start](guides/quick-start.md), explore
+[token and protocol globals](guides/protocols-and-tokens.md), then
+[create and fund an intent](guides/intents.md). Complete programs live in the
+[examples](examples/README.md).
+
+## Concepts
+
+| Read                                     | Learn                                                                                   |
+| ---------------------------------------- | --------------------------------------------------------------------------------------- |
+| [Architecture](concepts/architecture.md) | How the SDK, compiler package, on-chain engine, and Eco intents fit together            |
+| [SauceScript](concepts/saucescript.md)   | Execution model, source closures, supported language constructs, and target differences |
+
+## Guides
+
+| Task                                                  | Guide                                                  |
+| ----------------------------------------------------- | ------------------------------------------------------ |
+| Install and build your first intent                   | [Quick start](guides/quick-start.md)                   |
+| Use `USDC`, `Token(address)`, and protocol namespaces | [Protocols and tokens](guides/protocols-and-tokens.md) |
+| Construct, fund, and inspect an intent                | [Eco intents](guides/intents.md)                       |
+| Compose multiple intent executions                    | [Nested intents](guides/nested-intents.md)             |
+| Compile directly and encode runtime arguments         | [Compiling programs](guides/compiling.md)              |
+| Generate programs from structured inputs              | [Builders and actions](guides/builders-and-actions.md) |
+| Plan accounts, stage code, and execute on SVM         | [Solana](guides/solana.md)                             |
+| Check a settlement payload                            | [Verification](guides/verification.md)                 |
+
+## Reference and examples
+
+- [API entry points](api/README.md): published imports and where to find each feature.
+- [Compiler API](api/compiler.md): compiler options, output metadata, and argument encoding.
+- [Routes API](api/routes.md): execution options, intent builders, and Portal helpers.
+- [Registry coverage](api/coverage.md): protocols, source globals, tokens, and chain registries.
+- [Examples](examples/README.md): complete examples and how they are validated.