@coinlist-co/react 0.11.0 → 0.11.1-rc.10770e8

package/dist/client/index.d.ts

@@ -1,10 +1,11 @@
 import * as react_jsx_runtime from 'react/jsx-runtime';
 import * as react from 'react';
 import { ReactNode, ButtonHTMLAttributes } from 'react';
-import { A as AuthorizationCode, C as CodeVerifier, E as EvmWalletAddress, a as EthereumChain, T as Tx, b as Erc20Namespace, c as EvmContractAddress, B as BlockchainAmount, d as CoinListTokenSaleNamespace, O as OfferId, e as OfferOptionId, f as AssetId, P as Participation, g as CoinListTokenSaleNamespaceImpl, S as SharedNamespaceContext, h as OndoNamespace, i as AssetSymbol, j as OndoSwapTransaction, k as OndoNamespaceImpl, l as SuperstateSwapNamespace, W as WalletsNamespace, m as Bps, n as SuperstateSwapNamespaceImpl, R as RequirementsNamespace, o as Requirement, p as RequirementsNamespaceImpl, q as Config, r as OAuthAccessToken, s as OffersNamespace, t as TokensNamespace, u as Erc20Asset, v as OfferDetail, w as StablecoinSymbol, x as OfferType, y as Offer, z as RequirementStatusInfo, D as RequirementType, F as RequirementStatusValue, G as OfferOptionAddress, H as RequirementId, K as KycLevelName, I as WalletChallengeType, J as DocumentSubmission, L as OndoTradingStatus, M as AssetDecimals, N as OndoQuote, Q as OrderBookSide, U as OndoQuoteSize, V as BuildOndoSwapTransactionParams, X as OfferOptionAddressId, Y as TokenMetadata, Z as TokenIdentifier } from '../config-B5mwS_2l.js';
-export { _ as HttpError, $ as HttpResponse, a0 as KycToken } from '../config-B5mwS_2l.js';
-import { P as PKCEConfig, S as SwapQuote, A as AssetIconUrl, a as ShortenedWalletAddress, F as FormattedAmountAssetUi, b as FormattedPercentUi, T as TxExplorerUrl, N as NonEmptyArray } from '../collections-CZhHoQHr.js';
-import { Hash, Hex, Abi, TransactionReceipt } from 'viem';
+import { A as AuthorizationCode, C as CodeVerifier, L as Logger, W as WalletError, E as Erc20Namespace, a as EthereumChain, b as EvmContractAddress, B as BlockchainAmount, c as CoinListTokenSaleNamespace, O as OfferId, d as OfferOptionId, e as AssetId, P as Participation, f as CoinListTokenSaleNamespaceImpl, S as SharedNamespaceContext, g as OndoNamespace, h as AssetSymbol, i as OndoBuyTransaction, j as OndoSellTransaction, k as OndoSwapTransactionCore, l as OrderBookSide, m as OndoNamespaceImpl, n as SuperstateSwapNamespace, o as WalletsNamespace, p as Bps, q as EvmWalletAddress, r as SuperstateSwapNamespaceImpl, R as RequirementsNamespace, s as Requirement, t as RequirementsNamespaceImpl, u as Config, v as OAuthAccessToken, w as OffersNamespace, T as TokensNamespace, x as StablecoinSymbol, y as Erc20Asset, z as OfferDetail, D as OfferType, F as Offer, G as RequirementStatusInfo, H as RequirementType, I as RequirementStatusValue, J as OfferOptionAddress, K as RequirementId, M as KycLevelName, N as DocumentSubmission, Q as WalletChallengeType, U as PinoLoggerOptions, V as OndoTradingStatus, X as AssetDecimals, Y as BuildOndoBuyParams, Z as BuildOndoSellParams, _ as OndoQuote, $ as OndoQuoteSize, a0 as OfferOptionAddressId, a1 as TokenMetadata, a2 as TokenIdentifier } from '../config-CMl1bR3F.js';
+export { a3 as DebugEvent, a4 as FrontlineEventId, a5 as HttpError, a6 as HttpResponse, a7 as KycToken, a8 as LogBinding, a9 as LogBindings, aa as LogCause, ab as LogLevel, ac as LogScope, ad as LogValue, ae as ProductionLogLevel, af as RedactedWalletError, ag as RequestId, ah as SafeEvent, ai as SafeFields, aj as UnredactedFields } from '../config-CMl1bR3F.js';
+import { P as PKCEConfig, E as EvmWallet, S as SwapQuote, A as AssetIconUrl, a as ShortenedWalletAddress, F as FormattedAmountAssetUi, b as FormattedPercentUi, T as TxExplorerUrl, C as ConnectWallet, N as NonEmptyArray } from '../collections-BrX9rRWc.js';
+export { B as BroadcastTxParams, c as EvmSigner, W as WriteContractParams } from '../collections-BrX9rRWc.js';
+import { Hash } from 'viem';
 import * as class_variance_authority_types from 'class-variance-authority/types';
 import { VariantProps } from 'class-variance-authority';
 
@@ -94,84 +95,24 @@ type ClientAuthSession = {
  */
 type ClientAuthConfig = PKCEConfig & {
     readonly coinlistBaseUrl?: string;
+    readonly logger?: Logger;
 };
 declare class ClientAuthNamespaceImpl implements ClientAuthNamespace {
     private readonly config;
     private readonly session;
+    private readonly log;
     constructor(config: ClientAuthConfig, session: ClientAuthSession);
     getState(): AuthState;
     startOAuth(): Promise<void>;
+    private redirectToOAuth;
+    /**
+     * Every failure here is silent from the browser's side - a state mismatch
+     * and a missing verifier both just leave the user logged out - so the
+     * reason is logged rather than left for the host to infer from a callback.
+     */
     completeOAuth(): OauthClientResult;
     logout(): void;
-}
-
-/**
- * A classified wallet/transaction failure. The SDK derives this from whatever
- * the {@link EvmWallet} throws, so consumers get a stable, typed error
- * shape regardless of the underlying wallet library.
- */
-type WalletError = {
-    type: 'user_rejected';
-} | {
-    type: 'insufficient_funds';
-} | {
-    type: 'contract_reverted';
-    reason: string;
-} | {
-    type: 'timeout';
-    hash: Hash;
-} | {
-    type: 'unknown';
-    cause: unknown;
-};
-/**
- * Classifies an error thrown by an {@link EvmWallet} into a typed
- * {@link WalletError}. Pass the transaction `hash` when awaiting a receipt so a
- * timeout can be reported against it.
- */
-declare function classifyWalletError(error: unknown, ctx?: {
-    hash?: Hash;
-}): WalletError;
-
-type WriteContractParams = {
-    abi: Abi;
-    address: `0x${string}`;
-    functionName: string;
-    args?: readonly unknown[];
-    value?: bigint;
-    chain: EthereumChain;
-};
-type BroadcastTxParams = Tx & {
-    chain: EthereumChain;
-};
-/**
- * The signing-only wallet capability: address + `signMessage`. This is all the
- * external-wallet ownership proof needs (see `useConnectWallet`), so hosts can
- * satisfy that flow without implementing on-chain capabilities. The richer
- * {@link EvmWallet} extends this for swap flows.
- *
- * SDK users implement this against their own wallet stack (e.g. viem, wagmi,
- * Privy). `signMessage` throws on failure and the SDK classifies it.
- */
-interface EvmSigner {
-    readonly address: EvmWalletAddress;
-    signMessage(message: string): Promise<Hex>;
-}
-/**
- * The full on-chain wallet the SDK needs to run the swap flows: an
- * {@link EvmSigner} plus contract writes, raw-tx broadcast, and confirmation.
- * SDK users implement this against their own wallet stack (e.g. viem, wagmi,
- * Privy).
- *
- * Methods throw on failure. The SDK catches and classifies the thrown error
- * (viem's `UserRejectedRequestError`, `InsufficientFundsError`, timeouts, …)
- * into a typed {@link WalletError}, so implementers can simply let their wallet
- * library's errors propagate.
- */
-interface EvmWallet extends EvmSigner {
-    writeContract(params: WriteContractParams): Promise<Hash>;
-    broadcastRawTx(params: BroadcastTxParams): Promise<Hash>;
-    awaitTx(hash: Hash, chain: EthereumChain): Promise<TransactionReceipt>;
+    private readOauthCallback;
 }
 
 type Erc20AllowancePhase = 'checking-allowance' | 'resetting-allowance' | 'confirming-allowance-reset' | 'approving' | 'confirming-approval';
@@ -315,12 +256,16 @@ declare class ClientCoinListTokenSaleNamespaceImpl extends CoinListTokenSaleName
 }
 
 /**
- * Progress phases emitted by {@link prepareOndoSwap}, in the order they occur.
- * An allowance that already covers the order skips the approval phases.
+ * Progress phases emitted while an order is being prepared, in the order they
+ * occur. An allowance that already covers the order skips the approval phases.
  */
 type OndoSwapPreparationPhase = Erc20AllowancePhase | 'building-transaction';
 /**
- * A step-tagged reason {@link prepareOndoSwap} failed.
+ * A step-tagged reason a preparation failed.
+ *
+ * Shared by both directions because every arm names a *remedy* rather than a
+ * trade: an unsupported chain, a refused approval and a build that would not
+ * complete are fixed the same way whichever token was being approved.
  *
  * `insufficient-allowance` is separated from the generic build failure because
  * it is the one with a remedy: frontline reads the allowance before asking
@@ -336,14 +281,24 @@ type OndoSwapPreparationError = {
 } | {
     step: 'build-transaction';
 };
-type OndoSwapPreparationResult = {
+/**
+ * A prepared order of whichever kind was asked for, or the step that stopped
+ * it.
+ *
+ * Generic in the transaction rather than a union over the two, so a caller
+ * that asked for a sale cannot be handed a purchase to narrow.
+ */
+type OndoSwapPreparationResult<T> = {
     type: 'success';
-    transaction: OndoSwapTransaction;
+    transaction: T;
 } | {
     type: 'error';
     error: OndoSwapPreparationError;
 };
-type PrepareOndoSwapParams = {
+type OndoBuyPreparationResult = OndoSwapPreparationResult<OndoBuyTransaction>;
+type OndoSellPreparationResult = OndoSwapPreparationResult<OndoSellTransaction>;
+/** What both preparations take, before the two fields whose meaning forks. */
+type PrepareOndoSwapParamsCore = {
     ondo: OndoNamespace;
     erc20: Erc20Namespace;
     wallet: EvmWallet;
@@ -351,21 +306,36 @@ type PrepareOndoSwapParams = {
     symbol: AssetSymbol;
     /** The chain the swap executes on, which the swap contract lives on. */
     chain: EthereumChain;
+    onProgress?: (phase: OndoSwapPreparationPhase) => void;
+};
+type PrepareOndoBuyParams = PrepareOndoSwapParamsCore & {
     /**
-     * The ERC-20 being spent, e.g. USDC on `chain`.
+     * The funding token being spent - USDC on `chain`.
      *
-     * Approval only - it is not sent to frontline, which resolves the funding
-     * token from the offer. The two agreeing is what the allowance check on the
-     * far side is confirming.
+     * Approval only - it is not sent to frontline, which resolves both tokens
+     * from the offer. The two agreeing is what the allowance check on the far
+     * side is confirming.
      */
     tokenAddress: EvmContractAddress;
-    /** How much of `tokenAddress` to spend, in its base units. */
+    /** How much of the funding token to spend, in its base units. */
+    amount: BlockchainAmount;
+};
+type PrepareOndoSellParams = PrepareOndoSwapParamsCore & {
+    /**
+     * The **asset** being sold, on `chain` - not a stablecoin. A sale delivers
+     * the asset, so this is what the swap contract must be approved to pull.
+     *
+     * Approval only, as on a purchase. Unlike a purchase, the SDK has no
+     * registry entry to fall back on: the address comes off the sell quote and
+     * nowhere else.
+     */
+    tokenAddress: EvmContractAddress;
+    /** How much of the asset to sell, in the asset's base units. */
     amount: BlockchainAmount;
-    onProgress?: (phase: OndoSwapPreparationPhase) => void;
 };
 /**
- * Gets an order ready to place: ensures the swap contract may pull `amount` of
- * `tokenAddress`, then builds the transaction that spends it.
+ * Gets a purchase ready to place: ensures the swap contract may pull `amount`
+ * of the funding token, then builds the transaction that spends it.
  *
  * The approval comes first deliberately. Built calldata is only good for about
  * a minute and an approval takes most of one to mine, so building first would
@@ -378,7 +348,16 @@ type PrepareOndoSwapParams = {
  * Total: every failure is returned step-tagged rather than thrown, so a caller
  * can map each one to its own copy.
  */
-declare function prepareOndoSwap(params: PrepareOndoSwapParams): Promise<OndoSwapPreparationResult>;
+declare function prepareOndoBuy(params: PrepareOndoBuyParams): Promise<OndoBuyPreparationResult>;
+/**
+ * Gets a sale ready to place: ensures the swap contract may pull `amount` of
+ * the **asset**, then builds the transaction that spends it.
+ *
+ * Identical in shape to {@link prepareOndoBuy} and different in what it
+ * approves, which is the only thing about a sale that is not the purchase
+ * inverted. Same ordering, and for the same reason.
+ */
+declare function prepareOndoSell(params: PrepareOndoSellParams): Promise<OndoSellPreparationResult>;
 /** Progress phases emitted by {@link executeOndoSwap}, in order. */
 type OndoSwapExecutionPhase = 'broadcasting-swap' | 'confirming-swap';
 /**
@@ -399,21 +378,28 @@ type OndoSwapExecutionError = {
 } | {
     step: 'swap-reverted';
 };
-type OndoSwapExecutionResult = {
+type OndoSwapExecutionResult<T> = {
     type: 'success';
     txHash: Hash;
-    transaction: OndoSwapTransaction;
+    transaction: T;
 } | {
     type: 'error';
     error: OndoSwapExecutionError;
 };
-type ExecuteOndoSwapParams = {
+type OndoBuyExecutionResult = OndoSwapExecutionResult<OndoBuyTransaction>;
+type OndoSellExecutionResult = OndoSwapExecutionResult<OndoSellTransaction>;
+type ExecuteOndoSwapParams<T> = {
     wallet: EvmWallet;
     /**
-     * The transaction to fill, from {@link prepareOndoSwap} or
-     * `ondo.buildSwapTransaction`.
+     * The transaction to fill, from {@link prepareOndoBuy},
+     * {@link prepareOndoSell}, or either namespace builder.
+     *
+     * Typed by what it carries rather than by which direction built it:
+     * broadcasting reads the calldata, the deadline and nothing else, so a
+     * purchase and a sale are the same job here. The concrete type travels
+     * through to the result so a caller gets back what it handed in.
      */
-    transaction: OndoSwapTransaction;
+    transaction: T;
     /**
      * The chain it was built for.
      *
@@ -431,8 +417,12 @@ type ExecuteOndoSwapParams = {
     onProgress?: (phase: OndoSwapExecutionPhase) => void;
 };
 /**
- * Fills a built transaction: broadcasts the calldata Ondo encoded and waits
- * for it to mine.
+ * Fills a built transaction, whichever direction built it: broadcasts the
+ * calldata Ondo encoded and waits for it to mine.
+ *
+ * The one function both directions share, because it is the one step that does
+ * not depend on which token moves - {@link OndoSwapTransactionCore} is exactly
+ * what it reads.
  *
  * The calldata is broadcast verbatim - the SDK never re-encodes it, because
  * the contract verifies a signature over the exact arguments inside it.
@@ -442,39 +432,61 @@ type ExecuteOndoSwapParams = {
  * encoded in the calldata), and its `to` must be the contract the approval
  * named, since anything else cannot pull the funds.
  */
-declare function executeOndoSwap(params: ExecuteOndoSwapParams): Promise<OndoSwapExecutionResult>;
+declare function executeOndoSwap<T extends OndoSwapTransactionCore>(params: ExecuteOndoSwapParams<T>): Promise<OndoSwapExecutionResult<T>>;
 
 /**
- * The Ondo namespace plus the two halves of placing an order, which need a
- * wallet and so cannot live on the shared namespace.
+ * The Ondo namespace plus the halves of placing an order that need a wallet,
+ * and so cannot live on the shared namespace.
  *
- * They are two calls rather than one because the flow is two user decisions:
- * the buyer commits to an amount (approving the spend), reviews firm numbers,
- * and only then places the order. Bundling them would mean approving and
- * filling behind a single button, and would burn most of the transaction's
- * ~60-second life on the approval.
+ * Preparing and executing are two calls rather than one because the flow is
+ * two user decisions: the trader commits to an amount (approving the spend),
+ * reviews firm numbers, and only then places the order. Bundling them would
+ * mean approving and filling behind a single button, and would burn most of
+ * the transaction's ~60-second life on the approval.
+ *
+ * Preparing is two methods and executing is one, mirroring where the two
+ * directions actually differ: a purchase approves the funding token and a sale
+ * approves the asset, while broadcasting reads calldata and a deadline and
+ * knows nothing about either.
  *
  * `erc20` is supplied internally, so callers hand over only a wallet and an
  * order.
  */
 interface ClientOndoNamespace extends OndoNamespace {
     /**
-     * Approves the swap contract to spend `amount`, then builds the transaction
-     * that spends it. Returns a step-tagged result rather than throwing.
+     * Approves the swap contract to spend `amount` of the funding token, then
+     * builds the purchase that spends it. Returns a step-tagged result rather
+     * than throwing.
+     */
+    prepareBuy(params: Omit<PrepareOndoBuyParams, 'ondo' | 'erc20'>): Promise<OndoBuyPreparationResult>;
+    /**
+     * Approves the swap contract to pull `amount` of the **asset**, then builds
+     * the sale that delivers it. Returns a step-tagged result rather than
+     * throwing.
      */
-    prepareSwap(params: Omit<PrepareOndoSwapParams, 'ondo' | 'erc20'>): Promise<OndoSwapPreparationResult>;
+    prepareSell(params: Omit<PrepareOndoSellParams, 'ondo' | 'erc20'>): Promise<OndoSellPreparationResult>;
     /**
      * Broadcasts a built transaction and waits for it to mine, refusing one that
      * has expired or points at an unexpected contract. Returns a step-tagged
      * result rather than throwing.
+     *
+     * Takes either direction's transaction and hands the same one back. The
+     * `side` tag is required here and not by {@link executeOndoSwap} itself
+     * because this is the layer that logs: a flow event without a direction
+     * cannot be read back.
      */
-    executeSwap(params: ExecuteOndoSwapParams): Promise<OndoSwapExecutionResult>;
+    executeSwap<T extends OndoSwapTransactionCore & {
+        side: OrderBookSide;
+    }>(params: ExecuteOndoSwapParams<T>): Promise<OndoSwapExecutionResult<T>>;
 }
 declare class ClientOndoNamespaceImpl extends OndoNamespaceImpl implements ClientOndoNamespace {
     private readonly erc20;
     constructor(ctx: SharedNamespaceContext, erc20: Erc20Namespace);
-    prepareSwap(params: Omit<PrepareOndoSwapParams, 'ondo' | 'erc20'>): Promise<OndoSwapPreparationResult>;
-    executeSwap(params: ExecuteOndoSwapParams): Promise<OndoSwapExecutionResult>;
+    prepareBuy(params: Omit<PrepareOndoBuyParams, 'ondo' | 'erc20'>): Promise<OndoBuyPreparationResult>;
+    prepareSell(params: Omit<PrepareOndoSellParams, 'ondo' | 'erc20'>): Promise<OndoSellPreparationResult>;
+    executeSwap<T extends OndoSwapTransactionCore & {
+        side: OrderBookSide;
+    }>(params: ExecuteOndoSwapParams<T>): Promise<OndoSwapExecutionResult<T>>;
 }
 
 /**
@@ -660,6 +672,8 @@ interface ClientSupportNamespace {
     contact(): void;
 }
 declare class ClientSupportNamespaceImpl implements ClientSupportNamespace {
+    private readonly log;
+    constructor(logger?: Logger | null);
     contact(): void;
 }
 
@@ -742,10 +756,15 @@ interface CoinListClient {
     /**
      * Ondo swaps: whether an asset is tradable right now and what it costs - e.g.
      * `coinlist.ondo.getQuote({ ... })` - plus placing an order, in the two
-     * halves the flow actually has: `prepareSwap` (approve, then commit a firm
-     * quote) and `executeSwap` (broadcast it).
+     * halves the flow actually has: `prepareBuy` / `prepareSell` (approve, then
+     * commit a firm quote) and `executeSwap` (broadcast it).
      *
-     * The reads are free to poll while the user edits an order. `prepareSwap` is
+     * Preparing is two methods because the directions approve different tokens -
+     * the funding coin on a purchase, the asset on a sale - and commit to
+     * different terms; broadcasting is one, because it reads calldata and a
+     * deadline and knows about neither.
+     *
+     * The reads are free to poll while the user edits an order. Preparing is
      * not: committing a quote spends an attestation.
      *
      * No CoinList fee is applied to a read quote; see
@@ -756,7 +775,7 @@ interface CoinListClient {
      * Token display metadata (name, symbol, decimals, logos) from CoinList's
      * public token registry, keyed by chain + contract address — e.g.
      * `coinlist.tokens.get({ chain, address })` for an entry of
-     * `OfferDetail.tokens`, or `coinlist.tokens.list(chain)` for a whole
+     * `Offer.tokens`, or `coinlist.tokens.list()` for the whole
      * catalogue in one request.
      *
      * Public and unauthenticated: unlike the other namespaces, its methods never
@@ -917,6 +936,124 @@ interface CoinListSignInCardViewProps {
  */
 declare function CoinListSignInCardView({ state, onEvent, className, }: CoinListSignInCardViewProps): ReactNode;
 
+/**
+ * A filled Ondo order, as the confirmation dialog and the host's
+ * `onOrderConfirmed` callback need it.
+ *
+ * It lives here rather than beside either review viewmodel because both
+ * products produce one. Declaring it in `ondo/buy/` would make the sell
+ * viewmodel import a sibling product's module - which the `shared/` ladder
+ * forbids for the reason it always does: two products that reach sideways can
+ * no longer be moved or deleted on their own.
+ *
+ * It names no asset beyond the one that was spent. The transaction does not
+ * carry one, and rebuilding an `Erc20Asset` here would mean inventing a
+ * `decimals` - the quote's answers for a different quantity, and the
+ * transaction's is a scale rather than a property of the token. A host that
+ * wants to know what was traded has the `offer` and `ondoSymbol` it passed in.
+ */
+type OndoOrderPlaced = OndoBuyOrderPlaced | OndoSellOrderPlaced;
+/**
+ * The common half of an {@link OndoOrderPlaced}, before its side's terms.
+ *
+ * The transaction that was broadcast is not here, because it is not common:
+ * it carries the same `side` this order does, and saying so in prose left a
+ * sell order holding a buy transaction constructible and its
+ * `minimumReceiveOutputAmount` unreachable behind a narrowed `side`. Each arm
+ * names its own instead.
+ */
+type OndoOrderPlacedCore = {
+    txHash: Hash;
+    /** What the trader spent, in the input asset's base units. */
+    amount: BlockchainAmount;
+    wallet: EvmWallet;
+};
+/** A filled purchase: a stablecoin spent, the asset received. */
+type OndoBuyOrderPlaced = OndoOrderPlacedCore & OndoBuyOrderTerms;
+/** A filled sale: the asset spent, the settlement coin received. */
+type OndoSellOrderPlaced = OndoOrderPlacedCore & OndoSellOrderTerms;
+/**
+ * A buy spends a stablecoin the SDK ships a registry entry for, so its input
+ * asset is narrowed to one - which is what keeps `TOKEN_REGISTRY.erc20` total
+ * at the call sites that name it.
+ */
+type OndoBuyOrderTerms = {
+    side: 'buy';
+    inputAsset: StablecoinSymbol;
+    /** The purchase that was broadcast, and the deposit it was struck against. */
+    transaction: OndoBuyTransaction;
+};
+/**
+ * A sell spends the Ondo asset, which is in no registry: its address and
+ * decimals come off the quote, and only its symbol is carried here. Hence the
+ * wider `AssetSymbol`, and hence a SUM rather than one widened field - a buy
+ * that lost its stablecoin guarantee would be the cost of sharing one.
+ */
+type OndoSellOrderTerms = {
+    side: 'sell';
+    inputAsset: AssetSymbol;
+    /** The sale that was broadcast, and the floor under the proceeds it names. */
+    transaction: OndoSellTransaction;
+};
+
+/**
+ * The wallets a checkout can spend from, supplied by the host.
+ *
+ * The SDK ships no wallet stack and is not coupled to Privy, AppKit or
+ * anything else - a partner may be a wallet provider themselves - so wallet
+ * discovery and connection are inverted onto the host. It hands over ready
+ * {@link EvmWallet}s and two lambdas; the SDK decides nothing about how they
+ * came to exist.
+ *
+ * There is no separate wallet model here on purpose: `EvmWallet` already
+ * carries the `address`, so a `{ address, signer }` pair would be a second
+ * wallet type to keep in sync with the first.
+ *
+ * Everything the row displays beyond the address - the network name - comes
+ * from the checkout's execution chain rather than from the wallet, because
+ * that is the chain the transaction goes to whatever the wallet is currently
+ * pointed at.
+ */
+type CheckoutWalletSelection = {
+    /**
+     * The user's embedded (custodial) wallets, in display order. Empty when they
+     * have none, which is a normal state, not an error.
+     */
+    embedded: EvmWallet[];
+    /** The connected external wallet, or `null` while none is connected. */
+    external: EvmWallet | null;
+    /**
+     * A wallet the host has already settled on, or `null` to let the user pick.
+     *
+     * When set, a checkout that supports it skips its wallet step entirely and
+     * opens on the amount, renumbering the steps that remain. That is for the
+     * host that already knows the answer - a sell page reached from a position
+     * knows which wallet holds it, and asking again would be a question with one
+     * possible answer.
+     *
+     * It does not have to appear in `embedded` or `external`. The host supplies a
+     * ready {@link EvmWallet} either way, and the SDK never resolves this back to
+     * a row.
+     *
+     * **Only the Ondo sell checkout honours it today.** The field is on this seam
+     * rather than on one provider's config because nothing about it is Ondo's -
+     * any flow that opens on a wallet step could skip one - but a provider that
+     * has not adopted it ignores it rather than half-implementing it, so do not
+     * assume a skip from the field being set.
+     */
+    preselected: EvmWallet | null;
+    /**
+     * Opens the host's wallet connector. Resolves once the attempt finishes; the
+     * SDK reads the outcome from `external` on the next render rather than from
+     * a return value, so a host that connects through a redirect still works.
+     *
+     * Rejecting is how a declined or failed connection is reported.
+     */
+    connectExternal: () => Promise<void>;
+    /** Disconnects the external wallet. Resolves when it is gone. */
+    disconnectExternal: () => Promise<void>;
+};
+
 /**
  * UI models every checkout provider needs. Provider-specific models stay in
  * that provider's `use{X}ViewModel.types`; these live here because Ondo and
@@ -1093,294 +1230,104 @@ type CheckoutSelectableInputAssetUi = {
 };
 
 /**
- * Step 3 of the Ondo checkout: what the order comes to, and placing it.
+ * Step 3 of the Superstate checkout: what the swap comes to, the slippage it
+ * will tolerate, and placing it.
  *
- * `loading` is a separate arm from `active` rather than a flag inside it, so
- * the skeleton renders from a state that carries no order details at all —
- * there is nothing for the viewmodel to invent while the first quote is in
- * flight. Once details exist they stay on screen through every later refresh,
- * and it is `quote` that reports whether they can still be acted on.
+ * `loading` is its own arm rather than a flag inside `active`, so the skeleton
+ * renders from a state that carries no figures at all — there is nothing for
+ * the viewmodel to invent while a quote for the confirmed amount is in flight.
+ * The quote is repriced on a poll, and the amount the user committed to is only
+ * quoted once that poll catches up, so this arm is entered again on every
+ * amount change rather than only on first load.
+ *
+ * `error` is where a quote that cannot be honoured lands: no quote at all, or
+ * one asking for more than the user offered.
  */
-type OndoReviewUiState = {
+type SuperstateReviewUiState = {
     type: 'incomplete';
 }
-/** The first quote is in flight; nothing to show yet. */
+/** No quote yet for the confirmed amount; nothing to show. */
  | {
     type: 'loading';
 }
-/** No quote could be loaded at all. */
+/** No quote could be produced, or the one produced cannot be honoured. */
  | {
     type: 'error';
 } | {
     type: 'active';
     /** What the user is buying. */
     outputAsset: CheckoutAssetUi;
-    /** The quantity, e.g. `2.639 AAPLon`. */
+    /** The quantity the quote offers, e.g. `981.2431 USTB`. */
     outputAmount: FormattedAmountAssetUi;
-    /** Where the asset lands — the wallet confirmed in step 1. */
-    recipientAddress: ShortenedWalletAddress;
-    /** Price of one whole token, e.g. `$378.99`. */
-    pricePerShare: FormattedAmountAssetUi;
     /**
-     * `null` while no CoinList fee is disclosed: no Ondo endpoint returns one
-     * and none is applied to the quote (ENG-1680). The row is hidden rather
-     * than showing a placeholder.
+     * The least the user can end up with once slippage is applied — what
+     * `minOut` is set to on-chain, so the swap reverts rather than filling
+     * below it.
      */
-    coinlistFee: FormattedAmountAssetUi | null;
-    /** What the user pays in the input asset, e.g. `1,000.00 USDC`. */
+    minOutputAmount: FormattedAmountAssetUi;
+    /** Where the asset lands — the wallet authorized in step 1. */
+    recipientAddress: ShortenedWalletAddress;
+    /** Price of one whole output token, e.g. `$10.19`. */
+    pricePerShare: FormattedAmountAssetUi;
+    /** The protocol fee the quote carries, in the input asset. */
+    coinlistFee: FormattedAmountAssetUi;
+    /** Input plus fee: what leaves the wallet, e.g. `$1,000.00`. */
     total: FormattedAmountAssetUi;
-    quote: OndoQuoteStatusUi;
+    slippage: SuperstateSlippageUi;
     placeOrderCta: CheckoutCtaUi;
     /** A failure from placing the order, distinct from a quote problem. */
     error: string | null;
 };
 /**
- * Whether the shown numbers can still be traded on.
+ * The slippage tolerance, and the picker that changes it.
  *
- * A quote is only good for a few seconds, so this drives the line above the CTA
- * and whether the CTA can be pressed at all. `refresh-failed` is its own arm
- * rather than folding into the step's `error`, because the remedy differs: a
- * failed refresh is fixed by refreshing again, a failed order is not.
+ * `expanded` lives here rather than in the View because the tolerance and the
+ * disclosure that sets it are one control: the button's label is the current
+ * percent, and the description below explains what that percent does. Splitting
+ * them would make the View re-derive copy the viewmodel already formatted.
  */
-type OndoQuoteStatusUi = 
-/** Still good. `expiresInLabel` is the countdown copy, already formatted. */
-{
-    type: 'valid';
-    expiresInLabel: string;
-}
-/** A refresh is in flight; the previous numbers are still on screen. */
- | {
-    type: 'refreshing';
-}
-/** Too old to trade on. The user must refresh before placing the order. */
- | {
-    type: 'expired';
-}
-/** The refresh failed. `message` says why. */
- | {
-    type: 'refresh-failed';
-    message: string;
+type SuperstateSlippageUi = {
+    /** The tolerance in force, e.g. `0.5%`. */
+    percent: FormattedPercentUi;
+    expanded: boolean;
+    /** What this tolerance means, already interpolated with `percent`. */
+    description: string;
+    options: SuperstateSlippageOptionUi[];
 };
-type OndoReviewUiEvent = {
-    type: 'ON_REFRESH_QUOTE';
-}
-/** Retry from the `error` arm, where there is no quote to refresh. */
- | {
-    type: 'ON_RETRY';
+type SuperstateSlippageOptionUi = {
+    /**
+     * The value this option sets. Carried rather than the formatted percent so
+     * the event names an exact tolerance rather than a rendering of one.
+     */
+    bps: Bps;
+    percent: FormattedPercentUi;
+    selected: boolean;
+};
+type SuperstateReviewUiEvent = {
+    type: 'ON_SLIPPAGE_CLICK';
+} | {
+    type: 'ON_SLIPPAGE_SELECT';
+    bps: Bps;
 } | {
     type: 'ON_PLACE_ORDER';
 };
 
-type OndoReviewStepInput = {
-    type: 'incomplete';
-} | {
-    type: 'active';
-    /** The wallet that signs, pays, and receives. */
+/** What the swap actually filled at, once it has mined. */
+type SuperstateOrderPlaced = {
+    swapTxHash: Hash;
     wallet: EvmWallet;
-    /** What the user is spending, in the input asset's base units. */
-    amount: BlockchainAmount;
     inputAsset: StablecoinSymbol;
+    /** The input the contract pulled, excluding the fee. */
+    inputAmount: BlockchainAmount;
+    fee: BlockchainAmount;
+    outputAsset: Erc20Asset;
     /**
-     * The transaction `prepareSwap` already built for this order. Omitting
-     * it makes this step build one itself, which is the path a partner
-     * driving the review on its own takes - and the only way its `loading`
-     * and `error` states are reached.
-     */
-    transaction?: OndoSwapTransaction;
-};
-/**
- * A filled order, as the confirmation dialog needs it.
- *
- * It names no asset. The transaction does not carry one, and rebuilding an
- * `Erc20Asset` here would mean inventing a `decimals` - the quote's answers
- * for a different quantity, and the transaction's is a scale rather than a
- * property of the token. A host that wants to know what was bought has the
- * `offer` and `ondoSymbol` it passed in.
- */
-type OndoOrderPlaced = {
-    txHash: Hash;
-    transaction: OndoSwapTransaction;
-    /** What the buyer paid, in the input asset. */
-    amount: BlockchainAmount;
-    inputAsset: StablecoinSymbol;
-    wallet: EvmWallet;
-};
-interface UseOndoReviewViewModelOptions {
-    stepInput: OndoReviewStepInput;
-    /**
-     * Ondo's API symbol, e.g. `AAPLon`. Rebuilds the transaction, and names the
-     * bought asset on the card.
+     * How much arrived. Decoded from the `Swapped` event, except on the fallback
+     * path `outputAmountConfirmed` marks.
      */
-    ondoSymbol: AssetSymbol;
-    /** The chain the order executes on. */
-    chain: EthereumChain;
+    outputAmount: BlockchainAmount;
     /**
-     * The offer being bought: the asset's name and its only icon.
-     *
-     * The identity comes from here rather than from the price poll, so the card
-     * agrees with the reference panel beside it and a dropped poll cannot leave
-     * the review unable to say what was bought.
-     */
-    offer: OfferDetail;
-    /** Called once the swap has mined. */
-    onComplete: (order: OndoOrderPlaced) => void;
-}
-interface UseOndoReviewViewModelResult {
-    state: OndoReviewUiState;
-    onEvent: (event: OndoReviewUiEvent) => void;
-}
-/**
- * Drives step 3 of the Ondo checkout: what the order comes to, how long the
- * price holds, and placing it.
- *
- * The quote is firm and short-lived, so most of this is about time. The
- * countdown drives the line above the CTA, and a quote inside
- * {@link ONDO_QUOTE_EXPIRY_THRESHOLD_MS} of its deadline is treated as already
- * gone: placing an order is not instant, and a transaction that arrives after
- * the deadline reverts at the user's expense.
- *
- * Refreshing is always something the user asks for. Each refresh builds a new
- * transaction, which spends an attestation, so nothing here is on a timer.
- */
-declare function useOndoReviewViewModel({ stepInput, ondoSymbol, chain, offer, onComplete, }: UseOndoReviewViewModelOptions): UseOndoReviewViewModelResult;
-
-/**
- * The wallets a checkout can spend from, supplied by the host.
- *
- * The SDK ships no wallet stack and is not coupled to Privy, AppKit or
- * anything else - a partner may be a wallet provider themselves - so wallet
- * discovery and connection are inverted onto the host. It hands over ready
- * {@link EvmWallet}s and two lambdas; the SDK decides nothing about how they
- * came to exist.
- *
- * There is no separate wallet model here on purpose: `EvmWallet` already
- * carries the `address`, so a `{ address, signer }` pair would be a second
- * wallet type to keep in sync with the first.
- *
- * Everything the row displays beyond the address - the network name - comes
- * from the checkout's execution chain rather than from the wallet, because
- * that is the chain the transaction goes to whatever the wallet is currently
- * pointed at.
- */
-type CheckoutWalletSelection = {
-    /**
-     * The user's embedded (custodial) wallets, in display order. Empty when they
-     * have none, which is a normal state, not an error.
-     */
-    embedded: EvmWallet[];
-    /** The connected external wallet, or `null` while none is connected. */
-    external: EvmWallet | null;
-    /**
-     * Opens the host's wallet connector. Resolves once the attempt finishes; the
-     * SDK reads the outcome from `external` on the next render rather than from
-     * a return value, so a host that connects through a redirect still works.
-     *
-     * Rejecting is how a declined or failed connection is reported.
-     */
-    connectExternal: () => Promise<void>;
-    /** Disconnects the external wallet. Resolves when it is gone. */
-    disconnectExternal: () => Promise<void>;
-};
-
-/**
- * Step 3 of the Superstate checkout: what the swap comes to, the slippage it
- * will tolerate, and placing it.
- *
- * `loading` is its own arm rather than a flag inside `active`, so the skeleton
- * renders from a state that carries no figures at all — there is nothing for
- * the viewmodel to invent while a quote for the confirmed amount is in flight.
- * The quote is repriced on a poll, and the amount the user committed to is only
- * quoted once that poll catches up, so this arm is entered again on every
- * amount change rather than only on first load.
- *
- * `error` is where a quote that cannot be honoured lands: no quote at all, or
- * one asking for more than the user offered.
- */
-type SuperstateReviewUiState = {
-    type: 'incomplete';
-}
-/** No quote yet for the confirmed amount; nothing to show. */
- | {
-    type: 'loading';
-}
-/** No quote could be produced, or the one produced cannot be honoured. */
- | {
-    type: 'error';
-} | {
-    type: 'active';
-    /** What the user is buying. */
-    outputAsset: CheckoutAssetUi;
-    /** The quantity the quote offers, e.g. `981.2431 USTB`. */
-    outputAmount: FormattedAmountAssetUi;
-    /**
-     * The least the user can end up with once slippage is applied — what
-     * `minOut` is set to on-chain, so the swap reverts rather than filling
-     * below it.
-     */
-    minOutputAmount: FormattedAmountAssetUi;
-    /** Where the asset lands — the wallet authorized in step 1. */
-    recipientAddress: ShortenedWalletAddress;
-    /** Price of one whole output token, e.g. `$10.19`. */
-    pricePerShare: FormattedAmountAssetUi;
-    /** The protocol fee the quote carries, in the input asset. */
-    coinlistFee: FormattedAmountAssetUi;
-    /** Input plus fee: what leaves the wallet, e.g. `$1,000.00`. */
-    total: FormattedAmountAssetUi;
-    slippage: SuperstateSlippageUi;
-    placeOrderCta: CheckoutCtaUi;
-    /** A failure from placing the order, distinct from a quote problem. */
-    error: string | null;
-};
-/**
- * The slippage tolerance, and the picker that changes it.
- *
- * `expanded` lives here rather than in the View because the tolerance and the
- * disclosure that sets it are one control: the button's label is the current
- * percent, and the description below explains what that percent does. Splitting
- * them would make the View re-derive copy the viewmodel already formatted.
- */
-type SuperstateSlippageUi = {
-    /** The tolerance in force, e.g. `0.5%`. */
-    percent: FormattedPercentUi;
-    expanded: boolean;
-    /** What this tolerance means, already interpolated with `percent`. */
-    description: string;
-    options: SuperstateSlippageOptionUi[];
-};
-type SuperstateSlippageOptionUi = {
-    /**
-     * The value this option sets. Carried rather than the formatted percent so
-     * the event names an exact tolerance rather than a rendering of one.
-     */
-    bps: Bps;
-    percent: FormattedPercentUi;
-    selected: boolean;
-};
-type SuperstateReviewUiEvent = {
-    type: 'ON_SLIPPAGE_CLICK';
-} | {
-    type: 'ON_SLIPPAGE_SELECT';
-    bps: Bps;
-} | {
-    type: 'ON_PLACE_ORDER';
-};
-
-/** What the swap actually filled at, once it has mined. */
-type SuperstateOrderPlaced = {
-    swapTxHash: Hash;
-    wallet: EvmWallet;
-    inputAsset: StablecoinSymbol;
-    /** The input the contract pulled, excluding the fee. */
-    inputAmount: BlockchainAmount;
-    fee: BlockchainAmount;
-    outputAsset: Erc20Asset;
-    /**
-     * How much arrived. Decoded from the `Swapped` event, except on the fallback
-     * path `outputAmountConfirmed` marks.
-     */
-    outputAmount: BlockchainAmount;
-    /**
-     * Whether `outputAmount` came from the receipt rather than from the quote.
+     * Whether `outputAmount` came from the receipt rather than from the quote.
      *
      * `false` means the swap mined but its `Swapped` event would not decode, so
      * the quote's estimate is standing in. A host that shows the number owes the
@@ -1490,8 +1437,13 @@ declare function quoteIsStale({ total, inputAmount, isQuoteRefreshing, }: QuoteA
  * arriving in a catalogue is a thing they have to decide about, not a blank
  * screen their users find first.
  *
- * Nothing here is per-offer. It is per-*integration*, so a host builds it once
- * and passes the same object for every offer it renders.
+ * Almost nothing here is per-offer: it is per-*integration*, so a host builds
+ * it once and passes the same object for every offer it renders. The one
+ * exception is `ondo::swap`'s `side`, which is per-*render* rather than per
+ * offer or per integration - the same Ondo offer is both buyable and sellable -
+ * so a host with a buy page and a sell page rebuilds the object, or closes its
+ * `side` thunk over whatever selects the direction. See
+ * {@link OndoCheckoutConfig}.
  */
 type CheckoutConfig = {
     [K in OfferType]: CheckoutConfigByOfferType[K];
@@ -1534,7 +1486,32 @@ type OndoCheckoutConfig = {
      * recognise would take down a checkout Ondo has no part in; return anything.
      */
     symbol: (offer: OfferDetail) => AssetSymbol;
-    /** Fired once an Ondo swap has mined. The dialog shows either way. */
+    /**
+     * Which way the trade runs: `buy` invests in the asset, `sell` liquidates a
+     * holding of it.
+     *
+     * A thunk rather than a resolver like `symbol` above, because no offer can
+     * answer it: `offer.type` is `ondo::swap` for both directions, since
+     * frontline exposes one Ondo offer type and the side is a property of the
+     * page rather than of the catalogue. A host closes over whatever selects the
+     * direction - a route, a tab - and returns it.
+     *
+     * Still called for every offer, Superstate's and the token sale's included,
+     * because both Ondo viewmodels are called unconditionally; on those its
+     * answer is handed to a viewmodel that is `enabled: false` and never reads
+     * it. Nothing to be total over, so nothing to get wrong.
+     *
+     * Required, with no default. The wire parameter behind it defaults to `buy`
+     * silently, and the day sell ships an unstated direction should be a compile
+     * error rather than a purchase.
+     *
+     * **Read once, at mount.** The Ondo flow holds a committed quote and an
+     * approval granted for one specific token, so a resolver that starts
+     * answering differently mid-flow is ignored rather than obeyed - see the
+     * remount note on {@link CheckoutContainer}.
+     */
+    side: () => OrderBookSide;
+    /** Fired once an Ondo swap has mined, either way. The dialog shows anyway. */
     onOrderConfirmed?: (order: OndoOrderPlaced) => void;
 };
 /**
@@ -1575,7 +1552,10 @@ type RequiredCheckoutConfig = Pick<CheckoutConfig, 'ondo::swap' | 'coinlist::tok
  *
  * ```ts
  * const config = defaultCheckoutConfig({
- *   'ondo::swap': { symbol: (offer) => AssetSymbol(offer.asset.code) },
+ *   'ondo::swap': {
+ *     symbol: (offer) => AssetSymbol(offer.asset.code),
+ *     side: () => 'buy',
+ *   },
  *   'coinlist::token_sale': { render: (offer) => <MyTokenSalePage offer={offer} /> },
  * });
  * ```
@@ -1616,31 +1596,35 @@ interface CheckoutContainerProps {
  * provider's flow.
  *
  * Every provider's viewmodel is called on every render, because React hooks
- * cannot be called conditionally. Only the one matching `offer.type` is
- * `enabled`, so the other providers fetch nothing and run no timers — that
+ * cannot be called conditionally — and both Ondo products, since `side` picks
+ * between them at the same level. Only the one matching `offer.type` and
+ * `side` is `enabled`, so the rest fetch nothing and run no timers — that
  * `enabled` flag is why every checkout viewmodel has one.
  *
  * The `switch` is exhaustive against `OfferType`, and the `default` branch
  * assigns to `const exhaustive: never`, so a new offer type is a compile error
  * here as well as in {@link CheckoutConfig}.
  *
- * ## One mount, one offer, one chain
+ * ## One mount, one offer, one chain, one side
  *
- * `offer` and `chain` are read as fixed for the lifetime of the mount. Each
- * provider's viewmodel owns a step machine — which wallet was authorized, how
- * much is being spent — and that progress is bound to the offer it was made
- * against: a Superstate wallet authorization is allow-listed per offer, and an
- * ERC-20 approval is granted per chain. Changing either prop in place would
- * carry a completed step from one offer onto another, so the container does not
- * try to; a swap could also land mid-execution, between an approval and the
- * broadcast it was granted for, which is worse than not switching at all.
+ * `offer`, `chain` and the Ondo `side` are read as fixed for the lifetime of
+ * the mount. Each provider's viewmodel owns a step machine — which wallet was
+ * authorized, how much is being spent — and that progress is bound to the order
+ * it was made against: a Superstate wallet authorization is allow-listed per
+ * offer, and an ERC-20 approval is granted per chain, for one specific token.
+ * Changing any of the three in place would carry a completed step onto an order
+ * it was never made for — a flipped side most sharply of all, since the
+ * approval covers the coin the *old* direction spent. So the container does not
+ * try to: `side` is resolved once into state and later answers are ignored. A
+ * swap could also land mid-execution, between an approval and the broadcast it
+ * was granted for, which is worse than not switching at all.
  *
- * **To render a different offer or chain, remount rather than reassign** — give
- * the container a `key` that changes with them:
+ * **To render a different offer, chain or side, remount rather than
+ * reassign** — give the container a `key` that changes with them:
  *
  * ```tsx
  * <CheckoutContainer
- *   key={`${offer.id}:${chain}`}
+ *   key={`${offer.id}:${chain}:${side}`}
  *   offer={offer}
  *   chain={chain}
  *   wallets={wallets}
@@ -1651,6 +1635,61 @@ interface CheckoutContainerProps {
  * React then discards the old flow's state along with its component instance,
  * which is exactly the reset that is wanted and the only one that cannot strand
  * an in-flight transaction.
+ *
+ * ### A page per side
+ *
+ * The simplest way to ship both Ondo directions, and the one that needs no
+ * `key` at all: each page hard-codes its own direction, and a mount only ever
+ * sees one of them.
+ *
+ * ```tsx
+ * // The sell page. `side: () => 'buy'` on the buy page, everything else equal.
+ * const config = defaultCheckoutConfig({
+ *   'ondo::swap': { symbol: (o) => AssetSymbol(o.asset.code), side: () => 'sell' },
+ *   'coinlist::token_sale': { render: (o) => <MyTokenSalePage offer={o} /> },
+ * });
+ * ```
+ *
+ * A sell page reached from a position also knows which wallet holds it, so it
+ * usually sets {@link CheckoutWalletSelection.preselected} and opens on the
+ * amount.
+ *
+ * ### A buy/sell toggle on one page
+ *
+ * Also supported, but **React state alone will not switch it**: `side` is
+ * latched at mount, so a re-render with a new answer is ignored by design. Put
+ * the direction in the `key` and the toggle works, because the container
+ * remounts rather than reassigns.
+ *
+ * ```tsx
+ * const [side, setSide] = useState<OrderBookSide>('buy');
+ *
+ * <BuySellTabs value={side} onChange={setSide} />
+ * <CheckoutContainer
+ *   key={`${offer.id}:${chain}:${side}`} // `side` in the key, or the toggle is inert
+ *   offer={offer}
+ *   chain={chain}
+ *   wallets={wallets}
+ *   config={{
+ *     ...config,
+ *     'ondo::swap': { ...config['ondo::swap'], side: () => side },
+ *   }}
+ * />
+ * ```
+ *
+ * Rebuilding the config object on every render costs nothing here: `side` is
+ * called once per mount, so the thunk's identity never matters.
+ *
+ * Two things a host owns rather than the SDK:
+ *
+ * - **The remount clears the flow** — chosen wallet, entered amount, granted
+ *   approval. That is the point, but it is visible, so expect the card to reset
+ *   under a user who flips the tabs half way down it.
+ * - **A swap already in flight is not cancelled by unmounting it.** It still
+ *   mines; the UI just stops following it, and `onOrderConfirmed` never fires
+ *   for it. The container cannot tell a host that one is in flight, so gate the
+ *   toggle where it can reach an executing flow — disable the tabs once the
+ *   user is past the amount step, or confirm before switching.
  */
 declare function CheckoutContainer({ offer, chain, wallets, config, enabled, className, }: CheckoutContainerProps): ReactNode;
 
@@ -1661,7 +1700,7 @@ declare function CheckoutContainer({ offer, chain, wallets, config, enabled, cla
  * `CheckoutCtaUi` — it reports the on-chain phase back as loading copy while
  * the approval is mined.
  */
-type OndoAmountUiState = {
+type OndoBuyAmountUiState = {
     type: 'incomplete';
 } | {
     type: 'active';
@@ -1686,7 +1725,7 @@ type OndoAmountUiState = {
     /** The confirmed amount with its symbol, e.g. `1,000.00 USDC`. */
     amountFormatted: FormattedAmountAssetUi;
 };
-type OndoAmountUiEvent = {
+type OndoBuyAmountUiEvent = {
     type: 'ON_AMOUNT_CHANGE';
     value: string;
 } | {
@@ -1700,9 +1739,9 @@ type OndoAmountUiEvent = {
     type: 'ON_EDIT_AMOUNT';
 };
 
-interface OndoAmountViewProps {
-    state: OndoAmountUiState;
-    onEvent: (event: OndoAmountUiEvent) => void;
+interface OndoBuyAmountViewProps {
+    state: OndoBuyAmountUiState;
+    onEvent: (event: OndoBuyAmountUiEvent) => void;
     className?: string;
 }
 /**
@@ -1712,49 +1751,128 @@ interface OndoAmountViewProps {
  * Self-scoped: renders fully styled on its own, with no `CoinListStyleScope`
  * needed around it.
  */
-declare function OndoAmountView(props: OndoAmountViewProps): ReactNode;
+declare function OndoBuyAmountView(props: OndoBuyAmountViewProps): ReactNode;
 
 /**
- * The reference panel beside the Ondo checkout: which asset is being bought,
- * what it costs, and the facts about it that do not move while the order is
- * filled in.
- *
- * Read-only, so there is no `UiEvent`. Whether the mobile disclosure is open is
- * the View's own business.
+ * Step 3 of the Ondo checkout: what the order comes to, and placing it.
  *
- * A product type rather than a union: the identity half comes from the offer
- * and is known the moment the checkout renders, so there is no state in which
- * the panel has nothing to show. Only the price corner waits on the network,
- * and it carries its own arms.
+ * `loading` is a separate arm from `active` rather than a flag inside it, so
+ * the skeleton renders from a state that carries no order details at all —
+ * there is nothing for the viewmodel to invent while the first quote is in
+ * flight. Once details exist they stay on screen through every later refresh,
+ * and it is `quote` that reports whether they can still be acted on.
  */
-type OndoSidebarUiState = {
-    asset: CheckoutAssetUi;
+type OndoBuyReviewUiState = {
+    type: 'incomplete';
+}
+/** The first quote is in flight; nothing to show yet. */
+ | {
+    type: 'loading';
+}
+/** No quote could be loaded at all. */
+ | {
+    type: 'error';
+} | {
+    type: 'active';
+    /** What the user is buying. */
+    outputAsset: CheckoutAssetUi;
+    /** The quantity, e.g. `2.639 AAPLon`. */
+    outputAmount: FormattedAmountAssetUi;
+    /** Where the asset lands — the wallet confirmed in step 1. */
+    recipientAddress: ShortenedWalletAddress;
+    /** Price of one whole token, e.g. `$378.99`. */
+    pricePerShare: FormattedAmountAssetUi;
     /**
-     * Who issues the asset, e.g. `Ondo Global Markets`.
-     *
-     * `null` hides the row. No frontline endpoint carries an issuer today, so
-     * absence is the normal case rather than an edge one — the same reasoning as
-     * `coinlistFee` on the review step.
+     * `null` while no CoinList fee is disclosed: no Ondo endpoint returns one
+     * and none is applied to the quote (ENG-1680). The row is hidden rather
+     * than showing a placeholder.
      */
-    issuer: string | null;
-    /** The underlying's ticker, e.g. `AAPL` — not the token symbol. `null` hides the row. */
-    tickerSymbol: string | null;
-    /** The underlying's ISIN, e.g. `US0378331005`. `null` hides the row. */
-    isin: string | null;
-    /** What kind of instrument it is, e.g. `Common Stock`. `null` hides the row. */
-    assetType: string | null;
-    /** Display name of the chain the token lives on, e.g. `Ethereum`. */
-    networkName: string;
-    price: OndoSidebarPriceUi;
+    coinlistFee: FormattedAmountAssetUi | null;
+    /** What the user pays in the input asset, e.g. `1,000.00 USDC`. */
+    total: FormattedAmountAssetUi;
+    quote: OndoBuyQuoteStatusUi;
+    placeOrderCta: CheckoutCtaUi;
+    /** A failure from placing the order, distinct from a quote problem. */
+    error: string | null;
 };
 /**
- * The price corner of the panel.
+ * Whether the shown numbers can still be traded on.
  *
- * Its own SUM rather than nullable fields on the state, because price and
- * market status arrive together from the quote and trading-status polls, and
- * they arrive later than everything else on the panel. Keeping them here means
- * a refresh that is in flight, or one that failed, never blanks the asset's
- * identity.
+ * A quote is only good for a few seconds, so this drives the line above the CTA
+ * and whether the CTA can be pressed at all. `refresh-failed` is its own arm
+ * rather than folding into the step's `error`, because the remedy differs: a
+ * failed refresh is fixed by refreshing again, a failed order is not.
+ */
+type OndoBuyQuoteStatusUi = 
+/** Still good. `expiresInLabel` is the countdown copy, already formatted. */
+{
+    type: 'valid';
+    expiresInLabel: string;
+}
+/** A refresh is in flight; the previous numbers are still on screen. */
+ | {
+    type: 'refreshing';
+}
+/** Too old to trade on. The user must refresh before placing the order. */
+ | {
+    type: 'expired';
+}
+/** The refresh failed. `message` says why. */
+ | {
+    type: 'refresh-failed';
+    message: string;
+};
+type OndoBuyReviewUiEvent = {
+    type: 'ON_REFRESH_QUOTE';
+}
+/** Retry from the `error` arm, where there is no quote to refresh. */
+ | {
+    type: 'ON_RETRY';
+} | {
+    type: 'ON_PLACE_ORDER';
+};
+
+/**
+ * The reference panel beside the Ondo checkout: which asset is being bought,
+ * what it costs, and the facts about it that do not move while the order is
+ * filled in.
+ *
+ * Read-only, so there is no `UiEvent`. Whether the mobile disclosure is open is
+ * the View's own business.
+ *
+ * A product type rather than a union: the identity half comes from the offer
+ * and is known the moment the checkout renders, so there is no state in which
+ * the panel has nothing to show. Only the price corner waits on the network,
+ * and it carries its own arms.
+ */
+type OndoSidebarUiState = {
+    asset: CheckoutAssetUi;
+    /**
+     * Who issues the asset, e.g. `Ondo Global Markets`.
+     *
+     * `null` hides the row. No frontline endpoint carries an issuer today, so
+     * absence is the normal case rather than an edge one — the same reasoning as
+     * `coinlistFee` on the review step.
+     */
+    issuer: string | null;
+    /** The underlying's ticker, e.g. `AAPL` — not the token symbol. `null` hides the row. */
+    tickerSymbol: string | null;
+    /** The underlying's ISIN, e.g. `US0378331005`. `null` hides the row. */
+    isin: string | null;
+    /** What kind of instrument it is, e.g. `Common Stock`. `null` hides the row. */
+    assetType: string | null;
+    /** Display name of the chain the token lives on, e.g. `Ethereum`. */
+    networkName: string;
+    price: OndoSidebarPriceUi;
+};
+/**
+ * The price corner of the panel.
+ *
+ * Its own SUM rather than nullable fields on the state, because price and
+ * market status arrive together from the quote and trading-status polls, and
+ * they arrive later than everything else on the panel. Keeping them here means
+ * a refresh that is in flight, or one that failed, never blanks the asset's
+ * identity.
  */
 type OndoSidebarPriceUi = 
 /** No price yet. The corner renders placeholders. */
@@ -1831,8 +1949,8 @@ type OndoWalletSelectUiEvent = {
  */
 type OndoBuyCheckoutUiState = {
     wallet: OndoWalletSelectUiState;
-    amount: OndoAmountUiState;
-    review: OndoReviewUiState;
+    amount: OndoBuyAmountUiState;
+    review: OndoBuyReviewUiState;
     /** The asset panel. Read-only, so it raises no events. */
     sidebar: OndoSidebarUiState;
     orderConfirmed: OndoOrderConfirmedUiState;
@@ -1847,7 +1965,7 @@ type OndoBuyCheckoutUiState = {
  * tags must stay globally unique, which is why the edit events are
  * `ON_EDIT_WALLET` and `ON_EDIT_AMOUNT` rather than a shared `ON_EDIT`.
  */
-type OndoBuyCheckoutUiEvent = OndoWalletSelectUiEvent | OndoAmountUiEvent | OndoReviewUiEvent | OndoOrderConfirmedUiEvent;
+type OndoBuyCheckoutUiEvent = OndoWalletSelectUiEvent | OndoBuyAmountUiEvent | OndoBuyReviewUiEvent | OndoOrderConfirmedUiEvent;
 /**
  * The dialog that closes the Ondo checkout, once the swap is mined.
  *
@@ -1907,7 +2025,7 @@ interface OndoOrderConfirmedProps {
  * Self-scoped: renders fully styled on its own. It bails before the scope while
  * hidden, so a closed dialog leaves nothing in the DOM.
  */
-declare function OndoOrderConfirmed({ state, onEvent, className, }: OndoOrderConfirmedProps): ReactNode;
+declare function OndoBuyOrderConfirmed({ state, onEvent, className, }: OndoOrderConfirmedProps): ReactNode;
 
 interface OndoBuyCheckoutContainerProps {
     /** The offer being bought: names the asset and supplies its logo. */
@@ -1973,9 +2091,9 @@ interface OndoBuyCheckoutViewProps {
  */
 declare function OndoBuyCheckoutView({ state, onEvent, className, }: OndoBuyCheckoutViewProps): ReactNode;
 
-interface OndoReviewViewProps {
-    state: OndoReviewUiState;
-    onEvent: (event: OndoReviewUiEvent) => void;
+interface OndoBuyReviewViewProps {
+    state: OndoBuyReviewUiState;
+    onEvent: (event: OndoBuyReviewUiEvent) => void;
     className?: string;
 }
 /**
@@ -1986,49 +2104,23 @@ interface OndoReviewViewProps {
  * Self-scoped: renders fully styled on its own, with no `CoinListStyleScope`
  * needed around it.
  */
-declare function OndoReviewView(props: OndoReviewViewProps): ReactNode;
-
-interface OndoSidebarViewProps {
-    state: OndoSidebarUiState;
-    className?: string;
-}
-/**
- * The panel beside the Ondo checkout: what is being bought, what one share
- * costs, and the reference facts about the asset.
- *
- * Read-only, so it takes no `onEvent`. Rows the SDK has no source for arrive as
- * `null` and are dropped by `CheckoutDetailList` rather than rendered empty.
- *
- * Self-scoped: renders fully styled on its own, with no `CoinListStyleScope`
- * needed around it.
- */
-declare function OndoSidebarView({ state, className, }: OndoSidebarViewProps): ReactNode;
+declare function OndoBuyReviewView(props: OndoBuyReviewViewProps): ReactNode;
 
-interface OndoWalletSelectViewProps {
-    state: OndoWalletSelectUiState;
-    onEvent: (event: OndoWalletSelectUiEvent) => void;
-    className?: string;
-}
 /**
- * Step 1 of the Ondo checkout. Pure: the wallets arrive already shaped, and
- * every interaction leaves through `onEvent`.
+ * The amount step of the Ondo sell checkout: how much of the asset to sell.
  *
- * Self-scoped: renders fully styled on its own, with no `CoinListStyleScope`
- * needed around it.
- */
-declare function OndoWalletSelectView(props: OndoWalletSelectViewProps): ReactNode;
-
-/**
- * Step 2 of the Superstate checkout: how much to spend, and which asset to
- * spend.
+ * Confirming submits an ERC-20 approval on the *asset*, so the CTA is a
+ * `CheckoutCtaUi` reporting the on-chain phase back as loading copy - the same
+ * shape the buy step's carries, for the same reason.
  *
- * Nothing here touches the chain. Unlike Ondo's amount step, which approves and
- * commits a quote, this one only validates locally and hands the amount up — a
- * Superstate swap approves and executes together on the review step. Hence a
- * plain `confirmEnabled` rather than a `CheckoutCtaUi` with loading copy: there
- * is no phase to report.
+ * It is a separate state machine from the buy step's rather than a shared one
+ * with a flag, because the two screens differ in what the user is choosing.
+ * A buy picks a funding coin from a list and holds a balance per candidate; a
+ * sell has exactly one input, the asset the offer names, and renders its
+ * balance as a statement. Sharing an ADT would have made this difference a
+ * breaking change for both.
  */
-type SuperstateAmountUiState = {
+type OndoSellAmountUiState = {
     type: 'incomplete';
 } | {
     type: 'active';
@@ -2037,275 +2129,286 @@ type SuperstateAmountUiState = {
      * mid-edit, and `'1.'` is a legal thing to be holding.
      */
     amountInput: string;
-    /** The wallet the funds come from, per step 1. */
-    walletAddress: ShortenedWalletAddress;
     /**
-     * Every supported input asset, in display order, whether or not the user
-     * holds any. One entry renders as a plain card, two or more as a picker.
-     */
-    inputAssets: CheckoutSelectableInputAssetUi[];
-    confirmEnabled: boolean;
-    /** Validation copy, e.g. `Amount must be greater than 0.` */
+     * The asset being sold, with the user's holding of it.
+     *
+     * `null` until the sell quote lands. The asset's contract address and
+     * decimals come off that quote - the SDK ships no registry entry for an
+     * Ondo token - so until it does there is no balance to read and nothing
+     * honest to render. The CTA is `disabled` throughout.
+     */
+    balance: OndoSellBalanceUi | null;
+    /** Where the asset is held and where the proceeds land, per the wallet step. */
+    wallet: OndoSellSourceWalletUi;
+    confirmCta: CheckoutCtaUi;
+    /** Validation or approval failure, e.g. `Insufficient TSLAon`. */
     error: string | null;
 } | {
     type: 'complete';
-    inputAsset: CheckoutAssetUi;
-    /**
-     * What the user is spending, as the field asked for it: dollars, e.g.
-     * `$1,000.00`. The Superstate field is dollar-denominated, which is why
-     * this is prefixed rather than suffixed with a symbol.
-     */
+    asset: CheckoutAssetUi;
+    /** The confirmed amount with its symbol, e.g. `1.204 TSLAon`. */
     amountFormatted: FormattedAmountAssetUi;
-    /**
-     * The same figure in the asset actually being paid, e.g. `1,000.00 USDC`.
-     *
-     * Both are shown because the two are only equal while the funding asset
-     * is a dollar stablecoin — the day a non-dollar one is fundable, the
-     * summary would otherwise silently claim it was.
-     */
-    inputAmountFormatted: FormattedAmountAssetUi;
 };
-type SuperstateAmountUiEvent = {
-    type: 'ON_AMOUNT_CHANGE';
+/** The asset being sold and how much of it the wallet holds. */
+type OndoSellBalanceUi = {
+    asset: CheckoutAssetUi;
+    /** The holding, formatted, e.g. `1.204 TSLAon`. */
+    balance: FormattedAmountAssetUi;
+    /** Base units, so `Max` can fill the field without re-parsing the display. */
+    rawBalance: bigint;
+};
+/**
+ * How the balance card names where the asset is held.
+ *
+ * A SUM rather than a formatted string, because the two read differently: a
+ * CoinList wallet is named, an external one is shown by address. The View
+ * composes the `from …` copy from whichever arm it is handed.
+ */
+type OndoSellSourceWalletUi = {
+    type: 'embedded';
+} | {
+    type: 'external';
+    address: ShortenedWalletAddress;
+};
+type OndoSellAmountUiEvent = {
+    type: 'ON_SELL_AMOUNT_CHANGE';
     value: string;
 } | {
-    type: 'ON_MAX_AMOUNT_CLICK';
+    type: 'ON_SELL_MAX_AMOUNT_CLICK';
 } | {
-    type: 'ON_SELECT_PAY_WITH';
-    value: AssetSymbol;
-}
-/**
- * Named for what it does rather than for the step: confirming here previews
- * the order on step 3, it does not place or pay for anything.
- */
- | {
-    type: 'ON_PREVIEW_ORDER';
+    type: 'ON_CONFIRM_SELL_AMOUNT';
 } | {
-    type: 'ON_EDIT_AMOUNT';
+    type: 'ON_EDIT_SELL_AMOUNT';
 };
 
-interface SuperstateAmountViewProps {
-    state: SuperstateAmountUiState;
-    onEvent: (event: SuperstateAmountUiEvent) => void;
+interface OndoSellAmountViewProps {
+    state: OndoSellAmountUiState;
+    onEvent: (event: OndoSellAmountUiEvent) => void;
+    /**
+     * Where this card sits in the flow, which is 2 normally and 1 when the host
+     * preselected a wallet and the step above was skipped.
+     *
+     * A prop rather than a constant because the sell flow has two lengths. The
+     * god View derives it from the one fact that decides it, so the two cards
+     * cannot disagree about how many steps there are.
+     */
+    stepNumber: number;
     className?: string;
 }
 /**
- * Step 2 of the Superstate checkout. Pure: amounts arrive already formatted,
- * and every interaction leaves through `onEvent`.
+ * The amount step of the Ondo sell checkout. Pure: amounts arrive already
+ * formatted, and every interaction leaves through `onEvent`.
  *
- * The field is dollar-denominated, so the `$` goes in `CheckoutAmountInput`'s
- * `prefix` slot — where Ondo puts its asset symbol in `suffix`. Nothing here is
- * submitted: confirming only moves the flow to the review step.
+ * The balance is a statement rather than a choice - a sell has exactly one
+ * input, the asset the offer names - so it renders as a static card where the
+ * buy step renders a picker. `Max` is offered all the same, and means more
+ * here than there: selling a whole position is the common case.
  *
  * Self-scoped: renders fully styled on its own, with no `CoinListStyleScope`
  * needed around it.
  */
-declare function SuperstateAmountView(props: SuperstateAmountViewProps): ReactNode;
+declare function OndoSellAmountView(props: OndoSellAmountViewProps): ReactNode;
 
 /**
- * The reference panel beside the Superstate checkout: which asset is being
- * bought, what a share costs, and the facts about the sale that do not move
- * while the order is filled in.
+ * The review step of the Ondo sell checkout: what the sale comes to, and
+ * placing it.
  *
- * Read-only, so there is no `UiEvent`. Whether the mobile disclosure is open is
- * the View's own business.
- *
- * A product type rather than a union: the identity half comes from the offer
- * and is known the moment the checkout renders, so there is no state in which
- * the panel has nothing to show. Only the price waits on the network, and it
- * carries its own arms.
+ * `loading` is a separate arm from `active` rather than a flag inside it, so
+ * the skeleton renders from a state that carries no order details at all —
+ * there is nothing for the viewmodel to invent while the first quote is in
+ * flight. Once details exist they stay on screen through every later refresh,
+ * and it is `quote` that reports whether they can still be acted on.
  *
- * Different rows from Ondo's panel, which is why the two are not one screen:
- * Superstate has a sale window and a funding menu, and no ticker, ISIN or
- * instrument type.
+ * The rows are the buy step's inverted, not a subset of them: the hero is the
+ * *proceeds* rather than the asset, and there is no total, because a sell has
+ * nothing for the user to pay. Hence a second state machine rather than a
+ * shared one - the day either screen grows a row, it should not be the other
+ * screen's problem.
  */
-type SuperstateSidebarUiState = {
-    asset: CheckoutAssetUi;
-    /** Who issues the asset, e.g. `Superstate`. */
-    issuer: string;
+type OndoSellReviewUiState = {
+    type: 'incomplete';
+}
+/** The first quote is in flight; nothing to show yet. */
+ | {
+    type: 'loading';
+}
+/** No quote could be loaded at all. */
+ | {
+    type: 'error';
+} | {
+    type: 'active';
+    /** What the proceeds arrive in, e.g. USDC. */
+    outputAsset: CheckoutAssetUi;
     /**
-     * Whether the sale is still running, and the copy that says so — a live
-     * countdown, or `Sale ended`.
+     * What the sale is expected to return, and what CoinList takes to get
+     * there. An expectation, not a guarantee.
+     */
+    expected: OndoSellOutcomeUi;
+    /**
+     * What the calldata guarantees, and the cut at that outcome.
      *
-     * A countdown ticking down is a `label` change, not a state change, until the
-     * window actually closes.
+     * Shown rather than hidden, although no Ondo design calls for the row.
+     * On a sell {@link expected} is an expectation and this is the
+     * guarantee - Ondo settles through USDon before converting - so a screen
+     * that showed only the first would present a firm-looking number the
+     * contract may legitimately fill below.
+     */
+    minimum: OndoSellOutcomeUi;
+    /** Where the proceeds land, the wallet that holds the asset. */
+    recipientAddress: ShortenedWalletAddress;
+    /**
+     * Price of one whole token, e.g. `$378.99`.
+     *
+     * Struck against {@link expected} alone: pricing the floor would answer
+     * "the worst price this could fill at", which no screen asks for. Flat
+     * rather than per-outcome for that reason, and the row discloses that it
+     * is what the order is expected to fill at.
      */
-    sale: CheckoutStatusUi;
-    /** Display name of the chain the token lives on, e.g. `Ethereum`. */
-    networkName: string;
-    /** What the sale can be funded with, e.g. `USDC`. */
-    purchaseOptionsLabel: string;
-    /** The offer's minimum, e.g. `$100.00`. `-` when it publishes none. */
-    minPurchase: FormattedAmountAssetUi;
-    price: SuperstateSidebarPriceUi;
+    pricePerShare: FormattedAmountAssetUi;
+    quote: OndoSellQuoteStatusUi;
+    placeOrderCta: CheckoutCtaUi;
+    /** A failure from placing the order, distinct from a quote problem. */
+    error: string | null;
 };
 /**
- * The price corner of the panel.
+ * One end of the range a sale commits to, ready to render: what arrives, and
+ * what CoinList took to get it there.
  *
- * Its own SUM rather than nullable fields on the state, because the price is
- * derived from the swap quote and the output token, and both arrive later than
- * everything else on the panel. Keeping them here means a poll in flight never
- * blanks the asset's identity or the sale window.
+ * Paired for the same reason `OndoSellOutcome` is, one layer down. A flat
+ * `{ outputAmount, minimumOutputAmount, coinlistFee }` leaves the crossing -
+ * the expected quantity beside the floor's fee - reachable at every call site,
+ * and a review screen renders the two as adjacent rows, so the layer that
+ * flattens them is the layer that shows a seller the wrong disclosure. Keeping
+ * the pair together makes it unsayable here as well.
+ *
+ * Both halves are in the *proceeds*' decimals, unlike a buy's, because a sell
+ * takes its fee from the token it prices in.
  */
-type SuperstateSidebarPriceUi = 
-/** No quote or output token yet. The corner renders placeholders. */
-{
-    type: 'loading';
-} | {
-    type: 'known';
-    /** Price of one whole token, e.g. `$10.19`. */
-    price: FormattedAmountAssetUi;
+type OndoSellOutcomeUi = {
+    /** What the wallet receives at this outcome, net of {@link fee}. */
+    amount: FormattedAmountAssetUi;
+    /**
+     * CoinList's cut at this outcome, e.g. `0.42 USDC`.
+     *
+     * `null` while no fee is disclosed: frontline rejects a non-zero one on
+     * either side today (ENG-1718), and a row reading "0.00 USDC" would imply a
+     * fee exists and happens to round away. Nullable per outcome rather than
+     * once for the pair, so a cut that rounds to zero at one outcome and not the
+     * other still renders honestly.
+     */
+    fee: FormattedAmountAssetUi | null;
 };
-
 /**
- * Step 1 of the Superstate checkout: which wallet funds the swap and receives
- * the asset.
- *
- * There is no `incomplete` arm. This step is the first one, so it is either
- * being filled in or already answered — it is never waiting on a step above it.
- *
- * Confirming here is not a local decision the way Ondo's is: the wallet has to
- * prove ownership and be allow-listed on the swap contract before it may trade,
- * which is a signature and possibly a transaction. That is why the CTA is a
- * {@link CheckoutCtaUi} carrying the phase as loading copy, and why `error` can
- * hold an allow-listing failure as well as a failed connect.
+ * Whether the shown numbers can still be traded on.
  *
- * The allow-listing is invisible in the copy — the step still reads "Choose
- * your wallet" — because from the user's side it is the cost of choosing, not a
- * separate decision. `allowlisted` on the completed arm is the only trace of it.
- */
-type SuperstateWalletUiState = {
-    type: 'active';
-    /** The user's CoinList wallets. Empty when they have none. */
-    embeddedWallets: CheckoutEmbeddedWalletUi[];
-    /** `null` until an external wallet is connected. The row still renders. */
-    externalWallet: CheckoutWalletUi | null;
-    /** Whether the connected external wallet may be disconnected here. */
-    canDisconnect: boolean;
-    /**
-     * Confirming runs the authorization, so this reports its phase as
-     * loading copy — `Sign the message in your wallet…` and the rest.
-     */
-    confirmCta: CheckoutCtaUi;
-    /** A failed connect, or a failed step of the authorization. */
-    error: string | null;
-} | {
-    type: 'completed';
-    wallet: CheckoutConfirmedWalletUi;
+ * A quote is only good for a few seconds, so this drives the line above the CTA
+ * and whether the CTA can be pressed at all. `refresh-failed` is its own arm
+ * rather than folding into the step's `error`, because the remedy differs: a
+ * failed refresh is fixed by refreshing again, a failed order is not.
+ */
+type OndoSellQuoteStatusUi = 
+/** Still good. `expiresInLabel` is the countdown copy, already formatted. */
+{
+    type: 'valid';
+    expiresInLabel: string;
+}
+/** A refresh is in flight; the previous numbers are still on screen. */
+ | {
+    type: 'refreshing';
+}
+/** Too old to trade on. The user must refresh before placing the order. */
+ | {
+    type: 'expired';
+}
+/** The refresh failed. `message` says why. */
+ | {
+    type: 'refresh-failed';
+    message: string;
 };
-type SuperstateWalletUiEvent = {
-    type: 'ON_SELECT_WALLET';
-    value: CheckoutWalletTypeUi;
+type OndoSellReviewUiEvent = {
+    type: 'ON_REFRESH_SELL_QUOTE';
 }
-/**
- * Tapping the external row while nothing is connected. Split from
- * `ON_SELECT_WALLET` because it opens the host's wallet connector rather than
- * changing the selection.
- */
+/** Retry from the `error` arm, where there is no quote to refresh. */
  | {
-    type: 'ON_CONNECT_WALLET';
+    type: 'ON_SELL_RETRY';
 } | {
-    type: 'ON_DISCONNECT_WALLET';
-} | {
-    type: 'ON_CONFIRM_WALLET';
-} | {
-    type: 'ON_EDIT_WALLET';
+    type: 'ON_PLACE_SELL_ORDER';
 };
 
 /**
- * The whole Superstate swap checkout.
+ * The whole Ondo sell checkout: the step cards, the reference panel beside
+ * them, and the dialog that closes the flow.
  *
- * A SUM at the top, unlike Ondo's, because a Superstate checkout has one
- * failure it cannot localise to a region: the swap's output token. Without it
- * there is no quote, no price, no minimum received and no asset name, so three
- * of the four regions would have to invent something. `error` says so once and
- * offers the retry.
+ * A product type rather than a union, because every step that exists is always
+ * on screen — a step that is not the current one renders collapsed, not absent.
+ * Which one is live is carried by the steps themselves, and whether the flow is
+ * finished by `orderConfirmed`.
  */
-type SuperstateSwapCheckoutUiState = {
-    type: 'content';
-    wallet: SuperstateWalletUiState;
-    amount: SuperstateAmountUiState;
-    review: SuperstateReviewUiState;
-    /** The sale panel. Read-only, so it raises no events. */
-    sidebar: SuperstateSidebarUiState;
-    orderConfirmed: SuperstateOrderConfirmedUiState;
-}
-/** The swap could not be loaded at all. */
- | {
-    type: 'error';
-    reason: SuperstateSwapLoadErrorReason;
+type OndoSellCheckoutUiState = {
+    /**
+     * The wallet step, or `null` when the host preselected a wallet and the flow
+     * skipped it.
+     *
+     * `null` is the whole skip: it is what the View renders nothing for, and the
+     * single fact both remaining step numbers are derived from, so a two-step
+     * flow numbered `1, 2` and a three-step flow numbered `1, 2, 3` cannot
+     * disagree. A boolean beside a non-null state would have let them.
+     */
+    wallet: OndoWalletSelectUiState | null;
+    amount: OndoSellAmountUiState;
+    review: OndoSellReviewUiState;
+    /** The asset panel. Read-only, so it raises no events. */
+    sidebar: OndoSidebarUiState;
+    orderConfirmed: OndoSellOrderConfirmedUiState;
 };
-/**
- * Why the whole flow failed to load.
- *
- * The two differ in whether retrying can help, which is the only thing the View
- * does with this: a read that failed is worth another go, a chain with no
- * contract deployed on it is not, and offering a button that provably cannot
- * help is worse than offering none.
- */
-type SuperstateSwapLoadErrorReason = 
-/** The swap's output token would not read. Retrying may work. */
-'load-failed'
-/** No Superstate swap contract is deployed on this chain. Retrying cannot. */
- | 'unsupported-chain';
 /**
  * Every event any step can raise, flattened into one union.
  *
  * Flat rather than wrapped (`{ step, event }`) so that a single
- * `onEvent: (e: SuperstateSwapCheckoutUiEvent) => void` is assignable to each
- * step's narrower handler prop and can be passed straight down — no wrapping
- * lambdas in the View, no nested `switch` in the viewmodel. The cost is that
- * step event tags must stay globally unique within this union, which is why the
- * edit events are `ON_EDIT_WALLET` and `ON_EDIT_AMOUNT` rather than a shared
- * `ON_EDIT`.
- */
-type SuperstateSwapCheckoutUiEvent = SuperstateWalletUiEvent | SuperstateAmountUiEvent | SuperstateReviewUiEvent | SuperstateOrderConfirmedUiEvent | SuperstateSwapCheckoutRetryUiEvent;
-/**
- * Retrying the load behind the flow-level `error` arm.
- *
- * The SDK does not own the page it is mounted in, so this re-runs the fetch
- * rather than reloading the document the way the host app it was ported from
- * did.
+ * `onEvent: (e: OndoSellCheckoutUiEvent) => void` is assignable to each step's
+ * narrower handler prop and can be passed straight down — no wrapping lambdas
+ * in the View, no nested `switch` in the viewmodel. The cost is that step event
+ * tags must stay globally unique, which is why the sell steps' tags carry
+ * `SELL` where the buy steps' do not: the two products' step viewmodels are
+ * separate, and a shared tag would make one product's event dispatch into the
+ * other's handler in any host that composed both.
  */
-type SuperstateSwapCheckoutRetryUiEvent = {
-    type: 'ON_RETRY_LOAD';
-};
+type OndoSellCheckoutUiEvent = OndoWalletSelectUiEvent | OndoSellAmountUiEvent | OndoSellReviewUiEvent | OndoSellOrderConfirmedUiEvent;
 /**
- * The dialog that closes the Superstate checkout, once the swap is mined.
+ * The dialog that closes the Ondo sell checkout, once the swap is mined.
  *
  * A SUM rather than a nullable model, so a dialog on screen with no order
  * behind it is unrepresentable. Every figure is already formatted: the dialog
  * reports what happened and has nothing left to compute.
  */
-type SuperstateOrderConfirmedUiState = {
+type OndoSellOrderConfirmedUiState = {
     type: 'hidden';
 } | {
     type: 'visible';
-    /** What was bought. */
-    asset: CheckoutAssetUi;
-    /** Who issues it, e.g. `Superstate`. */
-    issuer: string;
-    /** How much of it arrived, e.g. `981.2431 USTB`. */
-    outputAmount: FormattedAmountAssetUi;
     /**
-     * Whether `outputAmount` and `pricePerShare` are what the chain reported,
-     * rather than what the quote predicted.
+     * What was sold.
      *
-     * `false` only on the fallback path: the swap mined, but its `Swapped`
-     * event would not decode and the quote's estimate is standing in. The
-     * dialog labels those two rows as estimates when it is, because a figure
-     * captioned `Shares received` is a claim about what is in the user's
-     * wallet and the fallback cannot support it.
+     * Named for the direction, not just for being an asset: `proceeds` below
+     * is denominated in the settlement coin, so the two sit side by side in
+     * this type.
      */
-    outputAmountConfirmed: boolean;
-    /** What the user paid, input plus fee, e.g. `$1,000.00`. */
-    totalCost: FormattedAmountAssetUi;
+    soldAsset: CheckoutAssetUi;
+    /** How much of it went, e.g. `1.204 TSLAon`. */
+    soldAmount: FormattedAmountAssetUi;
+    /** What arrived, in the settlement coin, e.g. `378.99 USDC`. */
+    proceeds: FormattedAmountAssetUi;
     /**
-     * Price of one whole token at the fill, e.g. `$10.19`. Derived from
-     * `outputAmount`, so `outputAmountConfirmed` covers it too.
+     * The settlement coin's symbol on its own, e.g. `USDC`.
+     *
+     * Carried rather than parsed back out of {@link proceeds}: the dialog's
+     * whole contract is that it has nothing left to compute, and a subtitle
+     * that took the last word of a formatted amount would break on the first
+     * locale that puts the unit first.
      */
+    proceedsSymbol: AssetSymbol;
+    /** Price of one whole token at the time of the fill, e.g. `$378.99`. */
     pricePerShare: FormattedAmountAssetUi;
-    /** The wallet the asset was delivered to. */
+    /** The wallet the proceeds were delivered to. */
     recipientAddress: ShortenedWalletAddress;
     /**
      * The settled swap on a block explorer. Always present: the dialog only
@@ -2320,18 +2423,18 @@ type SuperstateOrderConfirmedUiState = {
  * `txExplorerUrl`, not an event: the URL is already built, and an anchor keeps
  * middle-click, copy-link and the browser's own handling working.
  */
-type SuperstateOrderConfirmedUiEvent = {
-    type: 'ON_CLOSE_ORDER_CONFIRMED';
+type OndoSellOrderConfirmedUiEvent = {
+    type: 'ON_CLOSE_SELL_ORDER_CONFIRMED';
 };
 
-interface SuperstateOrderConfirmedProps {
-    state: SuperstateOrderConfirmedUiState;
-    onEvent: (event: SuperstateOrderConfirmedUiEvent) => void;
+interface OndoSellOrderConfirmedProps {
+    state: OndoSellOrderConfirmedUiState;
+    onEvent: (event: OndoSellOrderConfirmedUiEvent) => void;
     className?: string;
 }
 /**
- * The dialog that closes the Superstate checkout: what arrived, what it cost,
- * and where it went.
+ * The dialog that closes the Ondo sell checkout: what went, what came back,
+ * and where it landed.
  *
  * Pure: every figure is handed over formatted, and the explorer link is
  * rendered from the URL the viewmodel built rather than raised as an event.
@@ -2339,78 +2442,34 @@ interface SuperstateOrderConfirmedProps {
  * Self-scoped: renders fully styled on its own. It bails before the scope while
  * hidden, so a closed dialog leaves nothing in the DOM.
  */
-declare function SuperstateOrderConfirmed({ state, onEvent, className, }: SuperstateOrderConfirmedProps): ReactNode;
+declare function OndoSellOrderConfirmed({ state, onEvent, className, }: OndoSellOrderConfirmedProps): ReactNode;
 
-interface SlippagePickerProps {
-    slippage: SuperstateSlippageUi;
+interface OndoSellCheckoutContainerProps {
+    /** The offer being sold: names the asset and supplies its logo. */
+    offer: OfferDetail;
     /**
-     * What the tolerance applies to, rendered to the left of the toggle: the
-     * amount the user receives, in practice.
+     * Ondo's API symbol for the asset, e.g. `TSLAon`.
      *
-     * A slot, and the reason this component owns a row at all. The toggle has to
-     * sit beside the summary while the options have to span the full width
-     * beneath both - a picker that rendered only itself would put the options in
-     * whatever narrow column the toggle landed in. Taking the summary is what
-     * lets one component place both, and keeps `aria-controls` pointing at a
-     * panel it still owns.
+     * Explicit rather than derived from the offer: Ondo's symbol tracks the
+     * underlying ticker and changes on a rebrand, and on Sepolia the two already
+     * disagree, where a mock asset stands in.
      */
-    summary: ReactNode;
-    /** Toggles the disclosure. Open/closed is viewmodel state, not View state. */
-    onToggle: () => void;
-    onSelect: (bps: Bps) => void;
-    className?: string;
-}
-/**
- * The slippage tolerance, and the disclosure that changes it: a pill showing
- * the tolerance in force beside {@link SlippagePickerProps.summary}, and - once
- * opened - the options and what they mean, on their own line below both.
- *
- * Superstate-only, so it lives beside the review step rather than in
- * `checkout/shared`. Ondo quotes firm prices and has no tolerance to set, and a
- * shared component shaped entirely by one provider's `SLIPPAGE_OPTIONS_BPS`
- * would be that provider's component in a shared directory.
- *
- * Pure: it renders the options it is handed and reports which was picked. It
- * does not know what a basis point is.
- *
- * Self-scoped: renders fully styled on its own, with no `CoinListStyleScope`
- * needed around it.
- */
-declare function SlippagePicker({ slippage, summary, onToggle, onSelect, className, }: SlippagePickerProps): ReactNode;
-
-interface SuperstateReviewViewProps {
-    state: SuperstateReviewUiState;
-    onEvent: (event: SuperstateReviewUiEvent) => void;
-    className?: string;
-}
-/**
- * Step 3 of the Superstate checkout. Pure: every number arrives formatted, and
- * whether the order can be placed is decided by `placeOrderCta` rather than
- * re-derived here.
- *
- * The CTA covers a status check, an approval and the swap, which is why the
- * "don't close this page" notice appears only while it runs — a Superstate
- * order is several wallet prompts long, and leaving mid-flight strands the
- * approval.
- *
- * Self-scoped: renders fully styled on its own, with no `CoinListStyleScope`
- * needed around it.
- */
-declare function SuperstateReviewView(props: SuperstateReviewViewProps): ReactNode;
-
-interface SuperstateSwapCheckoutContainerProps {
-    /** The offer being bought: names the asset, the window and the minimum. */
-    offer: OfferDetail;
+    ondoSymbol: AssetSymbol;
     /**
-     * The chain the order executes on: the balance reads, the approval and the
-     * swap. The swap contract is looked up from it, so a chain with none
-     * deployed renders the flow's error state rather than a broken checkout.
+     * The chain the order executes on: the balance read, the approval and the
+     * broadcast. Ondo prices against production whatever this says, since it
+     * runs no sandbox.
      */
     chain: EthereumChain;
     /**
-     * The wallets the buyer can spend from, and the lambdas that connect and
-     * disconnect an external one. The SDK ships no wallet stack, so this is how
-     * a host plugs in Privy, AppKit, or its own.
+     * The wallets the seller can sell from, the lambdas that connect and
+     * disconnect an external one, and optionally the one the host has already
+     * settled on.
+     *
+     * Setting `wallets.preselected` skips the wallet step and opens the flow on
+     * the amount, with the two remaining cards renumbered. It is read once, at
+     * mount: the approval that follows the amount step is granted by one
+     * specific wallet.
      */
     wallets: CheckoutWalletSelection;
     /**
@@ -2419,30 +2478,33 @@ interface SuperstateSwapCheckoutContainerProps {
      */
     enabled?: boolean;
     /** Fired once the swap has mined. The dialog shows either way. */
-    onOrderConfirmed?: (order: SuperstateOrderPlaced) => void;
+    onOrderConfirmed?: (order: OndoOrderPlaced) => void;
     className?: string;
 }
 /**
- * The Superstate swap checkout, ready to drop in: three steps, the sale panel
- * beside them, and the dialog that closes the flow.
- *
- * Takes no contract address: it is looked up from `chain`, the way Ondo's is.
- * A partner who needs to point at a different deployment is below this rung and
- * calls `coinlist.superstate.execute` directly.
+ * The Ondo sell checkout, ready to drop in: the steps, the asset panel beside
+ * them, and the dialog that closes the flow.
  *
  * Self-scoped: renders fully styled on its own, with no `CoinListStyleScope`
  * needed around it.
  */
-declare function SuperstateSwapCheckoutContainer({ offer, chain, wallets, enabled, onOrderConfirmed, className, }: SuperstateSwapCheckoutContainerProps): ReactNode;
+declare function OndoSellCheckoutContainer({ offer, ondoSymbol, chain, wallets, enabled, onOrderConfirmed, className, }: OndoSellCheckoutContainerProps): ReactNode;
 
-interface SuperstateSwapCheckoutViewProps {
-    state: SuperstateSwapCheckoutUiState;
-    onEvent: (event: SuperstateSwapCheckoutUiEvent) => void;
+interface OndoSellCheckoutViewProps {
+    state: OndoSellCheckoutUiState;
+    onEvent: (event: OndoSellCheckoutUiEvent) => void;
     className?: string;
 }
 /**
- * The whole Superstate swap checkout: the three step cards, the sale panel
- * beside them, and the dialog that closes the flow.
+ * The whole Ondo sell checkout: the step cards, the asset panel beside them,
+ * and the dialog that closes the flow.
+ *
+ * **Two or three cards, depending on `state.wallet`.** A host that already
+ * knows which wallet holds the position preselects it, and the flow opens on
+ * the amount. That one nullable field is where both remaining step numbers
+ * come from, so a two-step flow reading `1, 2` and a three-step flow reading
+ * `1, 2, 3` cannot disagree - a second source for "is there a wallet step"
+ * would be the way they could.
  *
  * `onEvent` is handed to each step unwrapped. A handler that accepts the wider
  * union is assignable where a step's narrower one is expected, so there is no
@@ -2450,97 +2512,601 @@ interface SuperstateSwapCheckoutViewProps {
  *
  * The panel leads on a phone and moves to the right column from `md` up, where
  * it is reference material rather than the first thing to read. No page heading
- * and no back button — the host titles and navigates its own page.
+ * is rendered — the host titles its own page.
  *
  * Self-scoped: renders fully styled on its own, with no `CoinListStyleScope`
  * needed around it. The steps scope themselves too, and the scope is
  * idempotent, so nesting costs nothing.
  */
-declare function SuperstateSwapCheckoutView({ state, onEvent, className, }: SuperstateSwapCheckoutViewProps): ReactNode;
+declare function OndoSellCheckoutView({ state, onEvent, className, }: OndoSellCheckoutViewProps): ReactNode;
 
-interface SuperstateSidebarViewProps {
-    state: SuperstateSidebarUiState;
+interface OndoSellReviewViewProps {
+    state: OndoSellReviewUiState;
+    onEvent: (event: OndoSellReviewUiEvent) => void;
+    /** Where this card sits in the flow: 3 normally, 2 when the wallet step was skipped. */
+    stepNumber: number;
     className?: string;
 }
 /**
- * The panel beside the Superstate checkout: whether the sale is still running,
- * what is being bought, what one share costs, and the terms of the sale.
+ * The review step of the Ondo sell checkout. Pure: every number arrives
+ * formatted, and whether the order can be placed is decided by
+ * `placeOrderCta` rather than re-derived here from the quote's status.
  *
- * Read-only, so it takes no `onEvent`. The sale banner sits above the card
- * rather than inside it — it is the first thing to read on a phone, where the
- * card's own contents fold away behind a disclosure.
+ * It carries no total. A sell has nothing for the user to pay - the proceeds
+ * are the headline, and the fee comes out of them - so the buy step's
+ * gross/fee/total ladder has no counterpart here. What it carries instead is
+ * the floor: the proceeds above are what Ondo expects to deliver, and only the
+ * minimum is what the calldata enforces.
  *
  * Self-scoped: renders fully styled on its own, with no `CoinListStyleScope`
  * needed around it.
  */
-declare function SuperstateSidebarView({ state, className, }: SuperstateSidebarViewProps): ReactNode;
+declare function OndoSellReviewView(props: OndoSellReviewViewProps): ReactNode;
 
-interface SuperstateWalletViewProps {
-    state: SuperstateWalletUiState;
-    onEvent: (event: SuperstateWalletUiEvent) => void;
+interface OndoSidebarViewProps {
+    state: OndoSidebarUiState;
     className?: string;
 }
 /**
- * Step 1 of the Superstate checkout. Pure: the wallets arrive already shaped,
- * and every interaction leaves through `onEvent`.
+ * The panel beside the Ondo checkout: what is being bought, what one share
+ * costs, and the reference facts about the asset.
  *
- * Confirming allow-lists the wallet on-chain, which is why the CTA renders a
- * loading message rather than a spinner alone — the copy is what tells the user
- * their wallet is about to ask them to sign. The completed step says
- * `Allowlisted`, the only place the flow admits that anything happened.
+ * Read-only, so it takes no `onEvent`. Rows the SDK has no source for arrive as
+ * `null` and are dropped by `CheckoutDetailList` rather than rendered empty.
  *
  * Self-scoped: renders fully styled on its own, with no `CoinListStyleScope`
  * needed around it.
  */
-declare function SuperstateWalletView(props: SuperstateWalletViewProps): ReactNode;
+declare function OndoSidebarView({ state, className, }: OndoSidebarViewProps): ReactNode;
 
-type OffersGridUiState = {
+interface OndoWalletSelectViewProps {
+    state: OndoWalletSelectUiState;
+    onEvent: (event: OndoWalletSelectUiEvent) => void;
+    /**
+     * The line under the heading. Defaults to the buy copy.
+     *
+     * A plain string rather than a slot: every Ondo product renders one sentence
+     * here in the same style, and the only thing that varies is what the wallet
+     * is for.
+     */
+    description?: string;
+    className?: string;
+}
+/**
+ * The wallet step of an Ondo checkout: which wallet the order runs through.
+ * Pure - the wallets arrive already shaped, and every interaction leaves
+ * through `onEvent`.
+ *
+ * Shared by both Ondo products, because nothing about choosing a wallet
+ * differs between them: an Ondo wallet is not allow-listed either way, so the
+ * decision is local and synchronous on both. Only the sentence under the
+ * heading changes, and that is a prop.
+ *
+ * It is always step 1 where it renders at all. A sell that skips it does not
+ * render this component, rather than rendering it with another number.
+ *
+ * Self-scoped: renders fully styled on its own, with no `CoinListStyleScope`
+ * needed around it.
+ */
+declare function OndoWalletSelectView(props: OndoWalletSelectViewProps): ReactNode;
+
+/**
+ * Step 2 of the Superstate checkout: how much to spend, and which asset to
+ * spend.
+ *
+ * Nothing here touches the chain. Unlike Ondo's amount step, which approves and
+ * commits a quote, this one only validates locally and hands the amount up — a
+ * Superstate swap approves and executes together on the review step. Hence a
+ * plain `confirmEnabled` rather than a `CheckoutCtaUi` with loading copy: there
+ * is no phase to report.
+ */
+type SuperstateAmountUiState = {
+    type: 'incomplete';
+} | {
+    type: 'active';
+    /**
+     * Exactly what the user has typed, not a parsed number: the field is
+     * mid-edit, and `'1.'` is a legal thing to be holding.
+     */
+    amountInput: string;
+    /** The wallet the funds come from, per step 1. */
+    walletAddress: ShortenedWalletAddress;
+    /**
+     * Every supported input asset, in display order, whether or not the user
+     * holds any. One entry renders as a plain card, two or more as a picker.
+     */
+    inputAssets: CheckoutSelectableInputAssetUi[];
+    confirmEnabled: boolean;
+    /** Validation copy, e.g. `Amount must be greater than 0.` */
+    error: string | null;
+} | {
+    type: 'complete';
+    inputAsset: CheckoutAssetUi;
+    /**
+     * What the user is spending, as the field asked for it: dollars, e.g.
+     * `$1,000.00`. The Superstate field is dollar-denominated, which is why
+     * this is prefixed rather than suffixed with a symbol.
+     */
+    amountFormatted: FormattedAmountAssetUi;
+    /**
+     * The same figure in the asset actually being paid, e.g. `1,000.00 USDC`.
+     *
+     * Both are shown because the two are only equal while the funding asset
+     * is a dollar stablecoin — the day a non-dollar one is fundable, the
+     * summary would otherwise silently claim it was.
+     */
+    inputAmountFormatted: FormattedAmountAssetUi;
+};
+type SuperstateAmountUiEvent = {
+    type: 'ON_AMOUNT_CHANGE';
+    value: string;
+} | {
+    type: 'ON_MAX_AMOUNT_CLICK';
+} | {
+    type: 'ON_SELECT_PAY_WITH';
+    value: AssetSymbol;
+}
+/**
+ * Named for what it does rather than for the step: confirming here previews
+ * the order on step 3, it does not place or pay for anything.
+ */
+ | {
+    type: 'ON_PREVIEW_ORDER';
+} | {
+    type: 'ON_EDIT_AMOUNT';
+};
+
+interface SuperstateAmountViewProps {
+    state: SuperstateAmountUiState;
+    onEvent: (event: SuperstateAmountUiEvent) => void;
+    className?: string;
+}
+/**
+ * Step 2 of the Superstate checkout. Pure: amounts arrive already formatted,
+ * and every interaction leaves through `onEvent`.
+ *
+ * The field is dollar-denominated, so the `$` goes in `CheckoutAmountInput`'s
+ * `prefix` slot — where Ondo puts the symbol of the token it charges. Nothing
+ * here is submitted: confirming only moves the flow to the review step.
+ *
+ * Self-scoped: renders fully styled on its own, with no `CoinListStyleScope`
+ * needed around it.
+ */
+declare function SuperstateAmountView(props: SuperstateAmountViewProps): ReactNode;
+
+/**
+ * The reference panel beside the Superstate checkout: which asset is being
+ * bought, what a share costs, and the facts about the sale that do not move
+ * while the order is filled in.
+ *
+ * Read-only, so there is no `UiEvent`. Whether the mobile disclosure is open is
+ * the View's own business.
+ *
+ * A product type rather than a union: the identity half comes from the offer
+ * and is known the moment the checkout renders, so there is no state in which
+ * the panel has nothing to show. Only the price waits on the network, and it
+ * carries its own arms.
+ *
+ * Different rows from Ondo's panel, which is why the two are not one screen:
+ * Superstate has a sale window and a funding menu, and no ticker, ISIN or
+ * instrument type.
+ */
+type SuperstateSidebarUiState = {
+    asset: CheckoutAssetUi;
+    /** Who issues the asset, e.g. `Superstate`. */
+    issuer: string;
+    /**
+     * Whether the sale is still running, and the copy that says so — a live
+     * countdown, or `Sale ended`.
+     *
+     * A countdown ticking down is a `label` change, not a state change, until the
+     * window actually closes.
+     */
+    sale: CheckoutStatusUi;
+    /** Display name of the chain the token lives on, e.g. `Ethereum`. */
+    networkName: string;
+    /** What the sale can be funded with, e.g. `USDC`. */
+    purchaseOptionsLabel: string;
+    /** The offer's minimum, e.g. `$100.00`. `-` when it publishes none. */
+    minPurchase: FormattedAmountAssetUi;
+    price: SuperstateSidebarPriceUi;
+};
+/**
+ * The price corner of the panel.
+ *
+ * Its own SUM rather than nullable fields on the state, because the price is
+ * derived from the swap quote and the output token, and both arrive later than
+ * everything else on the panel. Keeping them here means a poll in flight never
+ * blanks the asset's identity or the sale window.
+ */
+type SuperstateSidebarPriceUi = 
+/** No quote or output token yet. The corner renders placeholders. */
+{
     type: 'loading';
 } | {
-    type: 'error';
-    message: string;
+    type: 'known';
+    /** Price of one whole token, e.g. `$10.19`. */
+    price: FormattedAmountAssetUi;
+};
+
+/**
+ * Step 1 of the Superstate checkout: which wallet funds the swap and receives
+ * the asset.
+ *
+ * There is no `incomplete` arm. This step is the first one, so it is either
+ * being filled in or already answered — it is never waiting on a step above it.
+ *
+ * Confirming here is not a local decision the way Ondo's is: the wallet has to
+ * prove ownership and be allow-listed on the swap contract before it may trade,
+ * which is a signature and possibly a transaction. That is why the CTA is a
+ * {@link CheckoutCtaUi} carrying the phase as loading copy, and why `error` can
+ * hold an allow-listing failure as well as a failed connect.
+ *
+ * The allow-listing is invisible in the copy — the step still reads "Choose
+ * your wallet" — because from the user's side it is the cost of choosing, not a
+ * separate decision. `allowlisted` on the completed arm is the only trace of it.
+ */
+type SuperstateWalletUiState = {
+    type: 'active';
+    /** The user's CoinList wallets. Empty when they have none. */
+    embeddedWallets: CheckoutEmbeddedWalletUi[];
+    /** `null` until an external wallet is connected. The row still renders. */
+    externalWallet: CheckoutWalletUi | null;
+    /** Whether the connected external wallet may be disconnected here. */
+    canDisconnect: boolean;
+    /**
+     * Confirming runs the authorization, so this reports its phase as
+     * loading copy — `Sign the message in your wallet…` and the rest.
+     */
+    confirmCta: CheckoutCtaUi;
+    /** A failed connect, or a failed step of the authorization. */
+    error: string | null;
 } | {
-    type: 'empty';
+    type: 'completed';
+    wallet: CheckoutConfirmedWalletUi;
+};
+type SuperstateWalletUiEvent = {
+    type: 'ON_SELECT_WALLET';
+    value: CheckoutWalletTypeUi;
+}
+/**
+ * Tapping the external row while nothing is connected. Split from
+ * `ON_SELECT_WALLET` because it opens the host's wallet connector rather than
+ * changing the selection.
+ */
+ | {
+    type: 'ON_CONNECT_WALLET';
 } | {
+    type: 'ON_DISCONNECT_WALLET';
+} | {
+    type: 'ON_CONFIRM_WALLET';
+} | {
+    type: 'ON_EDIT_WALLET';
+};
+
+/**
+ * The whole Superstate swap checkout.
+ *
+ * A SUM at the top, unlike Ondo's, because a Superstate checkout has one
+ * failure it cannot localise to a region: the swap's output token. Without it
+ * there is no quote, no price, no minimum received and no asset name, so three
+ * of the four regions would have to invent something. `error` says so once and
+ * offers the retry.
+ */
+type SuperstateSwapCheckoutUiState = {
     type: 'content';
-    offers: OfferCardUi[];
-    /** Cards render as buttons only when the host passed `onOfferClick`. */
-    interactive: boolean;
+    wallet: SuperstateWalletUiState;
+    amount: SuperstateAmountUiState;
+    review: SuperstateReviewUiState;
+    /** The sale panel. Read-only, so it raises no events. */
+    sidebar: SuperstateSidebarUiState;
+    orderConfirmed: SuperstateOrderConfirmedUiState;
+}
+/** The swap could not be loaded at all. */
+ | {
+    type: 'error';
+    reason: SuperstateSwapLoadErrorReason;
 };
-type OffersGridUiEvent = {
-    type: 'ON_OFFER_CLICK';
-    offerId: OfferId;
+/**
+ * Why the whole flow failed to load.
+ *
+ * The two differ in whether retrying can help, which is the only thing the View
+ * does with this: a read that failed is worth another go, a chain with no
+ * contract deployed on it is not, and offering a button that provably cannot
+ * help is worse than offering none.
+ */
+type SuperstateSwapLoadErrorReason = 
+/** The swap's output token would not read. Retrying may work. */
+'load-failed'
+/** No Superstate swap contract is deployed on this chain. Retrying cannot. */
+ | 'unsupported-chain';
+/**
+ * Every event any step can raise, flattened into one union.
+ *
+ * Flat rather than wrapped (`{ step, event }`) so that a single
+ * `onEvent: (e: SuperstateSwapCheckoutUiEvent) => void` is assignable to each
+ * step's narrower handler prop and can be passed straight down — no wrapping
+ * lambdas in the View, no nested `switch` in the viewmodel. The cost is that
+ * step event tags must stay globally unique within this union, which is why the
+ * edit events are `ON_EDIT_WALLET` and `ON_EDIT_AMOUNT` rather than a shared
+ * `ON_EDIT`.
+ */
+type SuperstateSwapCheckoutUiEvent = SuperstateWalletUiEvent | SuperstateAmountUiEvent | SuperstateReviewUiEvent | SuperstateOrderConfirmedUiEvent | SuperstateSwapCheckoutRetryUiEvent;
+/**
+ * Retrying the load behind the flow-level `error` arm.
+ *
+ * The SDK does not own the page it is mounted in, so this re-runs the fetch
+ * rather than reloading the document the way the host app it was ported from
+ * did.
+ */
+type SuperstateSwapCheckoutRetryUiEvent = {
+    type: 'ON_RETRY_LOAD';
+};
+/**
+ * The dialog that closes the Superstate checkout, once the swap is mined.
+ *
+ * A SUM rather than a nullable model, so a dialog on screen with no order
+ * behind it is unrepresentable. Every figure is already formatted: the dialog
+ * reports what happened and has nothing left to compute.
+ */
+type SuperstateOrderConfirmedUiState = {
+    type: 'hidden';
+} | {
+    type: 'visible';
+    /** What was bought. */
+    asset: CheckoutAssetUi;
+    /** Who issues it, e.g. `Superstate`. */
+    issuer: string;
+    /** How much of it arrived, e.g. `981.2431 USTB`. */
+    outputAmount: FormattedAmountAssetUi;
+    /**
+     * Whether `outputAmount` and `pricePerShare` are what the chain reported,
+     * rather than what the quote predicted.
+     *
+     * `false` only on the fallback path: the swap mined, but its `Swapped`
+     * event would not decode and the quote's estimate is standing in. The
+     * dialog labels those two rows as estimates when it is, because a figure
+     * captioned `Shares received` is a claim about what is in the user's
+     * wallet and the fallback cannot support it.
+     */
+    outputAmountConfirmed: boolean;
+    /** What the user paid, input plus fee, e.g. `$1,000.00`. */
+    totalCost: FormattedAmountAssetUi;
+    /**
+     * Price of one whole token at the fill, e.g. `$10.19`. Derived from
+     * `outputAmount`, so `outputAmountConfirmed` covers it too.
+     */
+    pricePerShare: FormattedAmountAssetUi;
+    /** The wallet the asset was delivered to. */
+    recipientAddress: ShortenedWalletAddress;
+    /**
+     * The settled swap on a block explorer. Always present: the dialog only
+     * exists once there is a mined transaction to point at.
+     */
+    txExplorerUrl: TxExplorerUrl;
+};
+/**
+ * Closing is the only thing the dialog raises.
+ *
+ * `View transaction onchain` is a plain link the View renders from
+ * `txExplorerUrl`, not an event: the URL is already built, and an anchor keeps
+ * middle-click, copy-link and the browser's own handling working.
+ */
+type SuperstateOrderConfirmedUiEvent = {
+    type: 'ON_CLOSE_ORDER_CONFIRMED';
 };
+
+interface SuperstateOrderConfirmedProps {
+    state: SuperstateOrderConfirmedUiState;
+    onEvent: (event: SuperstateOrderConfirmedUiEvent) => void;
+    className?: string;
+}
 /**
- * An offer as an offer card renders it: dates already formatted, nothing left
- * to decide at render time.
+ * The dialog that closes the Superstate checkout: what arrived, what it cost,
+ * and where it went.
+ *
+ * Pure: every figure is handed over formatted, and the explorer link is
+ * rendered from the URL the viewmodel built rather than raised as an event.
+ *
+ * Self-scoped: renders fully styled on its own. It bails before the scope while
+ * hidden, so a closed dialog leaves nothing in the DOM.
  */
-type OfferCardUi = {
+declare function SuperstateOrderConfirmed({ state, onEvent, className, }: SuperstateOrderConfirmedProps): ReactNode;
+
+interface SlippagePickerProps {
+    slippage: SuperstateSlippageUi;
+    /**
+     * What the tolerance applies to, rendered to the left of the toggle: the
+     * amount the user receives, in practice.
+     *
+     * A slot, and the reason this component owns a row at all. The toggle has to
+     * sit beside the summary while the options have to span the full width
+     * beneath both - a picker that rendered only itself would put the options in
+     * whatever narrow column the toggle landed in. Taking the summary is what
+     * lets one component place both, and keeps `aria-controls` pointing at a
+     * panel it still owns.
+     */
+    summary: ReactNode;
+    /** Toggles the disclosure. Open/closed is viewmodel state, not View state. */
+    onToggle: () => void;
+    onSelect: (bps: Bps) => void;
+    className?: string;
+}
+/**
+ * The slippage tolerance, and the disclosure that changes it: a pill showing
+ * the tolerance in force beside {@link SlippagePickerProps.summary}, and - once
+ * opened - the options and what they mean, on their own line below both.
+ *
+ * Superstate-only, so it lives beside the review step rather than in
+ * `checkout/shared`. Ondo quotes firm prices and has no tolerance to set, and a
+ * shared component shaped entirely by one provider's `SLIPPAGE_OPTIONS_BPS`
+ * would be that provider's component in a shared directory.
+ *
+ * Pure: it renders the options it is handed and reports which was picked. It
+ * does not know what a basis point is.
+ *
+ * Self-scoped: renders fully styled on its own, with no `CoinListStyleScope`
+ * needed around it.
+ */
+declare function SlippagePicker({ slippage, summary, onToggle, onSelect, className, }: SlippagePickerProps): ReactNode;
+
+interface SuperstateReviewViewProps {
+    state: SuperstateReviewUiState;
+    onEvent: (event: SuperstateReviewUiEvent) => void;
+    className?: string;
+}
+/**
+ * Step 3 of the Superstate checkout. Pure: every number arrives formatted, and
+ * whether the order can be placed is decided by `placeOrderCta` rather than
+ * re-derived here.
+ *
+ * The CTA covers a status check, an approval and the swap, which is why the
+ * "don't close this page" notice appears only while it runs — a Superstate
+ * order is several wallet prompts long, and leaving mid-flight strands the
+ * approval.
+ *
+ * Self-scoped: renders fully styled on its own, with no `CoinListStyleScope`
+ * needed around it.
+ */
+declare function SuperstateReviewView(props: SuperstateReviewViewProps): ReactNode;
+
+interface SuperstateSwapCheckoutContainerProps {
+    /** The offer being bought: names the asset, the window and the minimum. */
+    offer: OfferDetail;
+    /**
+     * The chain the order executes on: the balance reads, the approval and the
+     * swap. The swap contract is looked up from it, so a chain with none
+     * deployed renders the flow's error state rather than a broken checkout.
+     */
+    chain: EthereumChain;
+    /**
+     * The wallets the buyer can spend from, and the lambdas that connect and
+     * disconnect an external one. The SDK ships no wallet stack, so this is how
+     * a host plugs in Privy, AppKit, or its own.
+     */
+    wallets: CheckoutWalletSelection;
+    /**
+     * Default `true`. `false` turns off every request and timer, which is what
+     * `CheckoutContainer` uses to call each provider's checkout unconditionally.
+     */
+    enabled?: boolean;
+    /** Fired once the swap has mined. The dialog shows either way. */
+    onOrderConfirmed?: (order: SuperstateOrderPlaced) => void;
+    className?: string;
+}
+/**
+ * The Superstate swap checkout, ready to drop in: three steps, the sale panel
+ * beside them, and the dialog that closes the flow.
+ *
+ * Takes no contract address: it is looked up from `chain`, the way Ondo's is.
+ * A partner who needs to point at a different deployment is below this rung and
+ * calls `coinlist.superstate.execute` directly.
+ *
+ * Self-scoped: renders fully styled on its own, with no `CoinListStyleScope`
+ * needed around it.
+ */
+declare function SuperstateSwapCheckoutContainer({ offer, chain, wallets, enabled, onOrderConfirmed, className, }: SuperstateSwapCheckoutContainerProps): ReactNode;
+
+interface SuperstateSwapCheckoutViewProps {
+    state: SuperstateSwapCheckoutUiState;
+    onEvent: (event: SuperstateSwapCheckoutUiEvent) => void;
+    className?: string;
+}
+/**
+ * The whole Superstate swap checkout: the three step cards, the sale panel
+ * beside them, and the dialog that closes the flow.
+ *
+ * `onEvent` is handed to each step unwrapped. A handler that accepts the wider
+ * union is assignable where a step's narrower one is expected, so there is no
+ * per-step lambda here and no re-dispatch on the way back up.
+ *
+ * The panel leads on a phone and moves to the right column from `md` up, where
+ * it is reference material rather than the first thing to read. No page heading
+ * and no back button — the host titles and navigates its own page.
+ *
+ * Self-scoped: renders fully styled on its own, with no `CoinListStyleScope`
+ * needed around it. The steps scope themselves too, and the scope is
+ * idempotent, so nesting costs nothing.
+ */
+declare function SuperstateSwapCheckoutView({ state, onEvent, className, }: SuperstateSwapCheckoutViewProps): ReactNode;
+
+interface SuperstateSidebarViewProps {
+    state: SuperstateSidebarUiState;
+    className?: string;
+}
+/**
+ * The panel beside the Superstate checkout: whether the sale is still running,
+ * what is being bought, what one share costs, and the terms of the sale.
+ *
+ * Read-only, so it takes no `onEvent`. The sale banner sits above the card
+ * rather than inside it — it is the first thing to read on a phone, where the
+ * card's own contents fold away behind a disclosure.
+ *
+ * Self-scoped: renders fully styled on its own, with no `CoinListStyleScope`
+ * needed around it.
+ */
+declare function SuperstateSidebarView({ state, className, }: SuperstateSidebarViewProps): ReactNode;
+
+interface SuperstateWalletViewProps {
+    state: SuperstateWalletUiState;
+    onEvent: (event: SuperstateWalletUiEvent) => void;
+    className?: string;
+}
+/**
+ * Step 1 of the Superstate checkout. Pure: the wallets arrive already shaped,
+ * and every interaction leaves through `onEvent`.
+ *
+ * Confirming allow-lists the wallet on-chain, which is why the CTA renders a
+ * loading message rather than a spinner alone — the copy is what tells the user
+ * their wallet is about to ask them to sign. The completed step says
+ * `Allowlisted`, the only place the flow admits that anything happened.
+ *
+ * Self-scoped: renders fully styled on its own, with no `CoinListStyleScope`
+ * needed around it.
+ */
+declare function SuperstateWalletView(props: SuperstateWalletViewProps): ReactNode;
+
+/**
+ * An offer as {@link OfferAssetCard} renders it. Browse chrome: circular
+ * `logoUrl`, company `name`, and asset `symbol` (`asset.code`). No wordmark.
+ * `fromOffer` omits `name` and `symbol` — the list payload has neither — so a
+ * list-mapped card is honest about being logo-only. Prefer
+ * {@link OfferAssetCardUi.fromDetail} when the host has detail.
+ */
+type OfferAssetCardUi = {
     id: OfferId;
-    tagline: string;
-    bannerUrl: string;
+    /** Absent when the list payload has no display name. */
+    name?: string;
+    /** Absent when the list payload has no asset. Display form of `asset.code`. */
+    symbol?: string;
     logoUrl: string;
-    formattedStartsAt: string;
-    formattedEndsAt: string | null;
 };
-declare const OfferCardUi: {
-    fromDomain: (offer: Offer, locale: string) => OfferCardUi;
+declare const OfferAssetCardUi: {
+    fromOffer: (offer: Offer) => OfferAssetCardUi;
+    fromDetail: (detail: OfferDetail) => OfferAssetCardUi;
 };
 
-interface Props {
-    offer: OfferCardUi;
-    /** Optional click handler. When provided, the card renders as interactive. */
-    onClick?: () => void;
-    /** Optional className applied to the card root element. */
+interface OffersAssetGridProps {
+    offers: OfferAssetCardUi[];
+    /**
+     * When set, each card is the hit target and reports its `OfferId`. Omit to
+     * render a non-interactive browse grid.
+     */
+    onOfferClick?: (offerId: OfferId) => void;
+    /** Maximum number of columns when horizontal space allows. Caps at platform 3. */
+    maxColumns?: number;
+    /** Optional className applied to the grid element. */
     className?: string;
-    /** Optional className applied to an outer wrapper element. */
+    /** Optional className applied to the outer wrapper element. */
     containerClassName?: string;
 }
 /**
- * Offer card. Self-scoped: renders fully styled on its own, with no
- * `CoinListStyleScope` needed. Also composed by {@link OffersGrid}.
+ * Responsive browse grid of {@link OfferAssetCard} leaves. Pure: no fetch, no
+ * provider. Distinct from {@link OffersGridView}, which lays out live-sale
+ * cards — hosts pick which grid to embed. Self-scoped. Mobile is one column;
+ * then 2 from `sm`, and up to 3 from `md` when `maxColumns` allows.
  */
-declare function OfferCard({ offer, onClick, className, containerClassName, }: Props): ReactNode;
+declare function OffersAssetGrid({ offers, onOfferClick, maxColumns, className, containerClassName, }: OffersAssetGridProps): ReactNode;
 
 interface OffersGridContainerProps {
     /** Maximum number of columns to render when horizontal space allows. */
@@ -2565,8 +3131,10 @@ interface OffersGridContainerProps {
     data?: Offer[];
 }
 /**
- * Displays a responsive grid of offers, backed by
- * {@link useOffersGridViewModel}.
+ * Displays a responsive live-sale grid of {@link OfferSaleCard}, backed by
+ * {@link useOffersGridViewModel}. List offers have no display name — the card
+ * shows logo + tagline until the host maps from detail. For equities /
+ * past-sales browse rows, compose {@link OffersAssetGrid} instead.
  *
  * Pass `data` (pre-fetched server-side) to use that data as-is and skip the
  * client-side fetch entirely. Uses the `loading` / `error` / `emptyState` slots
@@ -2578,10 +3146,52 @@ interface OffersGridContainerProps {
  */
 declare function OffersGridContainer({ data, onOfferClick, ...viewProps }?: OffersGridContainerProps): ReactNode;
 
+/**
+ * An offer as {@link OfferSaleCard} renders it. Countdown copy is derived in
+ * the leaf from `startsAt` / `endsAt` so it can tick; the mapper does not
+ * invent a name, price, FDV, unlock schedule, banner overlay, or wordmark.
+ * `fromOffer` omits `name` because the list payload has none — do not derive
+ * one from `slug`, and do not expect a wordmark. The card pairs `logoUrl` with
+ * `name` as an h2 and renders the h2 only when the field is present. Prefer
+ * {@link OfferSaleCardUi.fromDetail} when the host has a name. Missing logo
+ * omits the icon — name and tagline only.
+ */
+type OfferSaleCardUi = {
+    id: OfferId;
+    /** Absent when the list payload has no display name; only `fromDetail` sets it. */
+    name?: string;
+    tagline: string;
+    logoUrl: string;
+    startsAt: Date;
+    endsAt: Date | null;
+};
+declare const OfferSaleCardUi: {
+    fromOffer: (offer: Offer) => OfferSaleCardUi;
+    fromDetail: (detail: OfferDetail) => OfferSaleCardUi;
+};
+
+type OffersGridUiState = {
+    type: 'loading';
+} | {
+    type: 'error';
+    message: string;
+} | {
+    type: 'empty';
+} | {
+    type: 'content';
+    offers: OfferSaleCardUi[];
+    /** Whole card is clickable only when the host passed `onOfferClick`. View offer always shows. */
+    interactive: boolean;
+};
+type OffersGridUiEvent = {
+    type: 'ON_OFFER_CLICK';
+    offerId: OfferId;
+};
+
 interface OffersGridViewProps {
     state: OffersGridUiState;
     onEvent: (event: OffersGridUiEvent) => void;
-    /** Maximum number of columns to render when horizontal space allows. */
+    /** Maximum number of columns to render when horizontal space allows. Caps at platform 2. */
     maxColumns?: number;
     /** Optional className applied to the grid element. */
     className?: string;
@@ -2595,14 +3205,52 @@ interface OffersGridViewProps {
     emptyState?: ReactNode;
 }
 /**
- * Renders every state of the offers grid. Pure: it holds no state, fetches
- * nothing, and reports clicks through `onEvent`.
+ * Renders every state of the live-sale offers grid ({@link OfferSaleCard}).
+ * Pure: it holds no state, fetches nothing, and reports clicks through
+ * `onEvent`. Platform layout is at most 2×2 with 24px gaps on desktop (16px on
+ * mobile, single column). For equities / past-sales browse rows, embed
+ * {@link OffersAssetGrid} instead.
  *
  * Self-scoped: renders fully styled on its own, with no `CoinListStyleScope`
  * needed.
  */
 declare function OffersGridView(props: OffersGridViewProps): ReactNode;
 
+interface OfferAssetCardProps {
+    offer: OfferAssetCardUi;
+    /** When set, the whole card is the hit target. */
+    onClick?: () => void;
+    /** Optional className applied to the card root element. */
+    className?: string;
+    /** Optional className applied to an outer wrapper element. */
+    containerClassName?: string;
+}
+/**
+ * Light browse-row catalogue card. Self-scoped. Header is API `logoUrl`
+ * beside company `name` (h2) and asset `symbol` under it — not a wordmark.
+ * Responsive hug: tighter pad / logo / type below `md`, desktop keeps the
+ * H4 + 48px logo row. Hosts compose this beside {@link OfferSaleCard}; the
+ * card does not pick a variant itself.
+ */
+declare function OfferAssetCard({ offer, onClick, className, containerClassName, }: OfferAssetCardProps): ReactNode;
+
+interface OfferSaleCardProps {
+    offer: OfferSaleCardUi;
+    /** Host click handler. View offer always renders; this wires the hit target. */
+    onClick?: () => void;
+    /** Optional className applied to the card root element. */
+    className?: string;
+    /** Optional className applied to an outer wrapper element. */
+    containerClassName?: string;
+}
+/**
+ * Dark live-sale catalogue card. Self-scoped. Header is API `logoUrl` beside
+ * the company `name` as an h2, then the tagline — not a wordmark. The same
+ * logo is painted as a faint right-shifted watermark over the gradient.
+ * Responsive hug layout; View offer always renders. No token price, FDV or unlock.
+ */
+declare function OfferSaleCard({ offer, onClick, className, containerClassName, }: OfferSaleCardProps): ReactNode;
+
 type RequirementsChecklistUiState = {
     type: 'loading';
 } | {
@@ -2774,137 +3422,6 @@ interface RequirementItemProps {
  */
 declare function RequirementItem({ ui, expanded, onToggle, className, onAction, onRemoveWallet, walletsStatus, onContactSupport, }: RequirementItemProps): react_jsx_runtime.JSX.Element;
 
-/**
- * The host-provided wallet the ownership flow signs with: the signing-only
- * {@link EvmSigner} plus the {@link EthereumChain} the signature is proven on.
- * `chain` rides on the wallet (not the offer) because the binding is
- * chain-agnostic: it only records which EVM chain signed.
- */
-type ConnectWallet = EvmSigner & {
-    readonly chain: EthereumChain;
-};
-/**
- * Machine-readable classification of a connect-wallet failure, so consumers can
- * branch on the cause (e.g. hide a retry affordance on a terminal failure)
- * instead of pattern-matching a display string.
- */
-type ConnectWalletErrorCode = 'not_authenticated' | 'user_rejected' | 'wallet_not_whitelisted' | 'max_wallets_reached' | 'unknown';
-/**
- * A classified connect-wallet failure. `retryable` is false when re-signing the
- * same wallet can never succeed (a terminal binding rejection, or no signed-in
- * session). Display copy is the caller's concern, kept out of the core.
- */
-type ConnectWalletFlowError = {
-    code: ConnectWalletErrorCode;
-    retryable: boolean;
-};
-/** Progress phases emitted by {@link connectExternalWalletFlow}, in order. */
-type ConnectWalletPhase = 'requesting-challenge' | 'signing-message' | 'submitting-signature';
-type ConnectWalletFlowResult = {
-    type: 'success';
-    binding: OfferOptionAddress;
-} | {
-    type: 'cancelled';
-} | {
-    type: 'error';
-    error: ConnectWalletFlowError;
-};
-/**
- * The client surface the flow actually depends on, kept narrow on purpose.
- *
- * Named as a structural slice rather than `Pick<CoinListClient, 'wallets'>` so
- * this feature does not import its layer's entry point: a flow takes the
- * namespaces it needs, the way `@/client/core/checkout/**` flows do.
- */
-type ConnectWalletClient = {
-    wallets: WalletsNamespace;
-};
-type ConnectWalletFlowParams = {
-    coinlist: ConnectWalletClient;
-    /** Host-provided connected wallet the flow signs with. */
-    wallet: ConnectWallet;
-    offerId: OfferId;
-    offerOptionId: OfferOptionId;
-    /** Challenge framing; defaults to `'siwe'`. */
-    challengeType?: WalletChallengeType;
-    /** SIWE statement shown in the signing prompt. */
-    statement?: string;
-    /**
-     * Polled before each irreversible step (signing, binding). Return true to
-     * abandon a superseded attempt; the flow then resolves `{ type: 'cancelled' }`
-     * without prompting the wallet or binding. React hooks pass a generation
-     * check here; non-React callers can omit it.
-     */
-    isCancelled?: () => boolean;
-    /** Reports flow progress for consumers rendering loading states. */
-    onProgress?: (phase: ConnectWalletPhase) => void;
-};
-/**
- * Drives the external-wallet ownership flow for one offer option:
- * `createWalletOwnershipChallenge` -> host `wallet.signMessage` ->
- * `connectExternalWallet`. Pure and signer-agnostic: signing is delegated to
- * the host-provided {@link ConnectWallet}, and no React is involved so non-hook
- * consumers can drive it directly (mirrors `authorizeWallet` in `swap-flows`).
- * EVM / EOA + SIWE only for now.
- */
-declare function connectExternalWalletFlow(params: ConnectWalletFlowParams): Promise<ConnectWalletFlowResult>;
-
-/**
- * A display-ready connect-wallet error: the core flow's machine-readable code
- * and `retryable` flag, plus copy for the UI.
- */
-type ConnectWalletError = {
-    code: ConnectWalletErrorCode;
-    message: string;
-    retryable: boolean;
-};
-/**
- * Signing-in-flight and the last sign error live inside the READY state (not a
- * separate top-level state) so a failed attempt returns to READY and can be
- * retried without re-opening the modal. Mirrors {@link SignState} in
- * `useTaxDocument`.
- */
-type ConnectWalletSignState = {
-    type: 'idle';
-    error: ConnectWalletError | null;
-} | {
-    type: 'signing';
-};
-type ConnectWalletState = {
-    type: 'NEEDS_WALLET';
-} | {
-    type: 'READY';
-    address: EvmWalletAddress;
-    sign: ConnectWalletSignState;
-} | {
-    type: 'CONNECTED';
-    binding: OfferOptionAddress;
-};
-interface UseConnectWalletOptions {
-    /** The hook resets state each time it opens. */
-    isOpen: boolean;
-    offerId: OfferId;
-    offerOptionId: OfferOptionId;
-    /** Host-provided connected wallet, or `null` while none is connected. */
-    wallet: ConnectWallet | null;
-    /** Challenge framing; defaults to `'siwe'`. */
-    challengeType?: WalletChallengeType;
-    /** SIWE statement shown in the signing prompt. */
-    statement?: string;
-}
-interface UseConnectWalletResult {
-    state: ConnectWalletState;
-    /** READY.sign: idle -> signing -> (CONNECTED | idle w/ error). No-op otherwise. */
-    onSign: () => void;
-}
-/**
- * React wrapper over {@link connectExternalWalletFlow}. Owns the modal state
- * machine, the display copy, and generation-token supersession (so a wallet
- * switch, modal close, or unmount cancels an in-flight attempt). The flow logic
- * itself lives in the framework-free core so non-React consumers can drive it.
- */
-declare function useConnectWallet({ isOpen, offerId, offerOptionId, wallet, challengeType, statement, }: UseConnectWalletOptions): UseConnectWalletResult;
-
 type LoadRequirementsReason = 'not-authenticated' | 'generic-error';
 type LoadRequirementsState = {
     type: 'LOADING';
@@ -3008,8 +3525,7 @@ interface RequirementsChecklistContainerProps {
      */
     data?: RequirementsData;
     /**
-     * Options for the inline Sumsub verification flow shown for KYC-backed
-     * requirements (`identity_verified`, `kyc_approved`, `accreditation`) when
+     * Options for the inline Sumsub verification flow, shown when
      * `onRequirementActionOverride` is not provided. The flow starts whenever
      * the requirement's status carries a `kycLevel` - the backend prescribes
      * both the level and whether the applicant must be reset first.
@@ -3118,8 +3634,8 @@ interface IdentityVerificationContainerProps {
  * Inline Sumsub identity verification flow, backed by
  * {@link useIdentityVerificationViewModel}, which fetches the Sumsub WebSDK
  * access token via {@link useKycToken}. Used by
- * `RequirementsChecklistContainer` for `identity_verified` requirements, and
- * can also be rendered standalone.
+ * `RequirementsChecklistContainer` for KYC-backed requirements, and can also
+ * be rendered standalone.
  */
 declare function IdentityVerificationContainer({ levelName, reset, locale, onSubmitted, onError, className, }: IdentityVerificationContainerProps): ReactNode;
 
@@ -3333,26 +3849,164 @@ type ConnectWalletScreenUi = {
      * never succeed by re-signing the same wallet, so the sign button is
      * disabled and only switching wallets helps.
      */
-    signDisabled: boolean;
+    signDisabled: boolean;
+};
+
+interface ConnectWalletModalViewProps {
+    state: ConnectWalletModalUiState;
+    onEvent: (event: ConnectWalletModalUiEvent) => void;
+    className?: string;
+}
+/**
+ * Modal for the external-wallet ownership flow: prompt for a wallet, then ask
+ * the user to sign a message proving they own it. Pure: signing is requested
+ * through `onEvent` and performed by the host's wallet, since the SDK never
+ * bundles a wallet stack.
+ *
+ * No portal is used - rendering stays inside the normal DOM tree. Self-scoped:
+ * renders fully styled on its own, with no `CoinListStyleScope` needed, so it
+ * is styled wherever the host places it and wherever the checklist renders it
+ * (as a sibling of `RequirementsChecklistView`, outside that View's scope).
+ */
+declare function ConnectWalletModalView({ state, onEvent, className, }: ConnectWalletModalViewProps): ReactNode;
+
+/**
+ * Classifies an error thrown by an {@link EvmWallet} into a typed
+ * {@link WalletError}. Pass the transaction `hash` when awaiting a receipt so a
+ * timeout can be reported against it.
+ *
+ * **Every check walks the cause chain rather than testing the thrown object.**
+ * viem never throws the error that says what happened: `sendTransaction` wraps
+ * it in a `TransactionExecutionError` and `writeContract` wraps that again in a
+ * `ContractFunctionExecutionError`, so a MetaMask 4001 arrives as a
+ * `UserRejectedRequestError` two levels down. Testing the top level - which is
+ * what this did until it was caught in a partner demo - classified every real
+ * refusal and every real revert as `unknown`, and that is public API: a host
+ * branching on `user_rejected` to stay quiet when a user simply cancels never
+ * saw one.
+ */
+declare function classifyWalletError(error: unknown, ctx?: {
+    hash?: Hash;
+}): WalletError;
+
+/**
+ * A {@link Logger} that writes structured records to the browser console
+ * through pino.
+ *
+ * ```ts
+ * createCoinListClient({
+ *   ...config,
+ *   logger: pinoClientLogger({ isDev: false, level: 'info' }),
+ * });
+ * ```
+ *
+ * The browser counterpart of {@link pinoServerLogger}. Two factories rather
+ * than one that sniffs `typeof window`, because the environment is the
+ * outermost axis of this codebase: the client build resolves pino's browser
+ * entry and the server build resolves its node entry, neither pays for the
+ * other, and neither has a branch in it.
+ *
+ * `browser: { asObject: true }` is the one non-default: pino's browser default
+ * hands its arguments to `console.info` unchanged, which is not a structured
+ * record. With it, each line is a single object carrying `level`, `time`,
+ * `name`, `scope`, the bindings and every field - the same shape the server
+ * writes as ndjson, so a record read in devtools and a record read in a log
+ * aggregator are the same record.
+ *
+ * ## Production
+ *
+ * **Running this in a production browser is not advised**, and the browser is
+ * where that advice is easiest to justify. **A browser console is readable by
+ * anyone with the page open**, and extensions can scrape it, so even the
+ * redacted levels put SDK-authored classification and server-minted ids
+ * somewhere you do not control. Nothing is transmitted anywhere either: pino's
+ * browser build writes to the console and stops, so what you get for the risk
+ * is a record only the end user can read.
+ *
+ * If you run one anyway, `isDev: false` restricts you to `'error'`, `'warn'`
+ * and `'info'` - `{ isDev: false, level: 'debug' }` does not compile, see
+ * {@link PinoLoggerOptions}. Those levels are redacted by construction; what
+ * follows from that in your environment is your call to make, not a warranty
+ * the SDK offers.
+ *
+ * If you want these records off the page, implement {@link Logger} yourself
+ * over your own transport, or pass a pino instance configured with
+ * `browser.transmit` - the seam is deliberately small enough to make that easy.
+ *
+ * Holds no module-level state: every call builds its own pino instance, and
+ * the level is fixed at construction, so two loggers never interfere. Fixed is
+ * this implementation's choice, not the seam's - the SDK re-reads
+ * {@link Logger.level} before every log call - so if you want a level you can
+ * change at runtime, implement {@link Logger} over your own pino instance
+ * rather than calling this.
+ */
+declare function pinoClientLogger(options: PinoLoggerOptions): Logger;
+
+/**
+ * Machine-readable classification of a connect-wallet failure, so consumers can
+ * branch on the cause (e.g. hide a retry affordance on a terminal failure)
+ * instead of pattern-matching a display string.
+ */
+type ConnectWalletErrorCode = 'not_authenticated' | 'user_rejected' | 'wallet_not_whitelisted' | 'max_wallets_reached' | 'unknown';
+/**
+ * A classified connect-wallet failure. `retryable` is false when re-signing the
+ * same wallet can never succeed (a terminal binding rejection, or no signed-in
+ * session). Display copy is the caller's concern, kept out of the core.
+ */
+type ConnectWalletFlowError = {
+    code: ConnectWalletErrorCode;
+    retryable: boolean;
+};
+/** Progress phases emitted by {@link connectExternalWalletFlow}, in order. */
+type ConnectWalletPhase = 'requesting-challenge' | 'signing-message' | 'submitting-signature';
+type ConnectWalletFlowResult = {
+    type: 'success';
+    binding: OfferOptionAddress;
+} | {
+    type: 'cancelled';
+} | {
+    type: 'error';
+    error: ConnectWalletFlowError;
+};
+/**
+ * The client surface the flow actually depends on, kept narrow on purpose.
+ *
+ * Named as a structural slice rather than `Pick<CoinListClient, 'wallets'>` so
+ * this feature does not import its layer's entry point: a flow takes the
+ * namespaces it needs, the way `@/client/core/checkout/**` flows do.
+ */
+type ConnectWalletClient = {
+    wallets: WalletsNamespace;
+};
+type ConnectWalletFlowParams = {
+    coinlist: ConnectWalletClient;
+    /** Host-provided connected wallet the flow signs with. */
+    wallet: ConnectWallet;
+    offerId: OfferId;
+    offerOptionId: OfferOptionId;
+    /** Challenge framing; defaults to `'siwe'`. */
+    challengeType?: WalletChallengeType;
+    /** SIWE statement shown in the signing prompt. */
+    statement?: string;
+    /**
+     * Polled before each irreversible step (signing, binding). Return true to
+     * abandon a superseded attempt; the flow then resolves `{ type: 'cancelled' }`
+     * without prompting the wallet or binding. React hooks pass a generation
+     * check here; non-React callers can omit it.
+     */
+    isCancelled?: () => boolean;
+    /** Reports flow progress for consumers rendering loading states. */
+    onProgress?: (phase: ConnectWalletPhase) => void;
 };
-
-interface ConnectWalletModalViewProps {
-    state: ConnectWalletModalUiState;
-    onEvent: (event: ConnectWalletModalUiEvent) => void;
-    className?: string;
-}
 /**
- * Modal for the external-wallet ownership flow: prompt for a wallet, then ask
- * the user to sign a message proving they own it. Pure: signing is requested
- * through `onEvent` and performed by the host's wallet, since the SDK never
- * bundles a wallet stack.
- *
- * No portal is used - rendering stays inside the normal DOM tree. Self-scoped:
- * renders fully styled on its own, with no `CoinListStyleScope` needed, so it
- * is styled wherever the host places it and wherever the checklist renders it
- * (as a sibling of `RequirementsChecklistView`, outside that View's scope).
+ * Drives the external-wallet ownership flow for one offer option:
+ * `createWalletOwnershipChallenge` -> host `wallet.signMessage` ->
+ * `connectExternalWallet`. Pure and signer-agnostic: signing is delegated to
+ * the host-provided {@link ConnectWallet}, and no React is involved so non-hook
+ * consumers can drive it directly (mirrors `authorizeWallet` in `swap-flows`).
+ * EVM / EOA + SIWE only for now.
  */
-declare function ConnectWalletModalView({ state, onEvent, className, }: ConnectWalletModalViewProps): ReactNode;
+declare function connectExternalWalletFlow(params: ConnectWalletFlowParams): Promise<ConnectWalletFlowResult>;
 
 interface UseCoinListSignInCardViewModelOptions {
     /** `error` renders the sign-in failure banner. Defaults to `idle`. */
@@ -3415,104 +4069,486 @@ interface UseCompleteOAuthOptions {
  *
  * Must be used within {@link CoinListProvider}.
  */
-declare function useCompleteOAuth(options: UseCompleteOAuthOptions): void;
+declare function useCompleteOAuth(options: UseCompleteOAuthOptions): void;
+
+type LoadParticipationsReason = 'not-authenticated' | 'generic-error';
+type LoadParticipationsState = {
+    type: 'LOADING';
+} | {
+    type: 'ERROR';
+    reason: LoadParticipationsReason;
+} | {
+    type: 'CONTENT';
+    participations: Participation[];
+};
+interface UseParticipationsOptions {
+    /**
+     * Participations pre-fetched on the server (e.g. via `CoinListServer#tokenSale.list()`).
+     * When provided, the hook uses this data as-is and skips the client-side fetch entirely.
+     */
+    data?: Participation[];
+}
+interface UseParticipationsResult {
+    participationsState: LoadParticipationsState;
+}
+/**
+ * Loads all CoinList participations for the current user and exposes a UI-friendly state.
+ * Optionally filters by offer when `offerId` is provided.
+ *
+ * Pass `data` (pre-fetched server-side) to use that data as-is and skip
+ * the client-side fetch entirely.
+ *
+ * Returns `LOADING` while CoinList is initializing or while participations are being fetched.
+ * Returns `CONTENT` with all participations when `fetchParticipations()` succeeds.
+ * Returns `ERROR` with:
+ * - `not-authenticated` when fetching fails with {@link NotAuthenticatedError}
+ * - `generic-error` for any other failure
+ */
+declare function useParticipations(offerId?: OfferId, options?: UseParticipationsOptions): UseParticipationsResult;
+
+/**
+ * How much the user is spending, and the transaction built for it.
+ *
+ * It names no asset. The transaction publishes the scale of every amount on
+ * it, and the offer names what is being bought, so there is nothing about the
+ * purchase left for this step to carry downstream.
+ */
+type OndoBuyAmountConfirmed = {
+    amount: BlockchainAmount;
+    inputAsset: StablecoinSymbol;
+    transaction: OndoBuyTransaction;
+};
+type OndoBuyAmountStepInput = {
+    type: 'incomplete';
+} | {
+    type: 'active';
+    /** The wallet confirmed in step 1: it holds the funds and signs. */
+    wallet: EvmWallet;
+    /**
+     * The market as last read, or `null` while it is unknown. Unknown does
+     * not block: a dropped poll is not evidence the market is closed, and
+     * building will fail with a real reason if it is.
+     */
+    tradingStatus: OndoTradingStatus | null;
+    /** The offer's minimum, in whole USD. `null` when it publishes none. */
+    minimumPurchaseUsd: number | null;
+} | {
+    type: 'complete';
+    wallet: EvmWallet;
+    amount: BlockchainAmount;
+    inputAsset: StablecoinSymbol;
+};
+interface UseOndoBuyAmountViewModelOptions {
+    stepInput: OndoBuyAmountStepInput;
+    /** Ondo's API symbol, e.g. `AAPLon`. */
+    ondoSymbol: AssetSymbol;
+    /** The chain the order executes on: balances, approval, and the contract. */
+    chain: EthereumChain;
+    /**
+     * When false, the step neither fetches nor polls. Defaults to true.
+     *
+     * The step being `incomplete` is not the same thing and does not stand in
+     * for it: a checkout switched off mid-flow leaves this step `active`, and
+     * the balance poll would run on behind a screen nobody is looking at.
+     */
+    enabled?: boolean;
+    /** Called once the approval has mined and the transaction has been built. */
+    onComplete: (confirmed: OndoBuyAmountConfirmed) => void;
+    /** Called when the user reopens this step from a later one. */
+    onEdit: () => void;
+}
+interface UseOndoBuyAmountViewModelResult {
+    state: OndoBuyAmountUiState;
+    onEvent: (event: OndoBuyAmountUiEvent) => void;
+}
+/**
+ * Drives step 2 of the Ondo checkout: how much to spend, and getting the order
+ * ready to place.
+ *
+ * Confirming does real work - it approves the swap contract to pull the
+ * amount, then builds the transaction that spends it - so the CTA reports the on-chain phase
+ * as loading copy and every failure comes back as copy under the field.
+ *
+ * Everything checkable locally is checked before the wallet is asked to sign:
+ * the balance, the offer's minimum, and Ondo's own order caps. Each of those
+ * would otherwise cost the user a real approval transaction before failing.
+ */
+declare function useOndoBuyAmountViewModel({ stepInput, ondoSymbol, chain, enabled, onComplete, onEdit, }: UseOndoBuyAmountViewModelOptions): UseOndoBuyAmountViewModelResult;
+type OndoBuyAmountValidation = {
+    valid: true;
+    amount: BlockchainAmount;
+} | {
+    valid: false;
+    error: string;
+};
+/**
+ * The checks that can be made without asking the wallet for anything, in the
+ * order a user would hit them: is it a number, is it more than nothing, can
+ * they afford it, does the offer accept it, will Ondo fill it.
+ *
+ * Exported for the property tests: the ladder is money logic, and the property
+ * that matters (nothing above the balance or the caps is ever accepted) is
+ * about the whole ladder rather than any one rung.
+ */
+declare function validateAmount({ input, decimals, balance, symbol, minimumPurchaseUsd, tradingStatus, locale, }: {
+    input: string;
+    decimals: AssetDecimals;
+    /** `null` while no balance has been read; the check is then skipped. */
+    balance: bigint | null;
+    symbol: AssetSymbol;
+    minimumPurchaseUsd: number | null;
+    tradingStatus: OndoTradingStatus | null;
+    locale: string;
+}): OndoBuyAmountValidation;
+
+/**
+ * Why an Ondo read failed, in the only two flavours a UI acts on differently.
+ *
+ * `not-authenticated` is split out because no retry helps until the user signs
+ * in, and because the remedy is one the UI can name. Everything else collapses
+ * into `generic-error` and is offered a retry.
+ *
+ * That is a deliberate over-offer, not a claim that every such failure is
+ * retryable. A `ValidationError` from the DTO boundary - an unreadable expiry,
+ * a zero output amount, a scale no amount could be denominated in - is
+ * deterministic, and refreshing spends an attestation to fail again. It stays
+ * lumped in because each one means frontline changed its encoding, which is
+ * unreachable in a deployed pair and not worth a public union member and a
+ * branch in every consumer to distinguish. Split it out if that stops being
+ * true.
+ */
+type OndoLoadErrorReason = 'not-authenticated' | 'generic-error';
+declare function ondoLoadErrorReason(error: unknown): OndoLoadErrorReason;
+
+/**
+ * The state of the built purchase a review step acts on.
+ *
+ * `isRefreshing` rides on `CONTENT` rather than replacing it, so a refresh in
+ * flight never blanks the numbers the user is reading. A refresh that fails
+ * keeps them too, and reports why alongside - the previous purchase may still
+ * be good, and a failed refresh is fixed by refreshing again.
+ */
+type LoadOndoBuyTransactionState = {
+    type: 'LOADING';
+} | {
+    type: 'ERROR';
+    reason: OndoLoadErrorReason;
+} | {
+    type: 'CONTENT';
+    transaction: OndoBuyTransaction;
+    isRefreshing: boolean;
+    /** Why the last refresh failed; `null` when the purchase is fresh. */
+    refreshError: OndoLoadErrorReason | null;
+};
+interface UseOndoBuyTransactionOptions {
+    /**
+     * The order to build, or `null` while there is not one yet - before the
+     * amount step is confirmed. A `null` request fetches nothing.
+     */
+    request: BuildOndoBuyParams | null;
+    /**
+     * A purchase the caller already holds, typically the one `prepareBuy`
+     * returned with the approval. When present the hook adopts it and skips the
+     * initial fetch; `refetch` still fetches. This is what keeps the flow to one
+     * attestation per order.
+     */
+    data?: OndoBuyTransaction;
+    /** When false, the hook does not fetch. */
+    enabled: boolean;
+}
+interface UseOndoBuyTransactionResult {
+    state: LoadOndoBuyTransactionState;
+    /** Builds a fresh purchase for the same order. Spends an attestation. */
+    refetch: () => void;
+}
+/**
+ * Holds the firm, expiring purchase the buy review step places an order
+ * against, and rebuilds it on demand.
+ *
+ * **Never polls.** Building spends an attestation, so a new one is only ever
+ * obtained when the caller asks - on `refetch`, or on the first render if no
+ * `data` was supplied. That is also why an expired purchase is left expired
+ * here: whether to replace it is the user's call, not a timer's.
+ *
+ * Disabled it fetches nothing and stays on whatever state it opened with. That
+ * is `LOADING` and not an empty `CONTENT` because there is no empty
+ * purchase: firm calldata for an order that does not exist is not
+ * representable. A caller that switches this hook off should switch its own
+ * rendering off with it - which is what the review step does, since a step
+ * that is not active is `incomplete` and never reads this state at all.
+ *
+ * One of a pair with `useOndoSellTransaction`, and deliberately not one hook
+ * over both. The two endpoints answer different shapes - a purchase commits to
+ * an exact quantity, a sale to a range - so a shared hook would hand every
+ * review step a union to narrow after its own directory had already settled
+ * which trade it was. The machinery below is the price of that, and it is the
+ * cheaper half: what a screen reads off `CONTENT` is the expensive half.
+ */
+declare function useOndoBuyTransaction(options: UseOndoBuyTransactionOptions): UseOndoBuyTransactionResult;
+
+type OndoBuyReviewStepInput = {
+    type: 'incomplete';
+} | {
+    type: 'active';
+    /** The wallet that signs, pays, and receives. */
+    wallet: EvmWallet;
+    /** What the user is spending, in the input asset's base units. */
+    amount: BlockchainAmount;
+    inputAsset: StablecoinSymbol;
+    /**
+     * The purchase `prepareBuy` already built for this order. Omitting
+     * it makes this step build one itself, which is the path a partner
+     * driving the review on its own takes - and the only way its `loading`
+     * and `error` states are reached.
+     */
+    transaction?: OndoBuyTransaction;
+};
+interface UseOndoBuyReviewViewModelOptions {
+    stepInput: OndoBuyReviewStepInput;
+    /**
+     * Ondo's API symbol, e.g. `AAPLon`. Rebuilds the transaction, and names the
+     * bought asset on the card.
+     */
+    ondoSymbol: AssetSymbol;
+    /** The chain the order executes on. */
+    chain: EthereumChain;
+    /**
+     * The offer being bought: the asset's name and its only icon.
+     *
+     * The identity comes from here rather than from the price poll, so the card
+     * agrees with the reference panel beside it and a dropped poll cannot leave
+     * the review unable to say what was bought.
+     */
+    offer: OfferDetail;
+    /**
+     * When false, the step neither builds a transaction nor counts down, and
+     * neither refreshing the quote nor placing an order does anything. Defaults
+     * to true.
+     *
+     * The step being `incomplete` is not the same thing and does not stand in
+     * for it: a checkout switched off mid-flow leaves this step `active`, so the
+     * committed quote is still here to render and its clock would tick on behind
+     * a screen nobody is looking at.
+     */
+    enabled?: boolean;
+    /** Called once the swap has mined. */
+    /** Always a buy: this step only ever places one. */
+    onComplete: (order: OndoBuyOrderPlaced) => void;
+}
+interface UseOndoBuyReviewViewModelResult {
+    state: OndoBuyReviewUiState;
+    onEvent: (event: OndoBuyReviewUiEvent) => void;
+}
+/**
+ * Drives step 3 of the Ondo checkout: what the order comes to, how long the
+ * price holds, and placing it.
+ *
+ * The quote is firm and short-lived, so most of this is about time. The
+ * countdown drives the line above the CTA, and a quote inside
+ * {@link ONDO_QUOTE_EXPIRY_THRESHOLD_MS} of its deadline is treated as already
+ * gone: placing an order is not instant, and a transaction that arrives after
+ * the deadline reverts at the user's expense.
+ *
+ * Refreshing is always something the user asks for. Each refresh builds a new
+ * transaction, which spends an attestation, so nothing here is on a timer.
+ */
+declare function useOndoBuyReviewViewModel({ stepInput, ondoSymbol, chain, offer, enabled, onComplete, }: UseOndoBuyReviewViewModelOptions): UseOndoBuyReviewViewModelResult;
 
-type LoadParticipationsReason = 'not-authenticated' | 'generic-error';
-type LoadParticipationsState = {
-    type: 'LOADING';
+/**
+ * Which step is being filled in, carrying everything the ones before it
+ * settled.
+ *
+ * A union rather than a step index plus nullable fields: the amount step
+ * cannot run without a wallet, and the review step cannot run without a built
+ * transaction, so neither is representable here.
+ */
+type OndoBuyStep = {
+    type: 'wallet';
 } | {
-    type: 'ERROR';
-    reason: LoadParticipationsReason;
+    type: 'amount';
+    wallet: EvmWallet;
 } | {
-    type: 'CONTENT';
-    participations: Participation[];
+    type: 'review';
+    wallet: EvmWallet;
+    amount: BlockchainAmount;
+    inputAsset: StablecoinSymbol;
+    /** Built by `prepareBuy` when the amount was confirmed. */
+    transaction: OndoBuyTransaction;
 };
-interface UseParticipationsOptions {
+interface UseOndoBuyCheckoutViewModelOptions {
     /**
-     * Participations pre-fetched on the server (e.g. via `CoinListServer#tokenSale.list()`).
-     * When provided, the hook uses this data as-is and skips the client-side fetch entirely.
+     * The offer being bought: names the asset and supplies its logo.
+     *
+     * Fixed for the lifetime of the hook — see the note on
+     * {@link useOndoBuyCheckoutViewModel} about switching offers.
      */
-    data?: Participation[];
+    offer: OfferDetail;
+    /**
+     * Ondo's API symbol for the asset, e.g. `AAPLon`.
+     *
+     * Explicit rather than derived from `offer.asset.code`: Ondo's symbol tracks
+     * the underlying ticker and changes on a rebrand, and the two already
+     * disagree on Sepolia, where a mock asset stands in.
+     */
+    ondoSymbol: AssetSymbol;
+    /**
+     * The chain the order executes on: the balance read, the approval and the
+     * broadcast. Quotes are priced against Ondo production whatever this says,
+     * since Ondo runs no sandbox, so on a testnet the price is real and the
+     * money is not.
+     *
+     * Fixed for the lifetime of the hook, as `offer` is.
+     */
+    chain: EthereumChain;
+    /** The host's wallets, and the lambdas that connect and disconnect one. */
+    wallets: CheckoutWalletSelection;
+    /**
+     * Default `true`. When `false` nothing is fetched and no timer runs, so the
+     * hook can be called unconditionally beside other providers' viewmodels.
+     */
+    enabled?: boolean;
+    /**
+     * Fired once the swap has mined. The confirmation dialog shows either way;
+     * this is for a host that wants to navigate, refresh a portfolio, or log.
+     */
+    onOrderConfirmed?: (order: OndoOrderPlaced) => void;
 }
-interface UseParticipationsResult {
-    participationsState: LoadParticipationsState;
+interface UseOndoBuyCheckoutViewModelResult {
+    state: OndoBuyCheckoutUiState;
+    onEvent: (event: OndoBuyCheckoutUiEvent) => void;
 }
 /**
- * Loads all CoinList participations for the current user and exposes a UI-friendly state.
- * Optionally filters by offer when `offerId` is provided.
+ * Drives the whole Ondo buy checkout: the three steps, the reference panel
+ * beside them, and the dialog that closes the flow.
  *
- * Pass `data` (pre-fetched server-side) to use that data as-is and skip
- * the client-side fetch entirely.
+ * It owns the step machine and the two polls; each step's own viewmodel owns
+ * its screen. The polls live here because they are shared - the sidebar shows
+ * the price and the amount step gates on the market - and because the price is
+ * sized by whatever the flow has settled on so far.
  *
- * Returns `LOADING` while CoinList is initializing or while participations are being fetched.
- * Returns `CONTENT` with all participations when `fetchParticipations()` succeeds.
- * Returns `ERROR` with:
- * - `not-authenticated` when fetching fails with {@link NotAuthenticatedError}
- * - `generic-error` for any other failure
+ * There is no flow-level error state. Every failure belongs to a region: a
+ * price that will not load leaves the panel's corner unavailable, and an order
+ * that will not go through is reported on the review step, next to the button
+ * that caused it.
+ *
+ * `offer` and `chain` are read as fixed for the lifetime of the hook. The step
+ * machine holds a committed quote and an approval granted on one chain for one
+ * order, so changing either in place would carry them onto an order they were
+ * never priced for. Remount instead: give the component holding this hook a
+ * `key` that changes with the offer and the chain, as {@link CheckoutContainer}
+ * documents. That discards the flow with its component instance, which is the
+ * only reset that cannot land between an approval and the broadcast it was
+ * granted for.
  */
-declare function useParticipations(offerId?: OfferId, options?: UseParticipationsOptions): UseParticipationsResult;
+declare function useOndoBuyCheckoutViewModel({ offer, ondoSymbol, chain, wallets, enabled, onOrderConfirmed, }: UseOndoBuyCheckoutViewModelOptions): UseOndoBuyCheckoutViewModelResult;
 
 /**
- * How much the user is spending, and the transaction built for it.
+ * How much of the asset the user is selling, and the transaction built for it.
  *
- * It names no asset. The transaction publishes the scale of every amount on
- * it, and the offer names what is being bought, so there is nothing about the
- * purchase left for this step to carry downstream.
+ * It carries `inputAsset` where the buy step's counterpart carries a
+ * stablecoin: the asset being sold is in no registry, so the symbol has to
+ * travel with the amount for anything downstream to name it.
  */
-type OndoAmountConfirmed = {
+type OndoSellAmountConfirmed = {
     amount: BlockchainAmount;
-    inputAsset: StablecoinSymbol;
-    transaction: OndoSwapTransaction;
+    inputAsset: AssetSymbol;
+    transaction: OndoSellTransaction;
+};
+/**
+ * The asset a sell spends, as the quote resolves it.
+ *
+ * Both halves come off `GET /v1/ondo/swap/quote`, which is the SDK's only
+ * source for either: `TOKEN_REGISTRY` knows the stablecoins swaps are funded
+ * with and no provider's asset. The address is what the balance is read on and
+ * what the swap contract is approved for; the decimals are what the typed
+ * amount is parsed at.
+ */
+type OndoSellAsset = {
+    address: EvmContractAddress;
+    asset: Erc20Asset;
 };
-type OndoAmountStepInput = {
+type OndoSellAmountStepInput = {
     type: 'incomplete';
 } | {
     type: 'active';
-    /** The wallet confirmed in step 1: it holds the funds and signs. */
+    /** The wallet holding the asset, and the one that signs. */
     wallet: EvmWallet;
+    /**
+     * Whether that wallet is one of the user's CoinList wallets, which
+     * decides how the balance card names it: an embedded wallet reads
+     * `from CoinList Wallet`, an external one `from 0x…`.
+     *
+     * Decided by the parent, which holds `wallets.embedded`. A preselected
+     * wallet need not appear in that list at all, so this cannot be inferred
+     * from how the step was reached.
+     */
+    walletIsEmbedded: boolean;
+    /**
+     * The asset as the sell quote resolves it, or `null` while the poll has
+     * not answered. Without it there is no balance to read and no scale to
+     * parse the field at, so the step renders but cannot be confirmed.
+     */
+    sellAsset: OndoSellAsset | null;
     /**
      * The market as last read, or `null` while it is unknown. Unknown does
      * not block: a dropped poll is not evidence the market is closed, and
      * building will fail with a real reason if it is.
      */
     tradingStatus: OndoTradingStatus | null;
-    /** The offer's minimum, in whole USD. `null` when it publishes none. */
-    minimumPurchaseUsd: number | null;
 } | {
     type: 'complete';
     wallet: EvmWallet;
     amount: BlockchainAmount;
-    inputAsset: StablecoinSymbol;
+    inputAsset: AssetSymbol;
 };
-interface UseOndoAmountViewModelOptions {
-    stepInput: OndoAmountStepInput;
-    /** Ondo's API symbol, e.g. `AAPLon`. */
+interface UseOndoSellAmountViewModelOptions {
+    stepInput: OndoSellAmountStepInput;
+    /** Ondo's API symbol, e.g. `TSLAon`. */
     ondoSymbol: AssetSymbol;
-    /** The chain the order executes on: balances, approval, and the contract. */
+    /** The chain the order executes on: the balance read, the approval and the broadcast. */
     chain: EthereumChain;
+    /** The offer being sold: supplies the asset's display name and its only icon. */
+    offer: OfferDetail;
+    /**
+     * When false, the step neither fetches nor polls. Defaults to true.
+     *
+     * The step being `incomplete` is not the same thing and does not stand in
+     * for it: a checkout switched off mid-flow leaves this step `active`, and
+     * the parent's own data hooks hold their last `CONTENT` rather than
+     * forgetting it - so the sell asset is still here to read a balance
+     * against, and the poll would run on behind a screen nobody is looking at.
+     */
+    enabled?: boolean;
     /** Called once the approval has mined and the transaction has been built. */
-    onComplete: (confirmed: OndoAmountConfirmed) => void;
+    onComplete: (confirmed: OndoSellAmountConfirmed) => void;
     /** Called when the user reopens this step from a later one. */
     onEdit: () => void;
 }
-interface UseOndoAmountViewModelResult {
-    state: OndoAmountUiState;
-    onEvent: (event: OndoAmountUiEvent) => void;
+interface UseOndoSellAmountViewModelResult {
+    state: OndoSellAmountUiState;
+    onEvent: (event: OndoSellAmountUiEvent) => void;
 }
 /**
- * Drives step 2 of the Ondo checkout: how much to spend, and getting the order
- * ready to place.
+ * Drives the amount step of the Ondo sell checkout: how much of the asset to
+ * sell, and getting the order ready to place.
  *
- * Confirming does real work - it approves the swap contract to pull the
- * amount, then builds the transaction that spends it - so the CTA reports the on-chain phase
- * as loading copy and every failure comes back as copy under the field.
+ * Confirming does real work - it approves the swap contract to pull the asset,
+ * then builds the transaction that spends it - so the CTA reports the on-chain
+ * phase as loading copy and every failure comes back as copy under the field.
+ * The approval is on the *asset*, not on a stablecoin, which is the one thing
+ * that makes this materially different from the buy step rather than a mirror
+ * of it: the token's address and decimals are not the SDK's to look up, so
+ * everything here waits on the sell quote.
  *
  * Everything checkable locally is checked before the wallet is asked to sign:
- * the balance, the offer's minimum, and Ondo's own order caps. Each of those
- * would otherwise cost the user a real approval transaction before failing.
- */
-declare function useOndoAmountViewModel({ stepInput, ondoSymbol, chain, onComplete, onEdit, }: UseOndoAmountViewModelOptions): UseOndoAmountViewModelResult;
-type OndoAmountValidation = {
+ * the balance and Ondo's own token cap. There is no minimum - `minimumPurchaseUsd`
+ * is an offer's minimum *purchase* and frontline enforces no floor on a sell
+ * beyond a non-zero amount - and the USD caps are deliberately not converted,
+ * because doing it through a price that moves between the check and the build
+ * would reject fillable orders and pass unfillable ones.
+ */
+declare function useOndoSellAmountViewModel({ stepInput, ondoSymbol, chain, offer, enabled, onComplete, onEdit, }: UseOndoSellAmountViewModelOptions): UseOndoSellAmountViewModelResult;
+type OndoSellAmountValidation = {
     valid: true;
     amount: BlockchainAmount;
 } | {
@@ -3520,43 +4556,265 @@ type OndoAmountValidation = {
     error: string;
 };
 /**
- * The checks that can be made without asking the wallet for anything, in the
- * order a user would hit them: is it a number, is it more than nothing, can
- * they afford it, does the offer accept it, will Ondo fill it.
+ * The checks that can be made without asking the wallet for anything, in the
+ * order a user would hit them: is it a number, is it more than nothing, do they
+ * hold that much, will Ondo fill it.
+ *
+ * Shorter than the buy ladder by two rungs, and deliberately so. There is no
+ * offer minimum on a sell - `minimumPurchaseUsd` is a *purchase* minimum, and
+ * frontline enforces nothing below a non-zero amount - and Ondo's two USD caps
+ * are left to the server, because converting them into tokens needs a price
+ * that has moved by the time the order is built. What survives is
+ * `grossMaxTokens`, which is already in whole tokens and needs no conversion at
+ * all.
+ *
+ * Exported for the property tests: the ladder is money logic, and the property
+ * that matters (nothing above the balance or the cap is ever accepted) is about
+ * the whole ladder rather than any one rung.
+ */
+declare function validateSellAmount({ input, decimals, balance, symbol, tradingStatus, locale, }: {
+    input: string;
+    decimals: AssetDecimals;
+    /** `null` while no balance has been read; the check is then skipped. */
+    balance: bigint | null;
+    symbol: AssetSymbol;
+    tradingStatus: OndoTradingStatus | null;
+    locale: string;
+}): OndoSellAmountValidation;
+
+/**
+ * The state of the built sale a review step acts on.
+ *
+ * `isRefreshing` rides on `CONTENT` rather than replacing it, so a refresh in
+ * flight never blanks the numbers the user is reading. A refresh that fails
+ * keeps them too, and reports why alongside - the previous sale may still
+ * be good, and a failed refresh is fixed by refreshing again.
+ */
+type LoadOndoSellTransactionState = {
+    type: 'LOADING';
+} | {
+    type: 'ERROR';
+    reason: OndoLoadErrorReason;
+} | {
+    type: 'CONTENT';
+    transaction: OndoSellTransaction;
+    isRefreshing: boolean;
+    /** Why the last refresh failed; `null` when the sale is fresh. */
+    refreshError: OndoLoadErrorReason | null;
+};
+interface UseOndoSellTransactionOptions {
+    /**
+     * The order to build, or `null` while there is not one yet - before the
+     * amount step is confirmed. A `null` request fetches nothing.
+     */
+    request: BuildOndoSellParams | null;
+    /**
+     * A sale the caller already holds, typically the one `prepareSell`
+     * returned with the approval. When present the hook adopts it and skips the
+     * initial fetch; `refetch` still fetches. This is what keeps the flow to one
+     * attestation per order.
+     */
+    data?: OndoSellTransaction;
+    /** When false, the hook does not fetch. */
+    enabled: boolean;
+}
+interface UseOndoSellTransactionResult {
+    state: LoadOndoSellTransactionState;
+    /** Builds a fresh sale for the same order. Spends an attestation. */
+    refetch: () => void;
+}
+/**
+ * Holds the firm, expiring sale the sell review step places an order
+ * against, and rebuilds it on demand.
+ *
+ * **Never polls.** Building spends an attestation, so a new one is only ever
+ * obtained when the caller asks - on `refetch`, or on the first render if no
+ * `data` was supplied. That is also why an expired sale is left expired
+ * here: whether to replace it is the user's call, not a timer's.
+ *
+ * Disabled it fetches nothing and stays on whatever state it opened with. That
+ * is `LOADING` and not an empty `CONTENT` because there is no empty
+ * sale: firm calldata for an order that does not exist is not
+ * representable. A caller that switches this hook off should switch its own
+ * rendering off with it - which is what the review step does, since a step
+ * that is not active is `incomplete` and never reads this state at all.
+ *
+ * The sell half of the pair `useOndoBuyTransaction` opens - see there for why
+ * the two are not one hook. What differs is entirely in what `CONTENT` carries:
+ * an {@link OndoSellTransaction} publishes an expected outcome and a floor
+ * beneath it rather than one attested quantity, and the review step renders
+ * both.
+ */
+declare function useOndoSellTransaction(options: UseOndoSellTransactionOptions): UseOndoSellTransactionResult;
+
+type OndoSellReviewStepInput = {
+    type: 'incomplete';
+} | {
+    type: 'active';
+    /** The wallet that signs, sends the asset, and receives the proceeds. */
+    wallet: EvmWallet;
+    /** What the user is selling, in the asset's base units. */
+    amount: BlockchainAmount;
+    inputAsset: AssetSymbol;
+    /**
+     * The sale `prepareSell` already built for this order. Omitting it makes
+     * this step build one itself, which is the path a partner driving the
+     * review on its own takes - and the only way its `loading` and `error`
+     * states are reached.
+     */
+    transaction?: OndoSellTransaction;
+};
+interface UseOndoSellReviewViewModelOptions {
+    stepInput: OndoSellReviewStepInput;
+    /** Ondo's API symbol, e.g. `TSLAon`. Rebuilds the transaction. */
+    ondoSymbol: AssetSymbol;
+    /** The chain the order executes on. */
+    chain: EthereumChain;
+    /**
+     * When false, the step neither builds a transaction nor counts down, and
+     * neither refreshing the quote nor placing an order does anything. Defaults
+     * to true.
+     *
+     * The step being `incomplete` is not the same thing and does not stand in
+     * for it: a checkout switched off mid-flow leaves this step `active`, so the
+     * committed quote is still here to render and its clock would tick on behind
+     * a screen nobody is looking at.
+     */
+    enabled?: boolean;
+    /** Called once the swap has mined. */
+    /** Always a sell: this step only ever places one. */
+    onComplete: (order: OndoSellOrderPlaced) => void;
+}
+interface UseOndoSellReviewViewModelResult {
+    state: OndoSellReviewUiState;
+    onEvent: (event: OndoSellReviewUiEvent) => void;
+}
+/**
+ * Drives the review step of the Ondo sell checkout: what the sale comes to, how
+ * long the price holds, and placing it.
+ *
+ * The same shape as its buy counterpart, and the same reasoning about time: the
+ * quote is firm and short-lived, a quote inside
+ * {@link ONDO_QUOTE_EXPIRY_THRESHOLD_MS} of its deadline is treated as already
+ * gone, and refreshing is always something the user asks for because each
+ * refresh spends an attestation.
+ *
+ * What differs is what it reads off the transaction. A sale has no
+ * `notionalValue` and therefore no total to render; it publishes an expected
+ * outcome and a floor beneath it where the buy publishes one attested
+ * quantity; and its fee, if one ever lands, is denominated in the proceeds
+ * rather than in what was spent, and comes in two - one per outcome. Those
+ * facts are why this is a second viewmodel rather than a flag on the first,
+ * and why the endpoint behind it is a second endpoint.
+ */
+declare function useOndoSellReviewViewModel({ stepInput, ondoSymbol, chain, enabled, onComplete, }: UseOndoSellReviewViewModelOptions): UseOndoSellReviewViewModelResult;
+
+/**
+ * Which step is being filled in, carrying everything the ones before it
+ * settled.
+ *
+ * A union rather than a step index plus nullable fields: the amount step cannot
+ * run without a wallet, and the review step cannot run without a built
+ * transaction, so neither is representable here.
+ *
+ * The `wallet` arm is only ever entered when the host preselected nothing. A
+ * skipped wallet step is not a fourth arm: it is the flow *opening* on
+ * `amount`, which is why `wallets.preselected` is read once to seed the state
+ * and never again.
+ */
+type OndoSellStep = {
+    type: 'wallet';
+} | {
+    type: 'amount';
+    wallet: EvmWallet;
+} | {
+    type: 'review';
+    wallet: EvmWallet;
+    amount: BlockchainAmount;
+    inputAsset: AssetSymbol;
+    /** Built by `prepareSell` when the amount was confirmed. */
+    transaction: OndoSellTransaction;
+};
+interface UseOndoSellCheckoutViewModelOptions {
+    /**
+     * The offer being sold: names the asset and supplies its logo.
+     *
+     * Fixed for the lifetime of the hook — see the note on
+     * {@link useOndoSellCheckoutViewModel} about switching offers.
+     */
+    offer: OfferDetail;
+    /**
+     * Ondo's API symbol for the asset, e.g. `TSLAon`.
+     *
+     * Explicit rather than derived from `offer.asset.code`: Ondo's symbol tracks
+     * the underlying ticker and changes on a rebrand, and the two already
+     * disagree on Sepolia, where a mock asset stands in.
+     */
+    ondoSymbol: AssetSymbol;
+    /**
+     * The chain the order executes on: the balance read, the approval and the
+     * broadcast. Quotes are priced against Ondo production whatever this says,
+     * since Ondo runs no sandbox, so on a testnet the price is real and the
+     * money is not.
+     *
+     * Fixed for the lifetime of the hook, as `offer` is.
+     */
+    chain: EthereumChain;
+    /**
+     * The host's wallets, the lambdas that connect and disconnect one, and
+     * optionally the wallet it has already settled on.
+     *
+     * `wallets.preselected` is read **once**, to seed the step machine. A host
+     * that changes it mid-flow is ignored: the approval that follows the amount
+     * step is granted by one specific wallet, and moving the flow onto another
+     * one under it would strand that approval and build calldata the new wallet
+     * cannot broadcast.
+     */
+    wallets: CheckoutWalletSelection;
+    /**
+     * Default `true`. When `false` nothing is fetched and no timer runs, so the
+     * hook can be called unconditionally beside other providers' viewmodels.
+     */
+    enabled?: boolean;
+    /**
+     * Fired once the swap has mined. The confirmation dialog shows either way;
+     * this is for a host that wants to navigate, refresh a portfolio, or log.
+     */
+    onOrderConfirmed?: (order: OndoOrderPlaced) => void;
+}
+interface UseOndoSellCheckoutViewModelResult {
+    state: OndoSellCheckoutUiState;
+    onEvent: (event: OndoSellCheckoutUiEvent) => void;
+}
+/**
+ * Drives the whole Ondo sell checkout: the steps, the reference panel beside
+ * them, and the dialog that closes the flow.
  *
- * Exported for the property tests: the ladder is money logic, and the property
- * that matters (nothing above the balance or the caps is ever accepted) is
- * about the whole ladder rather than any one rung.
- */
-declare function validateAmount({ input, decimals, balance, symbol, minimumPurchaseUsd, tradingStatus, locale, }: {
-    input: string;
-    decimals: AssetDecimals;
-    /** `null` while no balance has been read; the check is then skipped. */
-    balance: bigint | null;
-    symbol: AssetSymbol;
-    minimumPurchaseUsd: number | null;
-    tradingStatus: OndoTradingStatus | null;
-    locale: string;
-}): OndoAmountValidation;
-
-/**
- * Why an Ondo read failed, in the only two flavours a UI acts on differently.
+ * It owns the step machine and the two polls; each step's own viewmodel owns
+ * its screen. The polls live here because they are shared - the sidebar shows
+ * the price and the amount step gates on the market - and because the price is
+ * sized by whatever the flow has settled on so far.
  *
- * `not-authenticated` is split out because no retry helps until the user signs
- * in, and because the remedy is one the UI can name. Everything else collapses
- * into `generic-error` and is offered a retry.
+ * The sell price poll is what names the asset being sold. `TOKEN_REGISTRY`
+ * knows the stablecoins swaps are funded with and no provider's asset, so the
+ * contract address the balance is read on and the approval is granted for, and
+ * the decimals the typed amount is parsed at, both come off that quote and
+ * nowhere else.
  *
- * That is a deliberate over-offer, not a claim that every such failure is
- * retryable. A `ValidationError` from the DTO boundary - an unreadable expiry,
- * a zero output amount, a scale no amount could be denominated in - is
- * deterministic, and refreshing spends an attestation to fail again. It stays
- * lumped in because each one means frontline changed its encoding, which is
- * unreachable in a deployed pair and not worth a public union member and a
- * branch in every consumer to distinguish. Split it out if that stops being
- * true.
+ * There is no flow-level error state. Every failure belongs to a region: a
+ * price that will not load leaves the panel's corner unavailable, and an order
+ * that will not go through is reported on the review step, next to the button
+ * that caused it.
+ *
+ * `offer` and `chain` are read as fixed for the lifetime of the hook, and so is
+ * the wallet the flow opened on. The step machine holds a committed quote and
+ * an approval granted on one chain by one wallet for one order, so changing any
+ * of them in place would carry them onto an order they were never priced for.
+ * Remount instead: give the component holding this hook a `key` that changes
+ * with the offer, the chain and the side, as {@link CheckoutContainer}
+ * documents.
  */
-type OndoLoadErrorReason = 'not-authenticated' | 'generic-error';
-declare function ondoLoadErrorReason(error: unknown): OndoLoadErrorReason;
+declare function useOndoSellCheckoutViewModel({ offer, ondoSymbol, chain, wallets, enabled, onOrderConfirmed, }: UseOndoSellCheckoutViewModelOptions): UseOndoSellCheckoutViewModelResult;
 
 /**
  * The state of the indicative-price poll.
@@ -3615,7 +4873,8 @@ interface UseOndoPriceResult {
  *
  * Free to poll: this quote spends no attestation and commits nothing, which is
  * why it may run while the user is still deciding. It also cannot be executed
- * - committing a fillable quote is `coinlist.ondo.prepareSwap`.
+ * - committing a fillable quote is `coinlist.ondo.prepareBuy` or
+ *   `coinlist.ondo.prepareSell`, whichever way the trade runs.
  *
  * Disabled (or before the provider is ready) it neither fetches nor holds a
  * timer, and stays on whatever state it opened with - `LOADING`, or the `data`
@@ -3730,94 +4989,6 @@ interface UseOndoSidebarViewModelResult {
  */
 declare function useOndoSidebarViewModel({ offer, ondoSymbol, chain, priceState, tradingStatusState, }: UseOndoSidebarViewModelOptions): UseOndoSidebarViewModelResult;
 
-/**
- * Which step is being filled in, carrying everything the ones before it
- * settled.
- *
- * A union rather than a step index plus nullable fields: the amount step
- * cannot run without a wallet, and the review step cannot run without a built
- * transaction, so neither is representable here.
- */
-type OndoBuyStep = {
-    type: 'wallet';
-} | {
-    type: 'amount';
-    wallet: EvmWallet;
-} | {
-    type: 'review';
-    wallet: EvmWallet;
-    amount: BlockchainAmount;
-    inputAsset: StablecoinSymbol;
-    /** Built by `prepareSwap` when the amount was confirmed. */
-    transaction: OndoSwapTransaction;
-};
-interface UseOndoBuyCheckoutViewModelOptions {
-    /**
-     * The offer being bought: names the asset and supplies its logo.
-     *
-     * Fixed for the lifetime of the hook — see the note on
-     * {@link useOndoBuyCheckoutViewModel} about switching offers.
-     */
-    offer: OfferDetail;
-    /**
-     * Ondo's API symbol for the asset, e.g. `AAPLon`.
-     *
-     * Explicit rather than derived from `offer.asset.code`: Ondo's symbol tracks
-     * the underlying ticker and changes on a rebrand, and the two already
-     * disagree on Sepolia, where a mock asset stands in.
-     */
-    ondoSymbol: AssetSymbol;
-    /**
-     * The chain the order executes on: the balance read, the approval and the
-     * broadcast. Quotes are priced against Ondo production whatever this says,
-     * since Ondo runs no sandbox, so on a testnet the price is real and the
-     * money is not.
-     *
-     * Fixed for the lifetime of the hook, as `offer` is.
-     */
-    chain: EthereumChain;
-    /** The host's wallets, and the lambdas that connect and disconnect one. */
-    wallets: CheckoutWalletSelection;
-    /**
-     * Default `true`. When `false` nothing is fetched and no timer runs, so the
-     * hook can be called unconditionally beside other providers' viewmodels.
-     */
-    enabled?: boolean;
-    /**
-     * Fired once the swap has mined. The confirmation dialog shows either way;
-     * this is for a host that wants to navigate, refresh a portfolio, or log.
-     */
-    onOrderConfirmed?: (order: OndoOrderPlaced) => void;
-}
-interface UseOndoBuyCheckoutViewModelResult {
-    state: OndoBuyCheckoutUiState;
-    onEvent: (event: OndoBuyCheckoutUiEvent) => void;
-}
-/**
- * Drives the whole Ondo buy checkout: the three steps, the reference panel
- * beside them, and the dialog that closes the flow.
- *
- * It owns the step machine and the two polls; each step's own viewmodel owns
- * its screen. The polls live here because they are shared - the sidebar shows
- * the price and the amount step gates on the market - and because the price is
- * sized by whatever the flow has settled on so far.
- *
- * There is no flow-level error state. Every failure belongs to a region: a
- * price that will not load leaves the panel's corner unavailable, and an order
- * that will not go through is reported on the review step, next to the button
- * that caused it.
- *
- * `offer` and `chain` are read as fixed for the lifetime of the hook. The step
- * machine holds a committed quote and an approval granted on one chain for one
- * order, so changing either in place would carry them onto an order they were
- * never priced for. Remount instead: give the component holding this hook a
- * `key` that changes with the offer and the chain, as {@link CheckoutContainer}
- * documents. That discards the flow with its component instance, which is the
- * only reset that cannot land between an approval and the broadcast it was
- * granted for.
- */
-declare function useOndoBuyCheckoutViewModel({ offer, ondoSymbol, chain, wallets, enabled, onOrderConfirmed, }: UseOndoBuyCheckoutViewModelOptions): UseOndoBuyCheckoutViewModelResult;
-
 /**
  * Whether step 1 is being filled in or already answered.
  *
@@ -3861,70 +5032,6 @@ interface UseOndoWalletSelectViewModelResult {
  */
 declare function useOndoWalletSelectViewModel({ stepInput, wallets, chain, onComplete, onEdit, }: UseOndoWalletSelectViewModelOptions): UseOndoWalletSelectViewModelResult;
 
-/**
- * The state of the built transaction a review step acts on.
- *
- * `isRefreshing` rides on `CONTENT` rather than replacing it, so a refresh in
- * flight never blanks the numbers the user is reading. A refresh that fails
- * keeps them too, and reports why alongside - the previous transaction may
- * still be good, and a failed refresh is fixed by refreshing again.
- */
-type LoadOndoSwapTransactionState = {
-    type: 'LOADING';
-} | {
-    type: 'ERROR';
-    reason: OndoLoadErrorReason;
-} | {
-    type: 'CONTENT';
-    transaction: OndoSwapTransaction;
-    isRefreshing: boolean;
-    /** Why the last refresh failed; `null` when the transaction is fresh. */
-    refreshError: OndoLoadErrorReason | null;
-};
-interface UseOndoSwapTransactionOptions {
-    /**
-     * The order to build, or `null` while there is not one yet - before the
-     * amount step is confirmed. A `null` request fetches nothing.
-     */
-    request: BuildOndoSwapTransactionParams | null;
-    /**
-     * A transaction the caller already holds, typically the one `prepareSwap`
-     * returned with the approval. When present the hook adopts it and skips the
-     * initial fetch; `refetch` still fetches. This is what keeps the flow to one
-     * attestation per order.
-     */
-    data?: OndoSwapTransaction;
-    /** When false, the hook does not fetch. */
-    enabled: boolean;
-}
-interface UseOndoSwapTransactionResult {
-    state: LoadOndoSwapTransactionState;
-    /** Builds a fresh transaction for the same order. Spends an attestation. */
-    refetch: () => void;
-}
-/**
- * Holds the firm, expiring transaction a review step places an order against,
- * and rebuilds it on demand.
- *
- * **Never polls.** Building spends an attestation, so a new one is only ever
- * obtained when the caller asks - on `refetch`, or on the first render if no
- * `data` was supplied. That is also why an expired transaction is left expired
- * here: whether to replace it is the user's call, not a timer's.
- *
- * Disabled it fetches nothing and stays on whatever state it opened with. That
- * is `LOADING` and not an empty `CONTENT` because there is no empty
- * transaction: firm calldata for an order that does not exist is not
- * representable. A caller that switches this hook off should switch its own
- * rendering off with it - which is what the review step does, since a step
- * that is not active is `incomplete` and never reads this state at all.
- *
- * Buy-only, like the endpoint behind it - the funding token goes in and the
- * asset comes out, both resolved from the offer. It sits beside the two
- * side-parameterised polls rather than under `buy/` because a sell will reach
- * for the same seam, and moving it then is cheaper than forking it now.
- */
-declare function useOndoSwapTransaction(options: UseOndoSwapTransactionOptions): UseOndoSwapTransactionResult;
-
 /** How much the user is spending, and what they are spending it in. */
 type SuperstateAmountConfirmed = {
     amount: BlockchainAmount;
@@ -4394,6 +5501,62 @@ interface UseRequirementsChecklistViewModelResult {
  */
 declare function useRequirementsChecklistViewModel(options: UseRequirementsChecklistViewModelOptions): UseRequirementsChecklistViewModelResult;
 
+/**
+ * A display-ready connect-wallet error: the core flow's machine-readable code
+ * and `retryable` flag, plus copy for the UI.
+ */
+type ConnectWalletError = {
+    code: ConnectWalletErrorCode;
+    message: string;
+    retryable: boolean;
+};
+/**
+ * Signing-in-flight and the last sign error live inside the READY state (not a
+ * separate top-level state) so a failed attempt returns to READY and can be
+ * retried without re-opening the modal. Mirrors {@link SignState} in
+ * `useTaxDocument`.
+ */
+type ConnectWalletSignState = {
+    type: 'idle';
+    error: ConnectWalletError | null;
+} | {
+    type: 'signing';
+};
+type ConnectWalletState = {
+    type: 'NEEDS_WALLET';
+} | {
+    type: 'READY';
+    address: EvmWalletAddress;
+    sign: ConnectWalletSignState;
+} | {
+    type: 'CONNECTED';
+    binding: OfferOptionAddress;
+};
+interface UseConnectWalletOptions {
+    /** The hook resets state each time it opens. */
+    isOpen: boolean;
+    offerId: OfferId;
+    offerOptionId: OfferOptionId;
+    /** Host-provided connected wallet, or `null` while none is connected. */
+    wallet: ConnectWallet | null;
+    /** Challenge framing; defaults to `'siwe'`. */
+    challengeType?: WalletChallengeType;
+    /** SIWE statement shown in the signing prompt. */
+    statement?: string;
+}
+interface UseConnectWalletResult {
+    state: ConnectWalletState;
+    /** READY.sign: idle -> signing -> (CONNECTED | idle w/ error). No-op otherwise. */
+    onSign: () => void;
+}
+/**
+ * React wrapper over {@link connectExternalWalletFlow}. Owns the modal state
+ * machine, the display copy, and generation-token supersession (so a wallet
+ * switch, modal close, or unmount cancels an in-flight attempt). The flow logic
+ * itself lives in the framework-free core so non-React consumers can drive it.
+ */
+declare function useConnectWallet({ isOpen, offerId, offerOptionId, wallet, challengeType, statement, }: UseConnectWalletOptions): UseConnectWalletResult;
+
 type KycTokenErrorReason = 'not-authenticated' | 'generic-error';
 type KycTokenState = {
     type: 'IDLE';
@@ -4630,6 +5793,56 @@ interface UseConnectWalletModalViewModelResult {
  */
 declare function useConnectWalletModalViewModel({ isOpen, onClose, offerId, optionId, wallet, onConnected, onRequestConnect, challengeType, statement, }: UseConnectWalletModalViewModelOptions): UseConnectWalletModalViewModelResult;
 
+interface UseErc20BalanceOptions {
+    /**
+     * The token to read, by contract address.
+     *
+     * `null` when the caller does not know it yet, which fetches nothing. That is
+     * the normal state for a token the SDK ships no registry entry for: an Ondo
+     * asset's address arrives with its quote, so a sell screen renders before it
+     * has one.
+     */
+    tokenAddress: EvmContractAddress | null;
+    owner: EvmWalletAddress;
+    chain: EthereumChain;
+    /** How often to refresh. Defaults to {@link ERC20_BALANCE_POLL_INTERVAL_MS}. */
+    pollIntervalMs?: number;
+    /** When false, the hook neither fetches nor polls. */
+    enabled: boolean;
+}
+interface UseErc20BalanceResult {
+    /**
+     * Raw base units of the token currently named by the options, or `null`.
+     *
+     * `null` covers every state that is not a settled read of *this* request:
+     * before the first one settles, after one fails, while disabled, and from
+     * the moment the token, owner or chain changes until the read for the new
+     * one lands. A caller cannot tell those apart on purpose - none of them is a
+     * number to size an order against - and `isLoading` is what says whether to
+     * wait.
+     */
+    balance: bigint | null;
+    isLoading: boolean;
+}
+/**
+ * Polls one wallet's balance of one ERC-20, named by contract address.
+ *
+ * The address-keyed counterpart to `useErc20TokenBalances`, which reads a list
+ * of tokens by symbol through `TOKEN_REGISTRY`. That registry knows the
+ * stablecoins the SDK funds swaps with and nothing else, so a token whose
+ * address arrives at runtime - a provider's asset, resolved from a quote - has
+ * no symbol to look up and needs this instead. Two hooks rather than one
+ * widened hook: the plural one exists to read a *set* concurrently and settle
+ * each independently, which is a different job from following a single token
+ * whose address may not be known yet.
+ *
+ * A poll tick is skipped while the previous read is in flight, so a slow one
+ * cannot resolve last and overwrite a fresher balance. `isLoading` is true only
+ * until the first read settles; background polls do not toggle it. Disabled, or
+ * with no `tokenAddress`, it neither fetches nor holds a timer.
+ */
+declare function useErc20Balance(options: UseErc20BalanceOptions): UseErc20BalanceResult;
+
 /**
  * How often balances refresh when the caller names no interval. Matches the
  * cadence the checkout flows poll everything else at, and is slow enough that
@@ -4652,8 +5865,10 @@ interface UseErc20TokenBalancesOptions {
 interface UseErc20TokenBalancesResult {
     /**
      * Raw on-chain balances keyed by the requested assets. Each requested asset
-     * has an entry once a fetch settles (`bigint` on success, `null` on failure).
-     * Assets that were not requested are absent.
+     * with a deployment on the chain has an entry once a fetch settles
+     * (`bigint` on success, `null` on a failed read). Assets the chain has no
+     * deployment for (e.g. USDT on Base Sepolia) are omitted entirely, so
+     * absence and failure stay tellable apart.
      */
     balances: Map<StablecoinSymbol, bigint | null>;
     isLoading: boolean;
@@ -4661,9 +5876,11 @@ interface UseErc20TokenBalancesResult {
 /**
  * Polls the raw ERC-20 balances of `assets` for `address`, refreshing every
  * `pollIntervalMs`. Each asset settles independently: a failed read maps to
- * `null` while the others still resolve. A poll tick is skipped while the
- * previous fetch is still in flight. `assets` is compared by contents, so
- * passing an inline array does not restart the poll.
+ * `null` while the others still resolve, and an asset the chain has no
+ * deployment for is omitted from the result rather than read at a fake
+ * address. A poll tick is skipped while the previous fetch is still in
+ * flight. `assets` is compared by contents, so passing an inline array does
+ * not restart the poll.
  *
  * `isLoading` is true only until the first poll settles; background polls do
  * not toggle it. Disabled (or before the provider is ready) the hook does not
@@ -4835,6 +6052,19 @@ declare function formatMonthYear(date: Date, locale: string): string;
  * not a substitute — it renders one unit ("in 2 days"), not two.
  */
 declare function formatCountdown(totalSeconds: number): string;
+/**
+ * Live-sale chrome countdown, e.g. `3D 19H 42M`.
+ *
+ * Always three uppercase units and no seconds, matching Clay's sale card.
+ * Distinct from {@link formatCountdown}, which stays two mixed-case units for
+ * checkout sidebars.
+ *
+ * A positive remainder under a minute clamps to `0D 0H 1M`: the card shows the
+ * live dot next to this string, and a live sale reading `0D 0H 0M` would
+ * contradict the dot. That all-zero string is reserved for `ended` — and the
+ * status label for that never calls this function.
+ */
+declare function formatSaleCardCountdown(totalSeconds: number): string;
 
 interface UseCountdownOptions {
     /**
@@ -4877,4 +6107,4 @@ interface UseCountdownOptions {
  */
 declare function useCountdown({ until, tickMs, enabled, }: UseCountdownOptions): number | null;
 
-export { type AuthState, type AuthorizeWalletParams, type BroadcastTxParams, ChecklistStatus, CheckoutAssetUi, type CheckoutConfig, type CheckoutConfirmedWalletUi, CheckoutContainer, type CheckoutContainerProps, type CheckoutCtaUi, type CheckoutEmbeddedWalletUi, type CheckoutNetworkUi, type CheckoutSelectableInputAssetUi, type CheckoutStatusUi, type CheckoutWalletSelection, type CheckoutWalletTypeUi, type CheckoutWalletUi, type ClientAuthConfig, type ClientAuthNamespace, ClientAuthNamespaceImpl, type ClientAuthSession, type ClientCoinListTokenSaleNamespace, ClientCoinListTokenSaleNamespaceImpl, type ClientConfig, type ClientOndoNamespace, ClientOndoNamespaceImpl, type ClientRequirementsNamespace, ClientRequirementsNamespaceImpl, type ClientSuperstateSwapNamespace, ClientSuperstateSwapNamespaceImpl, type ClientSupportNamespace, ClientSupportNamespaceImpl, type CoinListClient, CoinListClientInitializationError, CoinListContext, CoinListContextProvider, type CoinListContextValue, CoinListProvider, type CoinListProviderProps, CoinListSignInButton, CoinListSignInCardContainer, type CoinListSignInCardContainerProps, type CoinListSignInCardUiEvent, type CoinListSignInCardUiState, CoinListSignInCardView, type CoinListSignInCardViewProps, CoinListStyleScope, type CoinListStyleScopeProps, type CoinListTokenSaleCheckoutConfig, type CompleteOAuthFailureReason, type ConnectWallet, type ConnectWalletError, type ConnectWalletErrorCode, type ConnectWalletFlowError, type ConnectWalletFlowParams, type ConnectWalletFlowResult, ConnectWalletModalContainer, type ConnectWalletModalContainerProps, type ConnectWalletModalUiEvent, type ConnectWalletModalUiState, ConnectWalletModalView, type ConnectWalletModalViewProps, type ConnectWalletPhase, type ConnectWalletScreenUi, type ConnectWalletSignState, type ConnectWalletState, ConnectedWalletList, type ConnectedWalletListProps, type ConnectedWalletUi, ERC20_BALANCE_POLL_INTERVAL_MS, type Erc20AllowanceError, type Erc20AllowancePhase, type Erc20AllowanceResult, type Erc20ApprovalError, type EvmSigner, type EvmWallet, type ExecuteOndoSwapParams, type ExecuteSwapParams, type ExecuteTokenSaleParams, IdentityVerificationContainer, type IdentityVerificationContainerProps, type IdentityVerificationUiEvent, type IdentityVerificationUiState, IdentityVerificationView, type IdentityVerificationViewProps, KycLevelName, type KycTokenErrorReason, type KycTokenState, type LoadOfferDetailsReason, type LoadOfferDetailsState, type LoadOffersReason, type LoadOffersState, type LoadOndoPriceState, type LoadOndoSwapTransactionState, type LoadOndoTradingStatusState, type LoadOptionAddressesReason, type LoadOptionAddressesState, type LoadParticipationsReason, type LoadParticipationsState, type LoadRequirementsReason, type LoadRequirementsState, type LoadTokenMetadataState, OAUTH_CODE_VERIFIER_KEY, OAUTH_STATE_KEY, type OauthClientErrorReason, type OauthClientResult, OfferCard, type Props as OfferCardProps, OfferCardUi, OffersGridContainer, type OffersGridContainerProps, type OffersGridUiEvent, type OffersGridUiState, OffersGridView, type OffersGridViewProps, type OndoAmountConfirmed, type OndoAmountStepInput, type OndoAmountUiEvent, type OndoAmountUiState, type OndoAmountValidation, OndoAmountView, type OndoAmountViewProps, OndoBuyCheckoutContainer, type OndoBuyCheckoutContainerProps, type OndoBuyCheckoutUiEvent, type OndoBuyCheckoutUiState, OndoBuyCheckoutView, type OndoBuyCheckoutViewProps, type OndoBuyStep, type OndoCheckoutConfig, type OndoLoadErrorReason, OndoOrderConfirmed, type OndoOrderConfirmedProps, type OndoOrderConfirmedUiEvent, type OndoOrderConfirmedUiState, type OndoOrderPlaced, type OndoQuoteStatusUi, type OndoReviewStepInput, type OndoReviewUiEvent, type OndoReviewUiState, OndoReviewView, type OndoReviewViewProps, type OndoSidebarPriceUi, type OndoSidebarUiState, OndoSidebarView, type OndoSidebarViewProps, type OndoSwapExecutionError, type OndoSwapExecutionPhase, type OndoSwapExecutionResult, type OndoSwapPreparationError, type OndoSwapPreparationPhase, type OndoSwapPreparationResult, type OndoWalletSelectStepInput, type OndoWalletSelectUiEvent, type OndoWalletSelectUiState, OndoWalletSelectView, type OndoWalletSelectViewProps, type PrepareOndoSwapParams, type RequiredCheckoutConfig, RequirementItem, type RequirementItemProps, RequirementItemUi, RequirementStatus, RequirementVariant, RequirementsChecklistContainer, type RequirementsChecklistContainerProps, type RequirementsChecklistItemUi, type RequirementsChecklistUiEvent, type RequirementsChecklistUiState, RequirementsChecklistView, type RequirementsChecklistViewProps, type RequirementsData, type RequirementsVerificationUi, type SignState, SlippagePicker, type SlippagePickerProps, type SubmitErc20ApprovalResult, type SuperstateAmountConfirmed, type SuperstateAmountStepInput, type SuperstateAmountUiEvent, type SuperstateAmountUiState, type SuperstateAmountValidation, SuperstateAmountView, type SuperstateAmountViewProps, type SuperstateCheckoutConfig, SuperstateOrderConfirmed, type SuperstateOrderConfirmedProps, type SuperstateOrderConfirmedUiEvent, type SuperstateOrderConfirmedUiState, type SuperstateOrderPlaced, type SuperstateReviewStepInput, type SuperstateReviewUiEvent, type SuperstateReviewUiState, SuperstateReviewView, type SuperstateReviewViewProps, type SuperstateSidebarPriceUi, type SuperstateSidebarUiState, SuperstateSidebarView, type SuperstateSidebarViewProps, type SuperstateSlippageOptionUi, type SuperstateSlippageUi, SuperstateSwapCheckoutContainer, type SuperstateSwapCheckoutContainerProps, type SuperstateSwapCheckoutRetryUiEvent, type SuperstateSwapCheckoutUiEvent, type SuperstateSwapCheckoutUiState, SuperstateSwapCheckoutView, type SuperstateSwapCheckoutViewProps, type SuperstateSwapLoadErrorReason, type SuperstateSwapStep, type SuperstateWalletStepInput, type SuperstateWalletUiEvent, type SuperstateWalletUiState, SuperstateWalletView, type SuperstateWalletViewProps, type SwapExecutionError, type SwapExecutionPhase, type SwapExecutionResult, type SwapOutputTokenState, type TaxDocumentAddressParts, type TaxDocumentFieldUi, type TaxDocumentFields, TaxDocumentModalContainer, type TaxDocumentModalContainerProps, type TaxDocumentModalUiEvent, type TaxDocumentModalUiState, TaxDocumentModalView, type TaxDocumentModalViewProps, type TaxDocumentScreenUi, type TaxDocumentState, type TokenSaleExecutionError, type TokenSaleExecutionPhase, type TokenSaleExecutionResult, USDC_ICON_URL, USDT_ICON_URL, type UseCoinListResult, type UseCoinListSignInCardViewModelOptions, type UseCoinListSignInCardViewModelResult, type UseCompleteOAuthOptions, type UseConnectWalletModalViewModelOptions, type UseConnectWalletModalViewModelResult, type UseConnectWalletOptions, type UseConnectWalletResult, type UseCountdownOptions, type UseErc20TokenBalancesOptions, type UseErc20TokenBalancesResult, type UseIdentityVerificationViewModelOptions, type UseIdentityVerificationViewModelResult, type UseKycTokenResult, type UseOfferDetailsOptions, type UseOfferDetailsResult, type UseOffersGridViewModelOptions, type UseOffersGridViewModelResult, type UseOffersOptions, type UseOffersResult, type UseOndoAmountViewModelOptions, type UseOndoAmountViewModelResult, type UseOndoBuyCheckoutViewModelOptions, type UseOndoBuyCheckoutViewModelResult, type UseOndoPriceOptions, type UseOndoPriceResult, type UseOndoReviewViewModelOptions, type UseOndoReviewViewModelResult, type UseOndoSidebarViewModelOptions, type UseOndoSidebarViewModelResult, type UseOndoSwapTransactionOptions, type UseOndoSwapTransactionResult, type UseOndoTradingStatusOptions, type UseOndoTradingStatusResult, type UseOndoWalletSelectViewModelOptions, type UseOndoWalletSelectViewModelResult, type UseOptionAddressesOptions, type UseOptionAddressesResult, type UseParticipationsOptions, type UseParticipationsResult, type UseRequirementsChecklistViewModelOptions, type UseRequirementsChecklistViewModelResult, type UseRequirementsOptions, type UseRequirementsResult, type UseSuperstateAmountViewModelOptions, type UseSuperstateAmountViewModelResult, type UseSuperstateReviewViewModelOptions, type UseSuperstateReviewViewModelResult, type UseSuperstateSidebarViewModelOptions, type UseSuperstateSidebarViewModelResult, type UseSuperstateSwapCheckoutViewModelOptions, type UseSuperstateSwapCheckoutViewModelResult, type UseSuperstateWalletViewModelOptions, type UseSuperstateWalletViewModelResult, type UseSwapOutputTokenOptions, type UseSwapOutputTokenResult, type UseSwapQuoteOptions, type UseSwapQuoteResult, type UseTaxDocumentModalViewModelOptions, type UseTaxDocumentModalViewModelResult, type UseTaxDocumentOptions, type UseTaxDocumentResult, type UseTokenMetadataOptions, type UseTokenMetadataResult, VerificationOverlay, type VerificationOverlayProps, type WalletAuthorizationError, type WalletAuthorizationPhase, type WalletAuthorizationResult, type WalletError, type WalletsStatus, type WriteContractParams, authorizeWallet, classifyWalletError, connectExternalWalletFlow, createCoinListClient, defaultCheckoutConfig, ensureErc20Allowance, executeOndoSwap, executeSwap, executeTokenSale, formatCountdown, formatMonthYear, offerIconUrl, ondoLoadErrorReason, prepareOndoSwap, quoteIsStale, quoteOverAsks, stablecoinIconUrl, submitErc20Approval, useCoinList, useCoinListSignInCardViewModel, useCompleteOAuth, useConnectWallet, useConnectWalletModalViewModel, useCountdown, useErc20TokenBalances, useIdentityVerificationViewModel, useKycToken, useOfferDetails, useOffers, useOffersGridViewModel, useOndoAmountViewModel, useOndoBuyCheckoutViewModel, useOndoPrice, useOndoReviewViewModel, useOndoSidebarViewModel, useOndoSwapTransaction, useOndoTradingStatus, useOndoWalletSelectViewModel, useOptionAddresses, useParticipations, useRequirements, useRequirementsChecklistViewModel, useSuperstateAmountViewModel, useSuperstateReviewViewModel, useSuperstateSidebarViewModel, useSuperstateSwapCheckoutViewModel, useSuperstateWalletViewModel, useSwapOutputToken, useSwapQuote, useTaxDocument, useTaxDocumentModalViewModel, useTokenMetadata, validateAmount, validateSuperstateAmount };
+export { type AuthState, type AuthorizeWalletParams, ChecklistStatus, CheckoutAssetUi, type CheckoutConfig, type CheckoutConfirmedWalletUi, CheckoutContainer, type CheckoutContainerProps, type CheckoutCtaUi, type CheckoutEmbeddedWalletUi, type CheckoutNetworkUi, type CheckoutSelectableInputAssetUi, type CheckoutStatusUi, type CheckoutWalletSelection, type CheckoutWalletTypeUi, type CheckoutWalletUi, type ClientAuthConfig, type ClientAuthNamespace, ClientAuthNamespaceImpl, type ClientAuthSession, type ClientCoinListTokenSaleNamespace, ClientCoinListTokenSaleNamespaceImpl, type ClientConfig, type ClientOndoNamespace, ClientOndoNamespaceImpl, type ClientRequirementsNamespace, ClientRequirementsNamespaceImpl, type ClientSuperstateSwapNamespace, ClientSuperstateSwapNamespaceImpl, type ClientSupportNamespace, ClientSupportNamespaceImpl, type CoinListClient, CoinListClientInitializationError, CoinListContext, CoinListContextProvider, type CoinListContextValue, CoinListProvider, type CoinListProviderProps, CoinListSignInButton, CoinListSignInCardContainer, type CoinListSignInCardContainerProps, type CoinListSignInCardUiEvent, type CoinListSignInCardUiState, CoinListSignInCardView, type CoinListSignInCardViewProps, CoinListStyleScope, type CoinListStyleScopeProps, type CoinListTokenSaleCheckoutConfig, type CompleteOAuthFailureReason, ConnectWallet, type ConnectWalletError, type ConnectWalletErrorCode, type ConnectWalletFlowError, type ConnectWalletFlowParams, type ConnectWalletFlowResult, ConnectWalletModalContainer, type ConnectWalletModalContainerProps, type ConnectWalletModalUiEvent, type ConnectWalletModalUiState, ConnectWalletModalView, type ConnectWalletModalViewProps, type ConnectWalletPhase, type ConnectWalletScreenUi, type ConnectWalletSignState, type ConnectWalletState, ConnectedWalletList, type ConnectedWalletListProps, type ConnectedWalletUi, ERC20_BALANCE_POLL_INTERVAL_MS, type Erc20AllowanceError, type Erc20AllowancePhase, type Erc20AllowanceResult, type Erc20ApprovalError, EvmWallet, type ExecuteOndoSwapParams, type ExecuteSwapParams, type ExecuteTokenSaleParams, IdentityVerificationContainer, type IdentityVerificationContainerProps, type IdentityVerificationUiEvent, type IdentityVerificationUiState, IdentityVerificationView, type IdentityVerificationViewProps, KycLevelName, type KycTokenErrorReason, type KycTokenState, type LoadOfferDetailsReason, type LoadOfferDetailsState, type LoadOffersReason, type LoadOffersState, type LoadOndoBuyTransactionState, type LoadOndoPriceState, type LoadOndoSellTransactionState, type LoadOndoTradingStatusState, type LoadOptionAddressesReason, type LoadOptionAddressesState, type LoadParticipationsReason, type LoadParticipationsState, type LoadRequirementsReason, type LoadRequirementsState, type LoadTokenMetadataState, Logger, OAUTH_CODE_VERIFIER_KEY, OAUTH_STATE_KEY, type OauthClientErrorReason, type OauthClientResult, OfferAssetCard, type OfferAssetCardProps, OfferAssetCardUi, OfferSaleCard, type OfferSaleCardProps, OfferSaleCardUi, OffersAssetGrid, type OffersAssetGridProps, OffersGridContainer, type OffersGridContainerProps, type OffersGridUiEvent, type OffersGridUiState, OffersGridView, type OffersGridViewProps, type OndoBuyAmountConfirmed, type OndoBuyAmountStepInput, type OndoBuyAmountUiEvent, type OndoBuyAmountUiState, type OndoBuyAmountValidation, OndoBuyAmountView, type OndoBuyAmountViewProps, OndoBuyCheckoutContainer, type OndoBuyCheckoutContainerProps, type OndoBuyCheckoutUiEvent, type OndoBuyCheckoutUiState, OndoBuyCheckoutView, type OndoBuyCheckoutViewProps, type OndoBuyExecutionResult, OndoBuyOrderConfirmed, type OndoBuyOrderPlaced, type OndoBuyOrderTerms, type OndoBuyPreparationResult, type OndoBuyQuoteStatusUi, type OndoBuyReviewStepInput, type OndoBuyReviewUiEvent, type OndoBuyReviewUiState, OndoBuyReviewView, type OndoBuyReviewViewProps, type OndoBuyStep, type OndoCheckoutConfig, type OndoLoadErrorReason, type OndoOrderConfirmedProps, type OndoOrderConfirmedUiEvent, type OndoOrderConfirmedUiState, type OndoOrderPlaced, type OndoOrderPlacedCore, type OndoSellAmountConfirmed, type OndoSellAmountStepInput, type OndoSellAmountUiEvent, type OndoSellAmountUiState, type OndoSellAmountValidation, OndoSellAmountView, type OndoSellAmountViewProps, type OndoSellAsset, type OndoSellBalanceUi, OndoSellCheckoutContainer, type OndoSellCheckoutContainerProps, type OndoSellCheckoutUiEvent, type OndoSellCheckoutUiState, OndoSellCheckoutView, type OndoSellCheckoutViewProps, type OndoSellExecutionResult, OndoSellOrderConfirmed, type OndoSellOrderConfirmedProps, type OndoSellOrderConfirmedUiEvent, type OndoSellOrderConfirmedUiState, type OndoSellOrderPlaced, type OndoSellOrderTerms, type OndoSellOutcomeUi, type OndoSellPreparationResult, type OndoSellQuoteStatusUi, type OndoSellReviewStepInput, type OndoSellReviewUiEvent, type OndoSellReviewUiState, OndoSellReviewView, type OndoSellReviewViewProps, type OndoSellSourceWalletUi, type OndoSellStep, type OndoSidebarPriceUi, type OndoSidebarUiState, OndoSidebarView, type OndoSidebarViewProps, type OndoSwapExecutionError, type OndoSwapExecutionPhase, type OndoSwapExecutionResult, type OndoSwapPreparationError, type OndoSwapPreparationPhase, type OndoSwapPreparationResult, type OndoWalletSelectStepInput, type OndoWalletSelectUiEvent, type OndoWalletSelectUiState, OndoWalletSelectView, type OndoWalletSelectViewProps, PinoLoggerOptions, type PrepareOndoBuyParams, type PrepareOndoSellParams, type PrepareOndoSwapParamsCore, type RequiredCheckoutConfig, RequirementItem, type RequirementItemProps, RequirementItemUi, RequirementStatus, RequirementVariant, RequirementsChecklistContainer, type RequirementsChecklistContainerProps, type RequirementsChecklistItemUi, type RequirementsChecklistUiEvent, type RequirementsChecklistUiState, RequirementsChecklistView, type RequirementsChecklistViewProps, type RequirementsData, type RequirementsVerificationUi, type SignState, SlippagePicker, type SlippagePickerProps, type SubmitErc20ApprovalResult, type SuperstateAmountConfirmed, type SuperstateAmountStepInput, type SuperstateAmountUiEvent, type SuperstateAmountUiState, type SuperstateAmountValidation, SuperstateAmountView, type SuperstateAmountViewProps, type SuperstateCheckoutConfig, SuperstateOrderConfirmed, type SuperstateOrderConfirmedProps, type SuperstateOrderConfirmedUiEvent, type SuperstateOrderConfirmedUiState, type SuperstateOrderPlaced, type SuperstateReviewStepInput, type SuperstateReviewUiEvent, type SuperstateReviewUiState, SuperstateReviewView, type SuperstateReviewViewProps, type SuperstateSidebarPriceUi, type SuperstateSidebarUiState, SuperstateSidebarView, type SuperstateSidebarViewProps, type SuperstateSlippageOptionUi, type SuperstateSlippageUi, SuperstateSwapCheckoutContainer, type SuperstateSwapCheckoutContainerProps, type SuperstateSwapCheckoutRetryUiEvent, type SuperstateSwapCheckoutUiEvent, type SuperstateSwapCheckoutUiState, SuperstateSwapCheckoutView, type SuperstateSwapCheckoutViewProps, type SuperstateSwapLoadErrorReason, type SuperstateSwapStep, type SuperstateWalletStepInput, type SuperstateWalletUiEvent, type SuperstateWalletUiState, SuperstateWalletView, type SuperstateWalletViewProps, type SwapExecutionError, type SwapExecutionPhase, type SwapExecutionResult, type SwapOutputTokenState, type TaxDocumentAddressParts, type TaxDocumentFieldUi, type TaxDocumentFields, TaxDocumentModalContainer, type TaxDocumentModalContainerProps, type TaxDocumentModalUiEvent, type TaxDocumentModalUiState, TaxDocumentModalView, type TaxDocumentModalViewProps, type TaxDocumentScreenUi, type TaxDocumentState, type TokenSaleExecutionError, type TokenSaleExecutionPhase, type TokenSaleExecutionResult, USDC_ICON_URL, USDT_ICON_URL, type UseCoinListResult, type UseCoinListSignInCardViewModelOptions, type UseCoinListSignInCardViewModelResult, type UseCompleteOAuthOptions, type UseConnectWalletModalViewModelOptions, type UseConnectWalletModalViewModelResult, type UseConnectWalletOptions, type UseConnectWalletResult, type UseCountdownOptions, type UseErc20BalanceOptions, type UseErc20BalanceResult, type UseErc20TokenBalancesOptions, type UseErc20TokenBalancesResult, type UseIdentityVerificationViewModelOptions, type UseIdentityVerificationViewModelResult, type UseKycTokenResult, type UseOfferDetailsOptions, type UseOfferDetailsResult, type UseOffersGridViewModelOptions, type UseOffersGridViewModelResult, type UseOffersOptions, type UseOffersResult, type UseOndoBuyAmountViewModelOptions, type UseOndoBuyAmountViewModelResult, type UseOndoBuyCheckoutViewModelOptions, type UseOndoBuyCheckoutViewModelResult, type UseOndoBuyReviewViewModelOptions, type UseOndoBuyReviewViewModelResult, type UseOndoBuyTransactionOptions, type UseOndoBuyTransactionResult, type UseOndoPriceOptions, type UseOndoPriceResult, type UseOndoSellAmountViewModelOptions, type UseOndoSellAmountViewModelResult, type UseOndoSellCheckoutViewModelOptions, type UseOndoSellCheckoutViewModelResult, type UseOndoSellReviewViewModelOptions, type UseOndoSellReviewViewModelResult, type UseOndoSellTransactionOptions, type UseOndoSellTransactionResult, type UseOndoSidebarViewModelOptions, type UseOndoSidebarViewModelResult, type UseOndoTradingStatusOptions, type UseOndoTradingStatusResult, type UseOndoWalletSelectViewModelOptions, type UseOndoWalletSelectViewModelResult, type UseOptionAddressesOptions, type UseOptionAddressesResult, type UseParticipationsOptions, type UseParticipationsResult, type UseRequirementsChecklistViewModelOptions, type UseRequirementsChecklistViewModelResult, type UseRequirementsOptions, type UseRequirementsResult, type UseSuperstateAmountViewModelOptions, type UseSuperstateAmountViewModelResult, type UseSuperstateReviewViewModelOptions, type UseSuperstateReviewViewModelResult, type UseSuperstateSidebarViewModelOptions, type UseSuperstateSidebarViewModelResult, type UseSuperstateSwapCheckoutViewModelOptions, type UseSuperstateSwapCheckoutViewModelResult, type UseSuperstateWalletViewModelOptions, type UseSuperstateWalletViewModelResult, type UseSwapOutputTokenOptions, type UseSwapOutputTokenResult, type UseSwapQuoteOptions, type UseSwapQuoteResult, type UseTaxDocumentModalViewModelOptions, type UseTaxDocumentModalViewModelResult, type UseTaxDocumentOptions, type UseTaxDocumentResult, type UseTokenMetadataOptions, type UseTokenMetadataResult, VerificationOverlay, type VerificationOverlayProps, type WalletAuthorizationError, type WalletAuthorizationPhase, type WalletAuthorizationResult, WalletError, type WalletsStatus, authorizeWallet, classifyWalletError, connectExternalWalletFlow, createCoinListClient, defaultCheckoutConfig, ensureErc20Allowance, executeOndoSwap, executeSwap, executeTokenSale, formatCountdown, formatMonthYear, formatSaleCardCountdown, offerIconUrl, ondoLoadErrorReason, pinoClientLogger, prepareOndoBuy, prepareOndoSell, quoteIsStale, quoteOverAsks, stablecoinIconUrl, submitErc20Approval, useCoinList, useCoinListSignInCardViewModel, useCompleteOAuth, useConnectWallet, useConnectWalletModalViewModel, useCountdown, useErc20Balance, useErc20TokenBalances, useIdentityVerificationViewModel, useKycToken, useOfferDetails, useOffers, useOffersGridViewModel, useOndoBuyAmountViewModel, useOndoBuyCheckoutViewModel, useOndoBuyReviewViewModel, useOndoBuyTransaction, useOndoPrice, useOndoSellAmountViewModel, useOndoSellCheckoutViewModel, useOndoSellReviewViewModel, useOndoSellTransaction, useOndoSidebarViewModel, useOndoTradingStatus, useOndoWalletSelectViewModel, useOptionAddresses, useParticipations, useRequirements, useRequirementsChecklistViewModel, useSuperstateAmountViewModel, useSuperstateReviewViewModel, useSuperstateSidebarViewModel, useSuperstateSwapCheckoutViewModel, useSuperstateWalletViewModel, useSwapOutputToken, useSwapQuote, useTaxDocument, useTaxDocumentModalViewModel, useTokenMetadata, validateAmount, validateSellAmount, validateSuperstateAmount };