@eco-foundation/api-schemas 0.3.0 → 0.4.1

package/README.md

@@ -4,7 +4,7 @@ Zod-first schemas, error catalog, golden fixtures, and generated OpenAPI 3.1 for
 API. The Zod schemas are the source of truth; everything else (OpenAPI, fixtures, plain types)
 is generated from or gated against them.
 
-Today the package covers **13 endpoints across 12 paths**, **33 error codes** (51 namespaced
+Today the package covers **13 endpoints across 12 paths**, **37 error codes** (51 namespaced
 legacy references), and **19 golden fixtures**.
 
 ## Install
@@ -14,17 +14,309 @@ While the package is 0.x, pin the patch range or the exact version:
 ```json
 {
   "dependencies": {
-    "@eco-foundation/api-schemas": "~0.3.0"
+    "@eco-foundation/api-schemas": "~0.4.1"
   }
 }
 ```
 
 **Never write `^0`.** npm resolves `^0.x` as `>=0.0.0 <1.0.0`, so it silently accepts every
-future breaking `0.y` — it is not a pin at all. Use `~0.3.0` or the exact `0.3.0`.
+future breaking `0.y` — it is not a pin at all. Use `~0.4.1` or the exact `0.4.1`.
 
 A matching version string is not evidence of a matching artifact: also compare
 `V1_SCHEMA_DIGEST` (see [Invariants](#invariants-enforced-in-ci)). Two builds both called
-`0.3.0` — a registry copy and a `file:` tarball, say — can carry different schemas.
+`0.4.0` — a registry copy and a `file:` tarball, say — can carry different schemas.
+
+`zod` is a peer dependency, and since `0.3.1` an **optional** one — required only if you import a
+zod-bearing entry point. Which case you are in is decided entirely by your imports; see
+[Consumers](#consumers).
+
+## Migrating 0.4.0 -> 0.4.1
+
+Purely additive; no schema, wire, or digest change. `V1_SCHEMA_DIGEST` is UNCHANGED, so this is
+not a coordinated-rollout release — a fleet may run 0.4.0 and 0.4.1 side by side.
+
+**Added — the two conformance skip reasons are exported constants.**
+`SIDE_EFFECT_SKIP_REASON` and `DRAFT_SKIP_REASON` are now named exports of the `./testing`
+subpath. They were previously inline literals in this package's own spec, which meant a consumer
+pinning them had to copy the strings and had no way to notice a rewording — the published tarball
+ships `dist/`, never the sources those literals lived in. Import them instead of copying:
+
+```ts
+import { DRAFT_SKIP_REASON, SIDE_EFFECT_SKIP_REASON } from '@eco-foundation/api-schemas/testing';
+```
+
+This is also the first release cut from `eco/eco-api-schemas`, the package's own repository. It
+previously shipped from a pnpm workspace inside `eco-incorp/router`; nothing about the published
+artifact's contents or layout changed with the move.
+
+## Migrating 0.3.1 -> 0.4.0
+
+`0.3.1` was never published, so **`0.4.0` is the upgrade from `0.3.0`** and carries `0.3.1`'s
+change as well. It is a BREAKING release under 0.x semver (breaking bumps the minor while the
+major is 0), and it carries ONE breaking change plus two additive ones. The break is scoped to
+consumers that read the **SVM** branch of a quote's funding transaction; EVM quotes are
+byte-identical to `0.3.0`. Nothing here rejects a request body `0.3.0` accepted, and no existing
+code, status, or `legacyCodes` mapping moved.
+
+**`V1_SCHEMA_DIGEST` MOVES.** Both digest inputs changed (`errors/catalog.lock.json` gained four
+codes, and `openapi/v1.json` was regenerated for both the instruction list and the new response
+member), so the value is now
+`1d8e88e957795b23e1317dc1e3783fd64bf79b756e3f28bd40e02b047542d790` — was
+`3d41b4893b54e77e9ea56c24af1d7a1e9de0685ee911e497834dcd746e72c1f6` on `0.3.0`/`0.3.1`. Every
+consumer running `assertNoSkew` must move to the new value **in the same rollout**: the check
+compares services against each other, so a fleet running two versions fails it by design.
+
+**THE BREAKING HALF FIRST (PAR-576), then the two additive ones (PAR-601, PAR-605).**
+
+**The SVM funding transaction is now an ORDERED LIST OF INSTRUCTIONS, not a serialized
+transaction.** `SvmTransactionSchema` dropped `serializedTransaction` and gained `feePayer`
+and `instructions`:
+
+```diff
+-{ "kind": "svm", "chainId": 1399811149, "serializedTransaction": "<base64 tx>" }
++{
++  "kind": "svm",
++  "chainId": 1399811149,
++  "feePayer": "<base58 pubkey>",
++  "instructions": [
++    {
++      "programId": "<base58 pubkey>",
++      "accounts": [{ "pubkey": "<base58>", "isSigner": true, "isWritable": true }],
++      "data": "<base64: 8-byte Anchor discriminator + Borsh args>"
++    }
++  ]
++}
+```
+
+`serializedTransaction` is not deprecated-but-accepted; the key is gone and a body carrying
+it fails `QuoteResponseSchema`. That is deliberate — response schemas are `looseObject`, so
+leaving the old key valid would let a consumer keep reading a field the server no longer
+fills and get `undefined` at signing time instead of a named rejection.
+
+**Why the break, since `0.3.1` never shipped a working SVM quote:** a serialized Solana
+transaction embeds a recent blockhash, valid for roughly 150 slots — 60 to 90 seconds. Every
+realistic caller flow (fetch the quote, render it, let a human review it, sign, submit) is
+longer than that, so the transaction was already dead when the caller signed it, the failure
+surfaced as an opaque `BlockhashNotFound`, and the schema carried no field with which to
+refresh it. The old shape was undeliverable rather than merely awkward. Instructions have no
+expiry: the caller fetches its own blockhash at signing time, which is how every Solana
+wallet already works.
+
+**What the caller now owns.** In order:
+
+1. Fetch a recent blockhash (or use a durable nonce).
+2. Compile `instructions` **in the given order** into a legacy or v0 message, with `feePayer`
+   as the fee payer.
+3. Sign with every key marked `isSigner` — `feePayer` is always one of them.
+4. Choose its own compute-unit limit and priority fee. None is prescribed.
+
+**Two contracts that are load-bearing, and that no schema can check for you:**
+
+- **`instructions[].accounts` is POSITIONAL.** Solana resolves an instruction's accounts by
+  INDEX. Pass the array through verbatim — do not sort it, deduplicate it, drop an account
+  that also appears in another instruction, or regroup signers and writables. A permuted list
+  is a different instruction that still validates, and it fails on-chain with an unhelpful
+  message (a permuted Eco Portal `fund` reports `InvalidVault`, `InvalidAta` or
+  `InvalidTokenTransferAccounts` depending on which pair swapped). The schema does not know
+  which program `programId` is, so it cannot police this; it validates each entry's shape and
+  the PRESENCE of both privilege flags, and nothing more.
+- **`instructions` may exceed one transaction, and that is not an error.** A public-visibility
+  quote emits `Portal.publish` (carrying the whole route preimage) plus `Portal.fund`, and
+  Solana's packet ceiling is 1232 bytes: an EVM-destination route with one token and one call
+  ABI-encodes to about 600 bytes, so `publish` alone is roughly 710 bytes of instruction data,
+  `fund` adds about 173, and ten unique pubkeys add about 320 — over the ceiling before
+  headers. The instructions are independent on-chain, so submit them in the given order across
+  two transactions, or compile a v0 message against your own address-lookup table. Splitting is
+  safe; reordering is not.
+
+**No address-lookup-table references are emitted.** An ALT must already exist on-chain and
+eco-router has no Solana RPC with which to create or read one, so every account is inline and
+the message compiles as legacy. Bring your own ALT if you want a v0 message; the account metas
+are unaffected by that choice.
+
+**`isSigner` and `isWritable` are REQUIRED booleans** on every account meta, never optional and
+never defaulted. Both directions of a wrong value are a real failure — a missing `isWritable`
+makes the program's write revert, a missing `isSigner` makes Anchor's `Signer` constraint reject
+the instruction — so absence is a 400 rather than a guess.
+
+**New, additive:** the `Base64Bytes` primitive (standard padded base64; URL-safe, unpadded, and
+whitespace-bearing values are rejected, because Node's decoder silently accepts all three and
+strict decoders do not), plus the `SvmAccountMetaSchema` / `SvmInstructionSchema` schemas and the
+zod-free `V1SvmAccountMeta` / `V1SvmInstruction` aliases.
+
+**Unchanged:** the EVM branch, every request schema, and the error catalog — it gained NO new
+codes from this change.
+
+**TVM STAYS UNREPRESENTABLE, AND THAT IS NOW A DECISION RATHER THAN AN OPEN QUESTION.** Tron is
+OUT OF SCOPE for `/v1` funding. `FundingTransactionSchema` has no `tvm` member, a `kind: "tvm"`
+transaction fails `QuoteResponseSchema`, and eco-router answers `chain-not-supported` (422) for a
+Tron-source funding quote. Do not read the SVM lane as a precedent that a `tvm` branch is queued
+behind it: adding one would be a breaking wire change with its own migration note, and nothing
+here commits `/v1` to that surface.
+
+**Added — `./package.json` is an exported subpath.**
+`require('@eco-foundation/api-schemas/package.json')` previously threw
+`ERR_PACKAGE_PATH_NOT_EXPORTED`, which broke tooling that reads a dependency's manifest for
+its version. Nothing else changes; it is purely additive. (`prepack` now also rebuilds
+`dist/` on a manual `npm pack`/`npm publish`, which affects publishing rather than
+consuming.)
+
+**Added — the `errors` problem extension (per-field caller faults).**
+
+```json
+{
+  "type": "https://.../invalid-request",
+  "title": "Invalid request",
+  "status": 400,
+  "code": "invalid-request",
+  "detail": "source.chainId: must be a supported chain id",
+  "errors": [{ "field": "source.chainId", "detail": "must be a supported chain id" }]
+}
+```
+
+`errors` is **OPTIONAL**: an `invalid-request` for a body that is not JSON at all has no
+field to name, so absence is legal and means exactly that. `field` names the offending
+input in YOUR terms — the path into what you sent, with **no `body.`/`query.` prefix**:
+`source.chainId`, `funder`, `limit`. `detail` obeys the same free-text policy as the
+problem's own `detail`.
+
+Because there is no prefix, `field` alone does not say whether the value came from the body
+or the query string. Every /v1 endpoint takes its parameters in exactly one of the two, so
+**key on the route plus `field`**, not on `field` alone.
+
+**`errors` is NOT `solverErrors`.** They sit adjacent and answer different questions:
+`errors` is your own fault (a field you sent, and naming it is how you fix it);
+`solverErrors` is a downstream solver's failure, which you did not cause and usually
+cannot fix. A body never needs both to explain one failure. The name `errors` is the
+de-facto RFC 9457 validation extension (Spring `ProblemDetail`, ASP.NET
+`ValidationProblemDetails`), so it is probably already in your SDK.
+
+`problemFromZodError` populates it from the issues it already renders into `detail`, so
+you get the machine-readable form for free — bounded to 8 entries, and an issue with no
+path is omitted rather than given a placeholder field.
+
+**Added — `chains`, REQUIRED on the deposit-address create response (PAR-571).**
+
+```json
+{
+  "id": "deposit-address:0x…",
+  "chains": [
+    { "chainId": 8453, "source": true, "registration": "registered" },
+    { "chainId": 137, "source": false, "registration": "registered" }
+  ]
+}
+```
+
+Four identifiers, two pairs, and the members of a pair are one word apart — pair them
+carefully, because the wrong pairing still compiles.
+**`DepositAddressChainRegistrationSchema`** is the ENUM and
+**`DepositAddressChainRegistration`** its inferred type;
+**`DepositAddressChainStatusSchema`** is the OBJECT that `chains[]` holds and
+**`DepositAddressChainStatus`** its inferred type. The `Schema` suffix is what distinguishes
+schema from type — the bare name is always the type.
+
+**REQUIRED on the create response, and absent from the shared record.**
+`DepositAddressCreateResponseSchema` is now `DepositAddressSchema.extend({ chains })`
+rather than a bare alias. If you read a create response, `chains` is always there; if you
+read a lookup page, it is never there. That is deliberate — an optional member on the
+shared record would make one key mean "bug" on one lane and "correct" on the other, with
+nothing in the type to distinguish them. **Migration:** a server build that returns 201
+without `chains` now fails its own response schema.
+
+`.min(1)`: the source chain is always attempted, so an empty array could only mean the
+producer lost the outcome — and an empty `chains` reads as "no chain is live", the
+opposite of what a 201 means.
+
+**Two constraints are enforced beyond the shape:** exactly one entry has `source: true`,
+and no `chainId` repeats. `source` is what tells you which chain the top-level
+`depositAddress` is definitely correct for, so zero or two source entries would be a
+silently wrong answer about where funds may go. Errors name the field and carry the count
+(`chains must contain exactly one source entry, found 2`); a duplicate is reported at the
+offending index.
+
+These live in a `superRefine`, which means **they do not appear in `openapi/v1.json`** —
+`z.toJSONSchema` drops refinements. Validate against the zod schema if you need them
+enforced; a client generated from the OpenAPI document alone will accept a body the zod
+schema rejects.
+
+**What `.min(1)` does NOT give you:** it rejects an empty array, not an incomplete one. A
+schema cannot know which chains should be present. Completeness is a producer guarantee —
+deposit-addresses builds the array from the full attempted set — not something validated
+here.
+
+Two things to read correctly:
+
+- **`registration` is binary today.** The enum exists so `'pending'` can be added
+  additively if a retry lane is ever built; there is no such lane, so do not look for a
+  third state.
+- **`registration: "registered"` means the chain-state ROW EXISTS.** That row is what the
+  polling services rebuild their watch set from at boot. It does NOT promise the
+  in-process publish succeeded, so it can **lead the live process by one restart**. Read
+  it as "known, and picked up no later than the next boot" — never "being watched right
+  now". It is also **not** `isDeployed`, which is CREATE2 deployment of the address
+  contract: `isDeployed: false` does not mean "do not send funds here".
+
+New zod-free aliases: `V1DepositAddressChainStatus` and `V1DepositAddressCreateResponse`.
+
+**Added — four error codes for the transport statuses `/v1` could not answer (PAR-601).**
+
+| Code                     | Status | Reached by                                                   |
+| ------------------------ | ------ | ------------------------------------------------------------ |
+| `endpoint-not-found`     | 404    | a typo'd path — no `/v1` endpoint at that path               |
+| `method-not-allowed`     | 405    | a real path, wrong HTTP method                               |
+| `request-too-large`      | 413    | body bytes over the limit, or too many urlencoded parameters |
+| `unsupported-media-type` | 415    | an unsupported media type, charset, or content encoding      |
+
+All four are `audience: 'all'` and carry no `legacyCodes`. Before `0.4.0` these four statuses
+had no catalog code at all, so a `/v1` response at any of them fell through to eco-router's
+legacy envelope — a partner SDK keying on `type`/`code` saw neither.
+
+**The one newly-possible rejection, and it is consumer-side.** `V1ProblemSchema` cross-checks a
+KNOWN code's `status`/`type` against the catalog and ignores codes it does not know. These four
+are now known, so a problem body carrying one of them with a CONTRADICTING status or type stops
+parsing where `0.3.0` tolerated it as "a newer server". If you already emit any of these four
+spellings, confirm the status and `type` match the table above before upgrading.
+
+**`endpoint-not-found` is NOT `token-not-found`.** Both are 404. A consumer branching on status
+alone will conflate "that path does not exist" with "that token is unknown on that chain" —
+branch on `code`.
+
+**Exhaustive `switch` over `V1ErrorCode` will not compile until you handle the four.** That is
+the intended signal, not a break to work around.
+
+**Added — `/v1/chains` may advertise the deployment's effective page bounds (PAR-605).**
+
+```json
+{
+  "chains": [{ "chainId": 8453, "...": "..." }],
+  "limits": { "paging": { "maxLimit": 25, "defaultLimit": 10 } }
+}
+```
+
+`limits` is **OPTIONAL**, and **absence has a documented meaning: the published `PagingFields`
+bounds apply** — cap `STATUS_PAGE_MAX_LIMIT` (50), default `STATUS_PAGE_DEFAULT_LIMIT` (20),
+which is exactly the `0.3.0` contract. So a server that does not populate it stays correct and
+a consumer needs no new branch. When `limits` IS present, `paging` is required inside it:
+`limits: {}` is rejected rather than read as "bounds advertised, none given".
+
+An operator may only NARROW, so both numbers are capped at the canon values, and
+`defaultLimit <= maxLimit` is enforced — a deployment cannot advertise a first page it would
+reject on request.
+
+Read it if you choose page sizes programmatically. The 400 that names the bound is unchanged;
+this exists so the bound is discoverable in one request rather than one rejection.
+
+**Scope — it is the bound of the service serving that document.** eco-router serves
+`/v1/chains` and `/v1/intents/status` from one config, so its answer covers both.
+`/v1/deposit-addresses/status` and the `/v1/deposit-addresses` lookup are the
+deposit-addresses service's, paged from its own config; `DepositAddressLookupResponseSchema`
+deliberately does not carry this member.
+
+**Carried over from the unpublished `0.3.1`: the `zod` peer is now `optional`.** The range is
+unchanged (`^4.3.0`). It only widens the set of installs that resolve cleanly — a consumer
+importing only the zod-free entry points (`./v1/signature`, `./v1/types`) no longer gets a
+permanently wrong unmet-peer warning. `optional` suppresses the warning only when zod is
+ABSENT: a consumer holding a zod outside `^4.3.0` still sees a version-mismatch warning.
 
 ## Migrating 0.2.0 -> 0.3.0
 
@@ -134,11 +426,32 @@ must: it is the artifact identity, not the version string.
 | solver-v2 (Zod 3 — must not upgrade) | `import type { V1QuoteResponse } from '@eco-foundation/api-schemas/v1/types'` + fixtures | ZERO zod at runtime and in the `.d.ts` |
 | any consumer needing `signatureHash` | `import { signatureHash } from '@eco-foundation/api-schemas/v1/signature'`               | NONE — that subpath is zod-free        |
 
+**Do you need `zod`? Only if you import a zod-bearing entry point.** Since `0.3.1` the peer is
+declared optional (`peerDependenciesMeta: { zod: { optional: true } }`), because for two of the
+published entry points it is genuinely not needed:
+
+- **Needs `zod` (`^4.3.0`):** the bare package name `.`, `./testing`, and anything reached
+  through the `v1` namespace on either. These load schema modules, and their `.d.ts` names zod
+  types.
+- **Needs NO `zod`:** `./v1/signature` (runtime code importing `@noble/hashes` and nothing else)
+  and `./v1/types` (plain `type` aliases, erased at compile time). A consumer whose imports stay
+  inside these two installs only `@noble/hashes` — declaring zod would be dead weight.
+
+Read `optional` narrowly: it says zod **may be absent**, not that any zod version works. pnpm
+suppresses the unmet-peer warning only when zod is MISSING (verified against pnpm 10.16); a
+consumer that HAS a zod outside `^4.3.0` — solver-v2, on zod 3 — still sees
+`unmet peer zod@^4.3.0: found <version>`, since that is a version mismatch rather than a missing
+peer. Suppressing that one is the consumer's own call
+(`pnpm.peerDependencyRules.allowedVersions`), and it is safe exactly while its imports are
+limited to the two zod-free subpaths above. The range itself cannot be widened — the schemas
+require Zod 4.
+
 Zod-major compatibility is the reason there are two interfaces, not one:
 
 - **Zod-4 consumers** (eco-router `^4.4.3`, deposit-addresses `^4.3.5`) import the schemas
-  directly. Since `0.2.0`, `zod` is a **`peerDependency` with a range (`^4.3.0`)**, not a
-  hard-pinned dependency: the consumer's own single copy satisfies it. The previous exact
+  directly. Since `0.2.0`, `zod` is a **`peerDependency` with a range (`^4.3.0`)** — optional
+  since `0.3.1` — not a hard-pinned dependency: the consumer's own single copy satisfies it. For
+  these consumers optional changes nothing; they must still install zod. The previous exact
   `dependencies` pin at `4.4.3` materialised a SECOND nested zod for every consumer not on that
   exact version, and two zod instances in one type graph is the documented failure — `TS2345` on
   `_zod.version.minor` when a package schema is passed to a local `z.ZodType<T>`, and `tsc`
@@ -264,12 +577,13 @@ Two `catalog:check` outcomes are NOT failures and must not be confused with each
 
 ## Publishing
 
-Tag `api-schemas-v<version>` (must equal `package.json` version) — the `publish-api-schemas`
-workflow verifies and publishes. It fails with `::error::tag version <x> != package version <y>`
+Tag `v<version>` (must equal `package.json` version) — the `publish` workflow verifies and
+publishes. It needs the `NPM_TOKEN` repo secret (an npm automation token with publish rights on
+`@eco-foundation`). It fails with `::error::tag version <x> != package version <y>`
 if the two drift, so a stale tag can never publish a mismatched artifact.
 
 Semver: breaking schema change = major, additive = minor; consumers pin minor. **While the
-package is 0.x, "pin minor" means `~0.3.0` or the exact `0.3.0` — never `^0`** (see
+package is 0.x, "pin minor" means `~0.4.1` or the exact `0.4.1` — never `^0`** (see
 [Install](#install)). Consumers additionally compare `V1_SCHEMA_DIGEST`: a matching version
 string is not evidence of a matching artifact. `/v1/routes` is draft-tagged and exempt until its
 stability flips.

package/dist/fixtures/v1/deposit-addresses-create.response.gateway-erc20.json

@@ -15,6 +15,18 @@
         "destinationAddress": "0x1111111111111111111111111111111111111111",
         "destinationChainId": 137,
         "expiresAt": null,
-        "createdAt": 1767225000
+        "createdAt": 1767225000,
+        "chains": [
+            {
+                "chainId": 8453,
+                "source": true,
+                "registration": "registered"
+            },
+            {
+                "chainId": 137,
+                "source": false,
+                "registration": "registered"
+            }
+        ]
     }
 }

package/dist/generated/build-digest.json

@@ -1,5 +1,5 @@
 {
-    "digest": "3d41b4893b54e77e9ea56c24af1d7a1e9de0685ee911e497834dcd746e72c1f6",
+    "digest": "1d8e88e957795b23e1317dc1e3783fd64bf79b756e3f28bd40e02b047542d790",
     "inputs": [
         "errors/catalog.lock.json",
         "openapi/v1.json"

package/dist/index.d.ts

@@ -3,4 +3,4 @@ export { generateOpenApiDocument, STABLE_TAG } from './openapi';
 export type { V1Fixture } from './testing';
 export { assertMatchesV1Schema, loadV1Fixtures } from './testing';
 export * as v1 from './v1';
-export type { LegacyCodeRef, V1Chain, V1ChainType, V1DepositAddress, V1DepositAddressCreateRequest, V1DepositAddressKind, V1DestinationCall, V1ErrorCode, V1ErrorDefinition, V1Execution, V1Fee, V1FeeKind, V1FeeToken, V1FundingTransaction, V1GaslessJob, V1GaslessJobStatus, V1GaslessSubState, V1GaslessSubStatus, V1Guarantee, V1IntentCall, V1IntentReward, V1IntentRoute, V1IntentTokenAmount, V1ProblemBody, V1QuoteCore, V1QuoteRequest, V1QuoteResponse, V1RankedQuoteEntry, V1RelatedIntent, V1RelatedIntentRole, V1SolverIdentity, V1StatusEntry, V1StatusType, V1Step, V1StepKind, V1StepLeg, V1SwapType, V1TokenEntry, V1Visibility, } from './v1/types';
+export type { LegacyCodeRef, V1Chain, V1ChainType, V1DepositAddress, V1DepositAddressChainStatus, V1DepositAddressCreateRequest, V1DepositAddressCreateResponse, V1DepositAddressKind, V1DestinationCall, V1ErrorCode, V1ErrorDefinition, V1Execution, V1Fee, V1FeeKind, V1FeeToken, V1FundingTransaction, V1GaslessJob, V1GaslessJobStatus, V1GaslessSubState, V1GaslessSubStatus, V1Guarantee, V1IntentCall, V1IntentReward, V1IntentRoute, V1IntentTokenAmount, V1ProblemBody, V1QuoteCore, V1QuoteRequest, V1QuoteResponse, V1RankedQuoteEntry, V1RelatedIntent, V1RelatedIntentRole, V1SolverIdentity, V1StatusEntry, V1StatusType, V1Step, V1StepKind, V1StepLeg, V1SvmAccountMeta, V1SvmInstruction, V1SwapType, V1TokenEntry, V1Visibility, } from './v1/types';

package/dist/testing/index.d.ts

@@ -5,3 +5,5 @@ export declare function assertMatchesV1Schema(endpointId: V1EndpointId, payload:
     direction?: 'request' | 'response';
 }): void;
 export declare function loadV1Fixtures(): readonly V1Fixture[];
+export declare const SIDE_EFFECT_SKIP_REASON = "sideEffect fixture \u2014 covered by flow E2Es";
+export declare const DRAFT_SKIP_REASON = "draft endpoint (x-stability: draft) \u2014 not served at launch";

package/dist/testing/index.js

@@ -1,5 +1,6 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
+exports.DRAFT_SKIP_REASON = exports.SIDE_EFFECT_SKIP_REASON = void 0;
 exports.assertMatchesV1Schema = assertMatchesV1Schema;
 exports.loadV1Fixtures = loadV1Fixtures;
 const zod_1 = require("zod");
@@ -24,4 +25,6 @@ function assertMatchesV1Schema(endpointId, payload, opts = {}) {
 function loadV1Fixtures() {
     return fixtures_1.V1_FIXTURES;
 }
+exports.SIDE_EFFECT_SKIP_REASON = 'sideEffect fixture — covered by flow E2Es';
+exports.DRAFT_SKIP_REASON = 'draft endpoint (x-stability: draft) — not served at launch';
 //# sourceMappingURL=index.js.map

package/dist/testing/index.js.map

@@ -1 +1 @@
-{"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/testing/index.ts"],"names":[],"mappings":";;AA0BA,sDAqBC;AAED,wCAEC;AAnDD,6BAAwB;AAExB,0CAAqD;AACrD,uDAA4F;AAY5F,MAAM,WAAW,GAA+C,uBAAY,CAAC;AAW7E,SAAgB,qBAAqB,CACnC,UAAwB,EACxB,OAAgB,EAChB,OAA+C,EAAE;IAEjD,MAAM,SAAS,GAAG,IAAI,CAAC,SAAS,IAAI,UAAU,CAAC;IAC/C,MAAM,GAAG,GAAG,WAAW,CAAC,UAAU,CAAC,CAAC;IACpC,IAAI,CAAC,GAAG,EAAE,CAAC;QACT,MAAM,IAAI,KAAK,CACb,4BAA4B,MAAM,CAAC,UAAU,CAAC,iBAAiB,SAAS,KAAK;YAC3E,cAAc,MAAM,CAAC,IAAI,CAAC,uBAAY,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,CACvD,CAAC;IACJ,CAAC;IACD,MAAM,MAAM,GAA0B,SAAS,KAAK,SAAS,CAAC,CAAC,CAAC,GAAG,CAAC,OAAO,CAAC,CAAC,CAAC,GAAG,CAAC,QAAQ,CAAC;IAC3F,IAAI,CAAC,MAAM;QAAE,MAAM,IAAI,KAAK,CAAC,GAAG,UAAU,WAAW,SAAS,SAAS,CAAC,CAAC;IACzE,MAAM,MAAM,GAAG,MAAM,CAAC,SAAS,CAAC,OAAO,CAAC,CAAC;IACzC,IAAI,CAAC,MAAM,CAAC,OAAO,EAAE,CAAC;QACpB,MAAM,IAAI,KAAK,CACb,0BAA0B,UAAU,IAAI,SAAS,aAAa,OAAC,CAAC,aAAa,CAAC,MAAM,CAAC,KAAK,CAAC,EAAE,CAC9F,CAAC;IACJ,CAAC;AACH,CAAC;AAED,SAAgB,cAAc;IAC5B,OAAO,sBAAW,CAAC;AACrB,CAAC"}
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/testing/index.ts"],"names":[],"mappings":";;;AA0BA,sDAqBC;AAED,wCAEC;AAnDD,6BAAwB;AAExB,0CAAqD;AACrD,uDAA4F;AAY5F,MAAM,WAAW,GAA+C,uBAAY,CAAC;AAW7E,SAAgB,qBAAqB,CACnC,UAAwB,EACxB,OAAgB,EAChB,OAA+C,EAAE;IAEjD,MAAM,SAAS,GAAG,IAAI,CAAC,SAAS,IAAI,UAAU,CAAC;IAC/C,MAAM,GAAG,GAAG,WAAW,CAAC,UAAU,CAAC,CAAC;IACpC,IAAI,CAAC,GAAG,EAAE,CAAC;QACT,MAAM,IAAI,KAAK,CACb,4BAA4B,MAAM,CAAC,UAAU,CAAC,iBAAiB,SAAS,KAAK;YAC3E,cAAc,MAAM,CAAC,IAAI,CAAC,uBAAY,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,CACvD,CAAC;IACJ,CAAC;IACD,MAAM,MAAM,GAA0B,SAAS,KAAK,SAAS,CAAC,CAAC,CAAC,GAAG,CAAC,OAAO,CAAC,CAAC,CAAC,GAAG,CAAC,QAAQ,CAAC;IAC3F,IAAI,CAAC,MAAM;QAAE,MAAM,IAAI,KAAK,CAAC,GAAG,UAAU,WAAW,SAAS,SAAS,CAAC,CAAC;IACzE,MAAM,MAAM,GAAG,MAAM,CAAC,SAAS,CAAC,OAAO,CAAC,CAAC;IACzC,IAAI,CAAC,MAAM,CAAC,OAAO,EAAE,CAAC;QACpB,MAAM,IAAI,KAAK,CACb,0BAA0B,UAAU,IAAI,SAAS,aAAa,OAAC,CAAC,aAAa,CAAC,MAAM,CAAC,KAAK,CAAC,EAAE,CAC9F,CAAC;IACJ,CAAC;AACH,CAAC;AAED,SAAgB,cAAc;IAC5B,OAAO,sBAAW,CAAC;AACrB,CAAC;AASY,QAAA,uBAAuB,GAAG,2CAA2C,CAAC;AACtE,QAAA,iBAAiB,GAAG,4DAA4D,CAAC"}

package/dist/v1/endpoints/chains.d.ts

@@ -26,6 +26,13 @@ export declare const ChainSchema: z.ZodObject<{
     }, z.core.$loose>;
 }, z.core.$loose>;
 export type Chain = z.input<typeof ChainSchema>;
+export declare const V1LimitsSchema: z.ZodObject<{
+    paging: z.ZodObject<{
+        maxLimit: z.ZodNumber;
+        defaultLimit: z.ZodNumber;
+    }, z.core.$loose>;
+}, z.core.$loose>;
+export type V1Limits = z.input<typeof V1LimitsSchema>;
 export declare const ChainsResponseSchema: z.ZodObject<{
     chains: z.ZodArray<z.ZodObject<{
         chainId: z.ZodNumber;
@@ -49,4 +56,10 @@ export declare const ChainsResponseSchema: z.ZodObject<{
             executor: z.ZodNullable<z.ZodUnion<readonly [z.ZodString, z.ZodUnion<readonly [z.ZodString, z.ZodString]>, z.ZodString]>>;
         }, z.core.$loose>;
     }, z.core.$loose>>;
+    limits: z.ZodOptional<z.ZodObject<{
+        paging: z.ZodObject<{
+            maxLimit: z.ZodNumber;
+            defaultLimit: z.ZodNumber;
+        }, z.core.$loose>;
+    }, z.core.$loose>>;
 }, z.core.$loose>;

package/dist/v1/endpoints/chains.js

@@ -1,9 +1,10 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.ChainsResponseSchema = exports.ChainSchema = exports.ChainContractsSchema = void 0;
+exports.ChainsResponseSchema = exports.V1LimitsSchema = exports.ChainSchema = exports.ChainContractsSchema = void 0;
 const zod_1 = require("zod");
 const enums_1 = require("../enums");
 const primitives_1 = require("../primitives");
+const status_1 = require("./status");
 exports.ChainContractsSchema = zod_1.z.looseObject({
     portal: primitives_1.AnyAddress,
     executor: primitives_1.AnyAddress.nullable(),
@@ -17,7 +18,11 @@ exports.ChainSchema = zod_1.z.looseObject({
     status: enums_1.ChainStatus,
     contracts: exports.ChainContractsSchema,
 });
+exports.V1LimitsSchema = zod_1.z.looseObject({
+    paging: status_1.PagingBoundsSchema,
+});
 exports.ChainsResponseSchema = zod_1.z.looseObject({
     chains: zod_1.z.array(exports.ChainSchema),
+    limits: exports.V1LimitsSchema.optional(),
 });
 //# sourceMappingURL=chains.js.map

package/dist/v1/endpoints/chains.js.map

@@ -1 +1 @@
-{"version":3,"file":"chains.js","sourceRoot":"","sources":["../../../src/v1/endpoints/chains.ts"],"names":[],"mappings":";;;AAAA,6BAAwB;AAExB,oCAAiE;AACjE,8CAAoD;AAKvC,QAAA,oBAAoB,GAAG,OAAC,CAAC,WAAW,CAAC;IAChD,MAAM,EAAE,uBAAU;IAMlB,QAAQ,EAAE,uBAAU,CAAC,QAAQ,EAAE;CAChC,CAAC,CAAC;AAEU,QAAA,WAAW,GAAG,OAAC,CAAC,WAAW,CAAC;IACvC,OAAO,EAAE,oBAAO;IAChB,IAAI,EAAE,OAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;IASvB,WAAW,EAAE,uBAAU;IAEvB,IAAI,EAAE,iBAAS;IACf,QAAQ,EAAE,qBAAa;IAEvB,MAAM,EAAE,mBAAW;IACnB,SAAS,EAAE,4BAAoB;CAChC,CAAC,CAAC;AAGU,QAAA,oBAAoB,GAAG,OAAC,CAAC,WAAW,CAAC;IAChD,MAAM,EAAE,OAAC,CAAC,KAAK,CAAC,mBAAW,CAAC;CAC7B,CAAC,CAAC"}
+{"version":3,"file":"chains.js","sourceRoot":"","sources":["../../../src/v1/endpoints/chains.ts"],"names":[],"mappings":";;;AAAA,6BAAwB;AAExB,oCAAiE;AACjE,8CAAoD;AACpD,qCAA8C;AAKjC,QAAA,oBAAoB,GAAG,OAAC,CAAC,WAAW,CAAC;IAChD,MAAM,EAAE,uBAAU;IAMlB,QAAQ,EAAE,uBAAU,CAAC,QAAQ,EAAE;CAChC,CAAC,CAAC;AAEU,QAAA,WAAW,GAAG,OAAC,CAAC,WAAW,CAAC;IACvC,OAAO,EAAE,oBAAO;IAChB,IAAI,EAAE,OAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;IASvB,WAAW,EAAE,uBAAU;IAEvB,IAAI,EAAE,iBAAS;IACf,QAAQ,EAAE,qBAAa;IAEvB,MAAM,EAAE,mBAAW;IACnB,SAAS,EAAE,4BAAoB;CAChC,CAAC,CAAC;AAwCU,QAAA,cAAc,GAAG,OAAC,CAAC,WAAW,CAAC;IAC1C,MAAM,EAAE,2BAAkB;CAC3B,CAAC,CAAC;AAGU,QAAA,oBAAoB,GAAG,OAAC,CAAC,WAAW,CAAC;IAChD,MAAM,EAAE,OAAC,CAAC,KAAK,CAAC,mBAAW,CAAC;IAC5B,MAAM,EAAE,sBAAc,CAAC,QAAQ,EAAE;CAClC,CAAC,CAAC"}

package/dist/v1/endpoints/deposit-addresses.d.ts

@@ -40,6 +40,20 @@ export declare const DepositAddressSchema: z.ZodObject<{
     createdAt: z.ZodNumber;
 }, z.core.$loose>;
 export type DepositAddress = z.input<typeof DepositAddressSchema>;
+export declare const DepositAddressChainRegistrationSchema: z.ZodEnum<{
+    registered: "registered";
+    unregistered: "unregistered";
+}>;
+export type DepositAddressChainRegistration = z.infer<typeof DepositAddressChainRegistrationSchema>;
+export declare const DepositAddressChainStatusSchema: z.ZodObject<{
+    chainId: z.ZodNumber;
+    source: z.ZodBoolean;
+    registration: z.ZodEnum<{
+        registered: "registered";
+        unregistered: "unregistered";
+    }>;
+}, z.core.$loose>;
+export type DepositAddressChainStatus = z.input<typeof DepositAddressChainStatusSchema>;
 export declare const DepositAddressCreateResponseSchema: z.ZodObject<{
     id: z.ZodString;
     depositAddress: z.ZodString;
@@ -54,7 +68,16 @@ export declare const DepositAddressCreateResponseSchema: z.ZodObject<{
     destinationChainId: z.ZodOptional<z.ZodNumber>;
     expiresAt: z.ZodNullable<z.ZodNumber>;
     createdAt: z.ZodNumber;
+    chains: z.ZodArray<z.ZodObject<{
+        chainId: z.ZodNumber;
+        source: z.ZodBoolean;
+        registration: z.ZodEnum<{
+            registered: "registered";
+            unregistered: "unregistered";
+        }>;
+    }, z.core.$loose>>;
 }, z.core.$loose>;
+export type DepositAddressCreateResponse = z.input<typeof DepositAddressCreateResponseSchema>;
 export declare const DEPOSIT_ADDRESS_LOOKUP_QUERY_SHAPE: {
     cursor: z.ZodOptional<z.ZodString>;
     limit: z.ZodDefault<z.ZodCoercedNumber<unknown>>;

package/dist/v1/endpoints/deposit-addresses.js

@@ -1,6 +1,6 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.DepositAddressLookupResponseSchema = exports.DepositAddressLookupQuerySchema = exports.DEPOSIT_ADDRESS_LOOKUP_QUERY_SHAPE = exports.DepositAddressCreateResponseSchema = exports.DepositAddressSchema = exports.DepositAddressCreateRequestSchema = exports.DepositAddressKind = exports.DEPOSIT_ADDRESS_KINDS = void 0;
+exports.DepositAddressLookupResponseSchema = exports.DepositAddressLookupQuerySchema = exports.DEPOSIT_ADDRESS_LOOKUP_QUERY_SHAPE = exports.DepositAddressCreateResponseSchema = exports.DepositAddressChainStatusSchema = exports.DepositAddressChainRegistrationSchema = exports.DepositAddressSchema = exports.DepositAddressCreateRequestSchema = exports.DepositAddressKind = exports.DEPOSIT_ADDRESS_KINDS = void 0;
 const zod_1 = require("zod");
 const primitives_1 = require("../primitives");
 const status_1 = require("./status");
@@ -38,7 +38,39 @@ exports.DepositAddressSchema = zod_1.z.looseObject({
     expiresAt: primitives_1.UnixSeconds.nullable(),
     createdAt: primitives_1.UnixSeconds,
 });
-exports.DepositAddressCreateResponseSchema = exports.DepositAddressSchema;
+exports.DepositAddressChainRegistrationSchema = zod_1.z.enum(['registered', 'unregistered']);
+exports.DepositAddressChainStatusSchema = zod_1.z.looseObject({
+    chainId: primitives_1.ChainId,
+    source: zod_1.z.boolean(),
+    registration: exports.DepositAddressChainRegistrationSchema,
+});
+exports.DepositAddressCreateResponseSchema = exports.DepositAddressSchema.extend({
+    chains: zod_1.z.array(exports.DepositAddressChainStatusSchema).min(1),
+}).superRefine((body, ctx) => {
+    const chains = body.chains;
+    if (!Array.isArray(chains))
+        return;
+    const sourceCount = chains.filter((entry) => entry.source === true).length;
+    if (sourceCount !== 1) {
+        ctx.addIssue({
+            code: 'custom',
+            path: ['chains'],
+            message: `chains must contain exactly one source entry, found ${sourceCount}`,
+        });
+    }
+    const seen = new Set();
+    chains.forEach((entry, index) => {
+        if (seen.has(entry.chainId)) {
+            ctx.addIssue({
+                code: 'custom',
+                path: ['chains', index, 'chainId'],
+                message: `chains must not repeat a chainId, ${entry.chainId} appears more than once`,
+            });
+            return;
+        }
+        seen.add(entry.chainId);
+    });
+});
 const DEPOSIT_ADDRESS_LOOKUP_FILTERS = [
     'depositAddress',
     'depositor',

package/dist/v1/endpoints/deposit-addresses.js.map

@@ -1 +1 @@
-{"version":3,"file":"deposit-addresses.js","sourceRoot":"","sources":["../../../src/v1/endpoints/deposit-addresses.ts"],"names":[],"mappings":";;;AAAA,6BAAwB;AAExB,8CAOuB;AACvB,qCAAiE;AAepD,QAAA,qBAAqB,GAAG,CAAC,QAAQ,EAAE,SAAS,EAAE,eAAe,CAAU,CAAC;AACxE,QAAA,kBAAkB,GAAG,OAAC,CAAC,IAAI,CAAC,6BAAqB,CAAC,CAAC;AAkBnD,QAAA,iCAAiC,GAAG,OAAC,CAAC,kBAAkB,CAAC,MAAM,EAAE;IAC5E,OAAC,CAAC,YAAY,CAAC;QACb,OAAO,EAAE,oBAAO;QAChB,SAAS,EAAE,uBAAU;QACrB,IAAI,EAAE,OAAC,CAAC,OAAO,CAAC,QAAQ,CAAC;QACzB,kBAAkB,EAAE,uBAAU;KAC/B,CAAC;IACF,OAAC,CAAC,YAAY,CAAC;QACb,OAAO,EAAE,oBAAO;QAChB,SAAS,EAAE,uBAAU;QACrB,IAAI,EAAE,OAAC,CAAC,OAAO,CAAC,SAAS,CAAC;QAC1B,kBAAkB,EAAE,uBAAU;KAC/B,CAAC;IACF,OAAC,CAAC,YAAY,CAAC;QACb,OAAO,EAAE,oBAAO;QAChB,SAAS,EAAE,uBAAU;QACrB,IAAI,EAAE,OAAC,CAAC,OAAO,CAAC,eAAe,CAAC;QAChC,kBAAkB,EAAE,uBAAU;QAC9B,kBAAkB,EAAE,oBAAO;KAC5B,CAAC;CACH,CAAC,CAAC;AASU,QAAA,oBAAoB,GAAG,OAAC,CAAC,WAAW,CAAC;IAChD,EAAE,EAAE,6BAAgB;IACpB,cAAc,EAAE,uBAAU;IAC1B,OAAO,EAAE,oBAAO;IAChB,SAAS,EAAE,uBAAU;IACrB,IAAI,EAAE,0BAAkB;IACxB,kBAAkB,EAAE,uBAAU;IAC9B,kBAAkB,EAAE,oBAAO,CAAC,QAAQ,EAAE;IACtC,SAAS,EAAE,wBAAW,CAAC,QAAQ,EAAE;IACjC,SAAS,EAAE,wBAAW;CACvB,CAAC,CAAC;AAIU,QAAA,kCAAkC,GAAG,4BAAoB,CAAC;AAUvE,MAAM,8BAA8B,GAAG;IACrC,gBAAgB;IAChB,WAAW;IACX,oBAAoB;CACZ,CAAC;AAoCE,QAAA,kCAAkC,GAAG;IAChD,cAAc,EAAE,uBAAU,CAAC,QAAQ,EAAE;IACrC,SAAS,EAAE,uBAAU,CAAC,QAAQ,EAAE;IAChC,kBAAkB,EAAE,uBAAU,CAAC,QAAQ,EAAE;IAGzC,OAAO,EAAE,OAAC,CAAC,MAAM,CAAC,MAAM,EAAE,CAAC,GAAG,EAAE,CAAC,QAAQ,EAAE,CAAC,GAAG,CAAC,MAAM,CAAC,gBAAgB,CAAC,CAAC,QAAQ,EAAE;IACnF,IAAI,EAAE,0BAAkB,CAAC,QAAQ,EAAE;IACnC,GAAG,qBAAY;CAChB,CAAC;AAEW,QAAA,+BAA+B,GAAG,OAAC;KAC7C,MAAM,CAAC,0CAAkC,CAAC;KAC1C,WAAW,CAAC,IAAA,gCAAuB,EAAC,8BAA8B,CAAC,CAAC,CAAC;AAE3D,QAAA,kCAAkC,GAAG,OAAC,CAAC,WAAW,CAAC;IAC9D,OAAO,EAAE,OAAC,CAAC,KAAK,CAAC,4BAAoB,CAAC;CACvC,CAAC,CAAC"}
+{"version":3,"file":"deposit-addresses.js","sourceRoot":"","sources":["../../../src/v1/endpoints/deposit-addresses.ts"],"names":[],"mappings":";;;AAAA,6BAAwB;AAExB,8CAOuB;AACvB,qCAAiE;AAepD,QAAA,qBAAqB,GAAG,CAAC,QAAQ,EAAE,SAAS,EAAE,eAAe,CAAU,CAAC;AACxE,QAAA,kBAAkB,GAAG,OAAC,CAAC,IAAI,CAAC,6BAAqB,CAAC,CAAC;AAkBnD,QAAA,iCAAiC,GAAG,OAAC,CAAC,kBAAkB,CAAC,MAAM,EAAE;IAC5E,OAAC,CAAC,YAAY,CAAC;QACb,OAAO,EAAE,oBAAO;QAChB,SAAS,EAAE,uBAAU;QACrB,IAAI,EAAE,OAAC,CAAC,OAAO,CAAC,QAAQ,CAAC;QACzB,kBAAkB,EAAE,uBAAU;KAC/B,CAAC;IACF,OAAC,CAAC,YAAY,CAAC;QACb,OAAO,EAAE,oBAAO;QAChB,SAAS,EAAE,uBAAU;QACrB,IAAI,EAAE,OAAC,CAAC,OAAO,CAAC,SAAS,CAAC;QAC1B,kBAAkB,EAAE,uBAAU;KAC/B,CAAC;IACF,OAAC,CAAC,YAAY,CAAC;QACb,OAAO,EAAE,oBAAO;QAChB,SAAS,EAAE,uBAAU;QACrB,IAAI,EAAE,OAAC,CAAC,OAAO,CAAC,eAAe,CAAC;QAChC,kBAAkB,EAAE,uBAAU;QAC9B,kBAAkB,EAAE,oBAAO;KAC5B,CAAC;CACH,CAAC,CAAC;AASU,QAAA,oBAAoB,GAAG,OAAC,CAAC,WAAW,CAAC;IAChD,EAAE,EAAE,6BAAgB;IACpB,cAAc,EAAE,uBAAU;IAC1B,OAAO,EAAE,oBAAO;IAChB,SAAS,EAAE,uBAAU;IACrB,IAAI,EAAE,0BAAkB;IACxB,kBAAkB,EAAE,uBAAU;IAC9B,kBAAkB,EAAE,oBAAO,CAAC,QAAQ,EAAE;IACtC,SAAS,EAAE,wBAAW,CAAC,QAAQ,EAAE;IACjC,SAAS,EAAE,wBAAW;CACvB,CAAC,CAAC;AAuBU,QAAA,qCAAqC,GAAG,OAAC,CAAC,IAAI,CAAC,CAAC,YAAY,EAAE,cAAc,CAAC,CAAC,CAAC;AAyB/E,QAAA,+BAA+B,GAAG,OAAC,CAAC,WAAW,CAAC;IAC3D,OAAO,EAAE,oBAAO;IAEhB,MAAM,EAAE,OAAC,CAAC,OAAO,EAAE;IACnB,YAAY,EAAE,6CAAqC;CACpD,CAAC,CAAC;AA0DU,QAAA,kCAAkC,GAAG,4BAAoB,CAAC,MAAM,CAAC;IAC5E,MAAM,EAAE,OAAC,CAAC,KAAK,CAAC,uCAA+B,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC;CACxD,CAAC,CAAC,WAAW,CAAC,CAAC,IAAI,EAAE,GAAG,EAAE,EAAE;IAC3B,MAAM,MAAM,GAAG,IAAI,CAAC,MAAM,CAAC;IAC3B,IAAI,CAAC,KAAK,CAAC,OAAO,CAAC,MAAM,CAAC;QAAE,OAAO;IAEnC,MAAM,WAAW,GAAG,MAAM,CAAC,MAAM,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,KAAK,CAAC,MAAM,KAAK,IAAI,CAAC,CAAC,MAAM,CAAC;IAC3E,IAAI,WAAW,KAAK,CAAC,EAAE,CAAC;QACtB,GAAG,CAAC,QAAQ,CAAC;YACX,IAAI,EAAE,QAAQ;YACd,IAAI,EAAE,CAAC,QAAQ,CAAC;YAChB,OAAO,EAAE,uDAAuD,WAAW,EAAE;SAC9E,CAAC,CAAC;IACL,CAAC;IAID,MAAM,IAAI,GAAG,IAAI,GAAG,EAAU,CAAC;IAC/B,MAAM,CAAC,OAAO,CAAC,CAAC,KAAK,EAAE,KAAK,EAAE,EAAE;QAC9B,IAAI,IAAI,CAAC,GAAG,CAAC,KAAK,CAAC,OAAO,CAAC,EAAE,CAAC;YAC5B,GAAG,CAAC,QAAQ,CAAC;gBACX,IAAI,EAAE,QAAQ;gBACd,IAAI,EAAE,CAAC,QAAQ,EAAE,KAAK,EAAE,SAAS,CAAC;gBAClC,OAAO,EAAE,qCAAqC,KAAK,CAAC,OAAO,yBAAyB;aACrF,CAAC,CAAC;YACH,OAAO;QACT,CAAC;QACD,IAAI,CAAC,GAAG,CAAC,KAAK,CAAC,OAAO,CAAC,CAAC;IAC1B,CAAC,CAAC,CAAC;AACL,CAAC,CAAC,CAAC;AAWH,MAAM,8BAA8B,GAAG;IACrC,gBAAgB;IAChB,WAAW;IACX,oBAAoB;CACZ,CAAC;AAoCE,QAAA,kCAAkC,GAAG;IAChD,cAAc,EAAE,uBAAU,CAAC,QAAQ,EAAE;IACrC,SAAS,EAAE,uBAAU,CAAC,QAAQ,EAAE;IAChC,kBAAkB,EAAE,uBAAU,CAAC,QAAQ,EAAE;IAGzC,OAAO,EAAE,OAAC,CAAC,MAAM,CAAC,MAAM,EAAE,CAAC,GAAG,EAAE,CAAC,QAAQ,EAAE,CAAC,GAAG,CAAC,MAAM,CAAC,gBAAgB,CAAC,CAAC,QAAQ,EAAE;IACnF,IAAI,EAAE,0BAAkB,CAAC,QAAQ,EAAE;IACnC,GAAG,qBAAY;CAChB,CAAC;AAEW,QAAA,+BAA+B,GAAG,OAAC;KAC7C,MAAM,CAAC,0CAAkC,CAAC;KAC1C,WAAW,CAAC,IAAA,gCAAuB,EAAC,8BAA8B,CAAC,CAAC,CAAC;AAE3D,QAAA,kCAAkC,GAAG,OAAC,CAAC,WAAW,CAAC;IAC9D,OAAO,EAAE,OAAC,CAAC,KAAK,CAAC,4BAAoB,CAAC;CACvC,CAAC,CAAC"}