@gibs/bridge-sdk 1.12.0 → 1.13.0

package/dist/image-links.d.ts

@@ -0,0 +1,117 @@
+import { type DepositAddressChain } from './chain-names.js';
+/**
+ * Sets the image root for the bridge
+ * @param root - the root
+ */
+export declare const setImageRoot: (root: string) => void;
+/**
+ * Returns the image root for the bridge
+ * @returns the image root
+ */
+export declare const getImageRoot: () => string;
+/** The minimal token info */
+interface MinimalTokenInfo {
+    chainId: number;
+    address: string;
+    logoURI?: string | null;
+}
+/**
+ * Returns the list image for the given path
+ * @param path - the path
+ * @returns the list image
+ */
+export declare const list: (path: string) => string;
+/**
+ * Returns the network image for the given chain id
+ * @param chainId - the chain id
+ * @returns the network image
+ */
+export declare const network: (chainId: number) => string;
+/**
+ * gib.show's own key for a chain this package can only name by a LOCAL,
+ * INVENTED identifier — a pay-by-hand origin (see `depositAddressChainIds`)
+ * rather than a real chain id gib.show's numeric endpoint recognizes.
+ * `network(chainId)` 404s for one of these, and the browser draws that 404 as
+ * a broken image on every chain badge and route mark drawn through it.
+ *
+ * Every route producer that draws a chain badge for a token needs this, not
+ * only the deposit-address ones: a route can START on a deposit-address chain
+ * and cross through ordinary Ethereum-Virtual-Machine chains after, so the
+ * predicate has to run on every chain id a route touches, not only the one
+ * the reader picked. Kept beside `network` rather than in the client that also
+ * resolves Relay's pseudo chains (`@gibs/bridge-client/image`'s
+ * `chainLogoUrl`) because that client sits ABOVE this package — it imports
+ * FROM `bridge-sdk` — so this package importing back from it would be a
+ * cycle. `chainLogoUrl` still adds a Relay-icon fallback for chains gib.show
+ * does not carry at ALL (Eclipse, Hyperliquid); this table is only the
+ * chains gib.show DOES carry, under a key other than their numeric id.
+ *
+ * EXPORTED, and this is the ONLY place a pay-by-hand chain's gib.show key is
+ * declared. `@gibs/bridge-client`'s `image.ts` used to hard-code its own copy
+ * of the same `zcash → 'bip122-133'` entry; it now spreads this map into its
+ * own icon table instead, because the dependency runs one way — the client
+ * already imports from this package — so there was never a cycle stopping it.
+ */
+export declare const pseudoChainGibShowIdentifierByChain: Record<DepositAddressChain, string>;
+/** {@link pseudoChainGibShowIdentifierByChain}, keyed by chain id for lookup. */
+export declare const pseudoChainGibShowIdentifier: Readonly<Record<number, string>>;
+/**
+ * The network image for a chain id, honouring a pseudo chain's own gib.show
+ * key when its numeric id is not one gib.show's `/image/<id>` endpoint knows.
+ *
+ * @param chainId - the chain id, a deposit-address chain's local identifier included
+ * @returns a working network/chain-badge image url
+ */
+export declare const networkOrPseudo: (chainId: number) => string;
+/**
+ * Returns the image url for the given token info.
+ *
+ * The gas token is asked for by BOTH of its keys, because the service keys it
+ * two ways and each chain carries only one of them. `<chain>/<zero address>` is
+ * a dedicated picture — Ethereum's ether diamond, PulseChain's mark — and
+ * Binance Smart Chain has none, so asking for it there returns a 404 the browser
+ * draws as a broken image. The empty-address form `<chain>/` is the chain's own
+ * mark, which every chain has.
+ *
+ * The order is NOT interchangeable. The service serves the first source that
+ * resolves, so a chain with a dedicated picture keeps it; reversed, Ethereum
+ * would show the network logo where the ether logo belongs (the two are
+ * genuinely different files). The pair is for the gas token alone: pairing an
+ * ordinary contract address with the chain mark would hide a missing token logo
+ * behind the network's, showing the wrong token rather than an honest fallback.
+ *
+ * @param t - the token info
+ * @returns the image url
+ */
+export declare const image: (t: MinimalTokenInfo) => string;
+/**
+ * {@link image}, but falling back to the token's own CHAIN mark rather than
+ * throwing or asking the service for a picture that was never going to exist,
+ * when the token carries no address a picture can be resolved from yet.
+ *
+ * WHY THIS EXISTS SEPARATELY FROM `image`. A route producer can reach the
+ * moment it draws a DELIVERED token's picture before that token's exact
+ * on-chain address is known — a not-yet-bridged token's `assetOutAddress` is
+ * documented to arrive `null` (see the repository's own "Not-Yet-Bridged
+ * Tokens" gotcha), and a deferred crossing's landing token is exactly this
+ * case: the reader has not yet signed the leg that would settle it. `image`
+ * either throws (`getAddress` refuses a malformed or empty string) or, for a
+ * caller that swallows the throw, silently draws nothing — the same "blank
+ * disc" defect the carrier marks were fixed for, one token lower. The chain's
+ * own mark is a real, recognisable picture that is honest about what is
+ * known: THIS chain, a token not yet resolved on it — the same trade
+ * `trackerView.ts`'s `depositAddressChainLogoFallback` already makes for a
+ * pay-by-hand ORIGIN with no address of its own.
+ *
+ * @param t - the token to draw
+ * @returns the token's own picture, or its chain's mark when the token's
+ *   address cannot be resolved into one
+ */
+export declare const tokenImageOrChainFallback: (t: MinimalTokenInfo) => string;
+/**
+ * Returns a url that will lookup all sources for the given array
+ * @param sources - the sources
+ * @returns the images
+ */
+export declare const images: (sources: string[]) => string;
+export {};

package/dist/image-links.js

@@ -0,0 +1,142 @@
+import { getAddress, zeroAddress } from 'viem';
+import { depositAddressChainIds } from './chain-names.js';
+import { isNativeAsset } from './ecosystems.js';
+let imageRoot = 'https://gib.show';
+/**
+ * Sets the image root for the bridge
+ * @param root - the root
+ */
+export const setImageRoot = (root) => {
+    imageRoot = root;
+};
+/**
+ * Returns the image root for the bridge
+ * @returns the image root
+ */
+export const getImageRoot = () => imageRoot;
+/**
+ * Returns the list image for the given path
+ * @param path - the path
+ * @returns the list image
+ */
+export const list = (path) => {
+    return `${imageRoot}/list${path}`;
+};
+/**
+ * Returns the network image for the given chain id
+ * @param chainId - the chain id
+ * @returns the network image
+ */
+export const network = (chainId) => `${imageRoot}/image/${Number(chainId)}`;
+/**
+ * gib.show's own key for a chain this package can only name by a LOCAL,
+ * INVENTED identifier — a pay-by-hand origin (see `depositAddressChainIds`)
+ * rather than a real chain id gib.show's numeric endpoint recognizes.
+ * `network(chainId)` 404s for one of these, and the browser draws that 404 as
+ * a broken image on every chain badge and route mark drawn through it.
+ *
+ * Every route producer that draws a chain badge for a token needs this, not
+ * only the deposit-address ones: a route can START on a deposit-address chain
+ * and cross through ordinary Ethereum-Virtual-Machine chains after, so the
+ * predicate has to run on every chain id a route touches, not only the one
+ * the reader picked. Kept beside `network` rather than in the client that also
+ * resolves Relay's pseudo chains (`@gibs/bridge-client/image`'s
+ * `chainLogoUrl`) because that client sits ABOVE this package — it imports
+ * FROM `bridge-sdk` — so this package importing back from it would be a
+ * cycle. `chainLogoUrl` still adds a Relay-icon fallback for chains gib.show
+ * does not carry at ALL (Eclipse, Hyperliquid); this table is only the
+ * chains gib.show DOES carry, under a key other than their numeric id.
+ *
+ * EXPORTED, and this is the ONLY place a pay-by-hand chain's gib.show key is
+ * declared. `@gibs/bridge-client`'s `image.ts` used to hard-code its own copy
+ * of the same `zcash → 'bip122-133'` entry; it now spreads this map into its
+ * own icon table instead, because the dependency runs one way — the client
+ * already imports from this package — so there was never a cycle stopping it.
+ */
+export const pseudoChainGibShowIdentifierByChain = {
+    zcash: 'bip122-133',
+};
+/** {@link pseudoChainGibShowIdentifierByChain}, keyed by chain id for lookup. */
+export const pseudoChainGibShowIdentifier = Object.fromEntries(Object.keys(depositAddressChainIds).map((chain) => [
+    depositAddressChainIds[chain],
+    pseudoChainGibShowIdentifierByChain[chain],
+]));
+/**
+ * The network image for a chain id, honouring a pseudo chain's own gib.show
+ * key when its numeric id is not one gib.show's `/image/<id>` endpoint knows.
+ *
+ * @param chainId - the chain id, a deposit-address chain's local identifier included
+ * @returns a working network/chain-badge image url
+ */
+export const networkOrPseudo = (chainId) => {
+    const identifier = pseudoChainGibShowIdentifier[chainId];
+    return identifier !== undefined ? `${imageRoot}/image/${identifier}` : network(chainId);
+};
+/**
+ * Returns the image url for the given token info.
+ *
+ * The gas token is asked for by BOTH of its keys, because the service keys it
+ * two ways and each chain carries only one of them. `<chain>/<zero address>` is
+ * a dedicated picture — Ethereum's ether diamond, PulseChain's mark — and
+ * Binance Smart Chain has none, so asking for it there returns a 404 the browser
+ * draws as a broken image. The empty-address form `<chain>/` is the chain's own
+ * mark, which every chain has.
+ *
+ * The order is NOT interchangeable. The service serves the first source that
+ * resolves, so a chain with a dedicated picture keeps it; reversed, Ethereum
+ * would show the network logo where the ether logo belongs (the two are
+ * genuinely different files). The pair is for the gas token alone: pairing an
+ * ordinary contract address with the chain mark would hide a missing token logo
+ * behind the network's, showing the wrong token rather than an honest fallback.
+ *
+ * @param t - the token info
+ * @returns the image url
+ */
+export const image = (t) => {
+    if (t.logoURI)
+        return t.logoURI;
+    if (isNativeAsset(t.address, 'evm')) {
+        return images([`${Number(t.chainId)}/${zeroAddress}`, `${Number(t.chainId)}/`]);
+    }
+    return `${network(t.chainId)}/${getAddress(t.address)}`;
+};
+/**
+ * Whether `address` is a real Ethereum-Virtual-Machine address {@link image}
+ * can ask the service about — the zero address included, since that is
+ * {@link isNativeAsset}'s own case and {@link image} handles it without
+ * `getAddress` ever running.
+ *
+ * @param address - the address to check
+ * @returns true when `getAddress` can checksum it without throwing
+ */
+const isResolvableEvmAddress = (address) => /^0x[0-9a-fA-F]{40}$/.test(address);
+/**
+ * {@link image}, but falling back to the token's own CHAIN mark rather than
+ * throwing or asking the service for a picture that was never going to exist,
+ * when the token carries no address a picture can be resolved from yet.
+ *
+ * WHY THIS EXISTS SEPARATELY FROM `image`. A route producer can reach the
+ * moment it draws a DELIVERED token's picture before that token's exact
+ * on-chain address is known — a not-yet-bridged token's `assetOutAddress` is
+ * documented to arrive `null` (see the repository's own "Not-Yet-Bridged
+ * Tokens" gotcha), and a deferred crossing's landing token is exactly this
+ * case: the reader has not yet signed the leg that would settle it. `image`
+ * either throws (`getAddress` refuses a malformed or empty string) or, for a
+ * caller that swallows the throw, silently draws nothing — the same "blank
+ * disc" defect the carrier marks were fixed for, one token lower. The chain's
+ * own mark is a real, recognisable picture that is honest about what is
+ * known: THIS chain, a token not yet resolved on it — the same trade
+ * `trackerView.ts`'s `depositAddressChainLogoFallback` already makes for a
+ * pay-by-hand ORIGIN with no address of its own.
+ *
+ * @param t - the token to draw
+ * @returns the token's own picture, or its chain's mark when the token's
+ *   address cannot be resolved into one
+ */
+export const tokenImageOrChainFallback = (t) => isResolvableEvmAddress(t.address) ? image(t) : networkOrPseudo(t.chainId);
+/**
+ * Returns a url that will lookup all sources for the given array
+ * @param sources - the sources
+ * @returns the images
+ */
+export const images = (sources) => `${imageRoot}/image/?${sources.map((s) => `i=${s}`).join('&')}`;

package/dist/index.d.ts

@@ -0,0 +1,20 @@
+export * from './abis.js';
+export * from './bridge-limits.js';
+export * from './chain-info.js';
+export * from './chains.js';
+export * from './config.js';
+export * from './consolidated-quote.js';
+export * from './relay-quote.js';
+export * from './relay-currencies.js';
+export * from './destination-calldata.js';
+export * from './ecosystems.js';
+export * from './fee-type.js';
+export * from './image-links.js';
+export * from './lifi-execution-guard.js';
+export * from './origin-deposit.js';
+export * from './providers.js';
+export * from './referral.js';
+export * from './route-steps.js';
+export * from './routing/index.js';
+export * from './settings.js';
+export * from './types.js';

package/dist/index.js

@@ -0,0 +1,20 @@
+export * from './abis.js';
+export * from './bridge-limits.js';
+export * from './chain-info.js';
+export * from './chains.js';
+export * from './config.js';
+export * from './consolidated-quote.js';
+export * from './relay-quote.js';
+export * from './relay-currencies.js';
+export * from './destination-calldata.js';
+export * from './ecosystems.js';
+export * from './fee-type.js';
+export * from './image-links.js';
+export * from './lifi-execution-guard.js';
+export * from './origin-deposit.js';
+export * from './providers.js';
+export * from './referral.js';
+export * from './route-steps.js';
+export * from './routing/index.js';
+export * from './settings.js';
+export * from './types.js';

package/dist/lifi-execution-guard.d.ts

@@ -0,0 +1,199 @@
+import { type Hex } from 'viem';
+/**
+ * Verifies a LI.FI EVM execution transaction before a wallet ever signs it.
+ *
+ * WHY THIS EXISTS. `lifiApi.quote` and `lifiApi.contractCallsQuote` are fetched
+ * through a configurable base URL — today `lifi.gibs.finance`, a server-side
+ * proxy; the interface may point at a different host in the future. Whichever
+ * host answers, this codebase used to sign whatever `transactionRequest` came
+ * back after checking only that `to` and `data` were hexadecimal strings (see
+ * `lifiEvmDeposit` in `consolidated-quote.ts`). A COMPROMISED PROXY could
+ * return ANY `to`/`data`/`value` and a connected wallet would sign it,
+ * moving the reader's funds wherever the proxy chose.
+ *
+ * WHAT THIS MODULE PROVES INSTEAD, before signing:
+ *
+ * 1. `to` (and, when present, `estimate.approvalAddress`) is LI.FI's own
+ *    Diamond entryway contract for the chain the transaction runs on — a
+ *    fixed table, not something the response gets to assert about itself.
+ *    See {@link lifiDiamondAddressByChainId}.
+ * 2. The calldata's selector is one of a small, explicitly verified set of
+ *    LI.FI facet functions whose ABI this module carries in full. An unknown
+ *    selector is refused rather than guessed at.
+ * 3. The decoded `BridgeData` and leading `SwapData` entry agree with what
+ *    THIS APPLICATION asked for — not with other fields of the same,
+ *    potentially compromised, response. See {@link LifiExecutionExpectation}.
+ * 4. `transactionRequest.value` equals exactly the native currency the
+ *    decoded calldata implies (the amount being deposited, when that amount
+ *    is native, plus any protocol messaging fee the tool's own data
+ *    declares) — never more, never less.
+ *
+ * WHERE THE FIELD SEMANTICS CAME FROM. Every fact this module relies on —
+ * which struct field means what, and how the three verified facet functions
+ * actually populate `BridgeData` and `SwapData` — was read from REAL
+ * responses captured live from `https://li.quest`, decoded with this exact
+ * machinery, and cross-checked against the deployed contracts' Solidity
+ * source (`lifinance/contracts`, commit `025989955bb373739737ee78ddff01620638ae3b`,
+ * 2026-09-23). Two assumptions a first reading of LI.FI's own field
+ * descriptions would suggest turned out to be wrong, and are recorded here so
+ * nobody reintroduces them:
+ *
+ * - `BridgeData.receiver` is NOT "the final recipient" in general. For the
+ *   contract-calls endpoint (`hasDestinationCall: true`) it decoded to the
+ *   REQUEST'S `toFallbackAddress` — the address that receives the bridged
+ *   asset if the destination call reverts — not the destination call's own
+ *   contract or the reader's recipient. Only for the plain endpoint
+ *   (`hasDestinationCall: false`) does it equal the recipient (`toAddress`).
+ *   Verified against three independently captured quotes; see the fixtures
+ *   this module's test file reads.
+ * - `BridgeData.minAmount` is NOT the destination-side guaranteed amount for
+ *   any of the three verified tools. It is the amount of `sendingAssetId`
+ *   pulled from the depositor on the ORIGIN chain (`LibAsset.depositAsset`
+ *   in every facet's Solidity), reassigned at runtime to the real swap
+ *   output when `hasSourceSwaps` is true — a fact this module's calldata
+ *   never carries. The genuine destination-side guarantee lives in each
+ *   tool's own trailing struct (`AcrossV4Data.outputAmount`,
+ *   `StargateData.sendParams.minAmountLD`) and is read from there instead.
+ *   LayerSwap's own struct carries no on-chain amount field at all — its
+ *   guarantee is an off-chain, backend-signed attestation — so this module
+ *   cannot verify a destination minimum for it and refuses to try; see
+ *   {@link DecodedLifiFacetCall.destinationMinimum}.
+ *
+ * SCOPE, DELIBERATELY NARROW. Only the exact facet-function shapes seen in a
+ * REAL captured LI.FI response are decoded; every other selector refuses.
+ * Adding a new tool means capturing a fixture for it first — see
+ * `packages/bridge-sdk/src/__fixtures__/lifi/README.md` — and extending
+ * {@link lifiFacetDecoders} from that fixture, never from documentation
+ * alone (per the hand-built-quotes-hide-parser-gaps lesson: a decoder written
+ * from a guess passes its own hand-built test and nothing else).
+ */
+/**
+ * Every reason this module can refuse a LI.FI execution transaction.
+ *
+ * Each maps to one property of the response this module distrusts by
+ * default: `unknown-chain` and `router-mismatch` distrust `to`;
+ * `approval-address-mismatch` distrusts `estimate.approvalAddress`;
+ * `unknown-selector` and `calldata-undecodable` distrust `data`'s shape;
+ * `receiver-mismatch`, `destination-chain-mismatch`, `sending-asset-mismatch`,
+ * `destination-call-flag-mismatch` and `minimum-amount-below-requested`
+ * distrust `data`'s DECODED fields against what this application asked for;
+ * `native-value-mismatch` distrusts `value`. `missing-request-context` is
+ * different in kind: it means the CALLER never supplied what this
+ * application expected, so none of the above could even be checked — see
+ * `parseLifiContractCallsQuote` and `parseLifiQuote` in `consolidated-quote.ts`.
+ */
+export type LifiExecutionRefusalReason = 'unknown-chain' | 'router-mismatch' | 'approval-address-mismatch' | 'unknown-selector' | 'calldata-undecodable' | 'receiver-mismatch' | 'destination-chain-mismatch' | 'sending-asset-mismatch' | 'destination-call-flag-mismatch' | 'minimum-amount-below-requested' | 'native-value-mismatch' | 'missing-request-context';
+/** Why a LI.FI execution transaction was refused before signing. */
+export type LifiExecutionRefusal = {
+    readonly reason: LifiExecutionRefusalReason;
+    /** A short, specific explanation naming the values that disagreed. */
+    readonly detail: string;
+};
+/**
+ * Thrown by {@link verifyLifiEvmExecution} instead of returning a deposit a
+ * wallet could sign.
+ *
+ * NAMED AND TYPED SO A REFUSAL IS NEVER A SILENT DROP. Every caller that
+ * catches this can read `refusal.reason` and show, or log, exactly which
+ * check failed — the same discipline `@gibs/quotes`'s `ProviderQuoteError`
+ * applies to a provider declining a quote, applied here to a provider's
+ * ANSWER disagreeing with itself.
+ */
+export declare class LifiExecutionRefusedError extends Error {
+    readonly refusal: LifiExecutionRefusal;
+    constructor(refusal: LifiExecutionRefusal);
+}
+/**
+ * LI.FI's Diamond entryway contract address, by chain id.
+ *
+ * SOURCE. `lifinance/contracts` (https://github.com/lifinance/contracts),
+ * commit `025989955bb373739737ee78ddff01620638ae3b` (2026-09-23): the
+ * `LiFiDiamond` address in `deployments/<network>.json`, matched to its
+ * chain id in `config/networks.json`, for every network whose `status` is
+ * `"active"` and `"type"` is `"mainnet"`. LI.FI's own documentation
+ * (https://docs.li.fi/introduction/lifi-architecture/smart-contract-addresses)
+ * states the address is `0x1231DEB6f5749EF6cE6943a275A1D3E7486F4EaE` "on most
+ * supported networks" but differs on some — confirmed here directly against
+ * the deployment records rather than assumed: 39 of the 65 active mainnet
+ * networks use a DIFFERENT address, almost all of them newer or lower-volume
+ * chains (0G, Abstract, ApeChain, Arbitrum Nova, Berachain, Flare, zkSync
+ * Era, and more).
+ *
+ * DELIBERATELY A FIXED, BAKED-IN TABLE, NEVER A LIVE LOOKUP. LI.FI's own
+ * `/v1/chains` endpoint carries a `diamondAddress` per chain, and this
+ * codebase already fetches it for other purposes — but that endpoint is
+ * reached through the SAME configurable, potentially-compromised host this
+ * module exists to distrust. Trusting it here would make the whole guard
+ * circular: a compromised proxy could simply report its own malicious
+ * address as the "correct" one. This table is real code, reviewed and
+ * shipped with the application, and can only change through a new release.
+ *
+ * UNKNOWN CHAIN, UNKNOWN ADDRESS. A chain id absent from this table refuses
+ * rather than falling back to the common address — LI.FI adds networks
+ * continuously, and assuming a newly-added chain shares the common address
+ * would be exactly the kind of guess this module exists to avoid making.
+ */
+export declare const lifiDiamondAddressByChainId: ReadonlyMap<number, Hex>;
+/** LI.FI's `ILiFi.BridgeData` struct — identical across every facet function. */
+export type LifiBridgeData = {
+    readonly transactionId: Hex;
+    readonly bridge: string;
+    readonly integrator: string;
+    readonly referrer: Hex;
+    readonly sendingAssetId: Hex;
+    readonly receiver: Hex;
+    readonly minAmount: bigint;
+    readonly destinationChainId: bigint;
+    readonly hasSourceSwaps: boolean;
+    readonly hasDestinationCall: boolean;
+};
+/**
+ * What THIS APPLICATION asked LI.FI for, independent of anything the
+ * response itself claims — the only thing a decoded transaction is allowed
+ * to be checked against.
+ */
+export type LifiExecutionExpectation = {
+    /**
+     * Where the bridged asset lands if the route needs no destination call
+     * (the plain endpoint's recipient), or where it lands if the destination
+     * call reverts (the contract-calls endpoint's fallback address) — see the
+     * `BridgeData.receiver` note at the top of this file for why these two are
+     * NOT the same field despite the shared name.
+     */
+    readonly receiver: Hex;
+    /** The chain the entry call (or the plain delivery) must land on. */
+    readonly destinationChainId: number;
+    /** The token this application is paying with on the origin chain. */
+    readonly sendingAssetId: Hex;
+    /** Whether this application attached an omnibridge entry call. */
+    readonly hasDestinationCall: boolean;
+    /**
+     * The guaranteed minimum this application asked LI.FI to deliver, or
+     * `null` for the plain (forward-solved) endpoint, which names no such
+     * minimum — the delivered amount is read back from the response instead
+     * of constrained by the request. See `ConsolidatedQuote.toAmount`.
+     */
+    readonly minimumAmount: bigint | null;
+};
+/** The transaction fields {@link verifyLifiEvmExecution} reads off the raw response. */
+export type LifiExecutionTransactionRequest = {
+    readonly to: Hex;
+    readonly data: Hex;
+    readonly value: bigint;
+    readonly chainId: number;
+};
+/**
+ * Verifies a LI.FI EVM execution transaction against what this application
+ * asked for, throwing {@link LifiExecutionRefusedError} on any disagreement.
+ * Returns normally — carrying nothing, since the caller already holds the
+ * transaction it validated — when every check passes.
+ *
+ * See this module's top-of-file doc comment for what is checked and why.
+ *
+ * @param transactionRequest - the parsed `to`/`data`/`value`/`chainId` this
+ *   application is about to hand to a wallet
+ * @param approvalAddress - `estimate.approvalAddress` from the same
+ *   response, or `null` when the route needs no token approval
+ * @param expectation - what this application actually asked for
+ */
+export declare const verifyLifiEvmExecution: (transactionRequest: LifiExecutionTransactionRequest, approvalAddress: Hex | null, expectation: LifiExecutionExpectation) => void;