This changelog covers the
@coinlist-co/react SDK.September 17, 2026 - The /universal entry point, the Ondo sell flow, structured logging, and Base support
Three things change every call site: the
The subpath is renamed. Nothing it exports is renamed with it, and the entry point gained exports rather than losing any.The other two entry points, The React surface forked with it. Every buy screen’s component and viewmodel is now
Migration: add A chain with no Ondo contract on it is known before any step runs, and the old shape had to render a wallet picker leading nowhere and a confident
Checkout asset icons now resolve from the public token registry first and fall back to the offer’s own artwork, so
A host that already knows the wallet can skip the wallet step: set
/shared subpath is now /universal, Ondo’s one-directional swap API forks into buy and sell, and the Ondo swap contract is read off the offer instead of a constant the SDK held.The release also adds a complete Ondo sell checkout, an optional structured logger on Config, and Base mainnet and Base Sepolia in the chain model.Breaking Changes
@coinlist-co/react/shared is now @coinlist-co/react/universal
The subpath is renamed. Nothing it exports is renamed with it, and the entry point gained exports rather than losing any.shared described where the code sat in the repository; universal describes what it is - the half of the SDK that runs unchanged in a browser and on a backend. The old name also collided with the SDK’s internal shared/ directories, which mean something else entirely.Migration: find and replace the import path. There is no compatibility alias - the old subpath is gone from exports, so a missed one is a resolution error at build time rather than a silent fallback.@coinlist-co/react and @coinlist-co/react/server, are untouched./universal now also exports EvmWallet and the wallet-address constructors, WalletError, Logger and the rest of the logging types, and swapSpender. A host that was reaching for those through @coinlist-co/react can keep doing so; both barrels name them.Ondo forks into buy and sell
Ondo ships two products on oneondo::swap offer type. Preparing an order now depends on which one, so the single method became two; broadcasting stays one, because it reads calldata and a deadline and knows about neither direction.A purchase approves the funding coin and a sale approves the asset, and the two builders are two endpoints -
POST /v1/ondo/swap/buy and POST /v1/ondo/swap/sell - whose amount is denominated in a different token on each. A single method taking a side would have re-merged exactly that distinction.Migration: pick the method that matches the direction. The parameters are otherwise unchanged apart from the required swapContracts below.OndoBuy*, the new sell screens are OndoSell*, and the two steps both products share kept their unqualified names:The Ondo swap contract is read off the offer
ondoSwapContractAddress(chain) is removed, and OfferDetail gains a required swapContracts: OfferSwapContract[].One constant can only name one deployment, and beta and production run different contracts on the same chain - so whichever one it named, the other approved a spender that could not fill the order. The address now arrives per environment on the offer.Migration: pass offer.swapContracts to prepareBuy, prepareSell and useOndoBuyAmountViewModel; read a single address with swapSpender(offer.swapContracts, chain). Code that constructs an OfferDetail by hand - fixtures, mocks, preloaded server data - adds the field, with [] meaning “cannot be swapped anywhere”.OndoSwapExecutionError loses its spender-mismatch arm as a result: the backend compares the built transaction’s destination to the contract it serves on the offer, so a third comparison would check one source against itself.CheckoutConfig for Ondo requires side
config["ondo::swap"] takes a new required side: () => OrderBookSide.A thunk rather than a resolver taking the offer, because no offer can answer it: offer.type is ondo::swap both ways, and the direction is a property of the page. This is the one config entry that is per-render rather than per-integration, so a host with a buy page and a sell page closes the thunk over whatever selects the direction.side. It is required with no default because the wire parameter behind it defaults to buy silently, and an unstated direction should be a compile error rather than a purchase.The Ondo checkout state is a union
OndoBuyCheckoutUiState - and the new OndoSellCheckoutUiState - are now discriminated unions rather than product types:0 USDC balance before refusing on Confirm. OndoCheckoutErrorReason is 'unsupported-chain' today.Migration: only for hosts driving useOndoBuyCheckoutViewModel behind their own markup. switch on state.type first, then read the steps off the content arm.OfferCard is now two components
One card cannot be both a live-sale tile and a browse row.
OfferSaleCard is the dark sale card with the countdown; OfferAssetCard is the light catalogue row. Each takes its own UI model - OfferSaleCardUi or OfferAssetCardUi, both with fromOffer and fromDetail companions - rather than an Offer.Migration: pick the card that matches the surface and map the offer through its UI model.CheckoutAssetUi.fromOffer takes token metadata
Checkout asset icons now resolve from the public token registry first and fall back to the offer’s own artwork, so CheckoutAssetUi.fromOffer takes the offer’s TokenMetadata | null alongside it. This affects hosts composing their own checkout viewmodel from the step-level hooks; pass null to keep the previous behaviour.Added
The Ondo sell flow
A complete sell checkout, mirroring buy.CheckoutContainer renders it when config["ondo::swap"].side() returns "sell" - no other host change is required.A sale sells the asset and settles into USDC, so the approval is granted on the asset’s contract. The SDK ships no registry entry for a provider’s asset, so its address and decimals come off the sell quote and nowhere else.See Ondo Swap Sell for the whole flow.
CheckoutWalletSelection.preselected
A host that already knows the wallet can skip the wallet step: set preselected to a ready EvmWallet and the checkout opens on the amount, renumbering the cards that remain. A sell page reached from a position knows which wallet holds it, and asking again would be a question with one answer.It lives on the wallet seam rather than in a provider’s config because nothing about it is one provider’s - but only the Ondo sell checkout honours it today, so do not assume a skip from the field being set.Structured logging
The SDK can now report what it is doing.Config takes an optional logger, and with none the SDK logs nothing at all - no console fallback, at any level, on any codepath.Logger(from@coinlist-co/react/universal) is the port:debug,info,warn,error, andlevel(). Implement it over your own sink in four methods.- Two shipped implementations, one per environment:
pinoClientLoggerfrom@coinlist-co/reactandpinoServerLoggerfrom@coinlist-co/react/server. - Every line is structured: a constant
msgnaming what happened, ascope(HTTP,OFFERS,ONDO,HOOKS, …), and a bag of fields carrying every value that varies. Field names follow OpenTelemetry where a stable key exists. - Every event is a lambda, checked against
level()before it runs, so an expensivedebugline costs nothing atinfoand nothing at all with no logger supplied.
pino ^10 is a new runtime dependency and does not tree-shake: every integration pays roughly 3 kB gzipped whether or not it logs.Base mainnet and Base Sepolia
EthereumChain gains base_mainnet (8453) and base_sepolia (84532), with chain ids, network names, explorers, and Base USDC and USDT in the token registry. Adding a chain is a deliberate compile error until every lookup table has an entry, so a host switching on EthereumChain exhaustively will need two more arms.No provider has a swap contract deployed on Base, so an Ondo or Superstate checkout there renders the unsupported-chain state.Smaller additions
coinlist.tokens.list(chain?)fetches the registry’s complete snapshot in a single request - every chain with no argument, one chain with it. Prefer it overget()in a loop when rendering a catalogue. Unlikeget, a missing snapshot throws rather than answering[].Offer.tokensandOfferDetail.tokens, the(chain, address)entries an offer’s assets live at, keyed by role.OffersAssetGrid, a responsive browse grid ofOfferAssetCardleaves. Pure - no fetch, no provider - and distinct fromOffersGridView, which lays out sale cards.useErc20Balance, the address-keyed counterpart touseErc20TokenBalances, for a token whose contract address arrives at runtime and has no registry symbol to look up.useCheckoutOfferTokenMetadata, which keys the registry lookup by the offer’s token entry for the checkout chain.OndoCheckoutErrorandOndoCheckoutErrorReason, the flow-level error surface both Ondo products share.- Release candidates on npm. Every merge to
mainnow publishes<next-patch>-rc.<short-sha>under thercdist-tag, so a fix can be tried before it is tagged:npm install @coinlist-co/react@rc.
Changed
- Checkout asset logos resolve from the token registry first, taking the vector logo or the smallest raster variant covering the render width, and falling back to
Offer.logoUrland then a neutral placeholder. Every absence - loading, error, disabled, unlisted, no token entry - falls back rather than rendering a broken image. - An Ondo checkout on a chain with no contract now fails at the flow level, before any step runs. It previously displayed a
0balance for a token the flow would never spend and refused on Confirm, as though the amount were the problem. useTokenMetadatamoved from the tokens feature to the shared hooks, now that checkout is its second consumer. The import path is unchanged: it is still exported from@coinlist-co/react.lucide-reactis now^1(from^0.577). It is a bundled dependency, not a peer, so no host action is needed.
Fixed
- An offer token on a chain the SDK does not model no longer blanks the offers list. One Base token took down the whole catalogue:
Offer.fromDtoruns inside the paginated response’smap, so one unparseable item threw away the page. Unknown chains are now skipped, costing that token its logo. - The Ondo amount step no longer strands the user when a quote expires while an error is showing. The refresh action is reachable from that state.
- The Ondo amount input reads
USDCwith amaxaffordance, matching the Superstate checkout.
Removed
identity_verified,proof_of_addressandsource_of_fundsare gone fromRequirementType. They were left over from an abandoned modular-KYC effort and the backend no longer returns them, so aswitchover requirement types needs three fewer arms.
August 25, 2026 - Namespaced client and server surfaces, the Ondo buy flow, a drop-in CheckoutContainer, and token metadata
This is the largest release since the SDK went out, and almost every call site changes. It finishes the namespace migration v0.10.0 started, splits every component with behaviour into a
A second swap provider shipped in this release, so a namespace called
Components split into
Every component that has behaviour is now a
Reading ERC-20 balances is not specific to a swap - the token sale and the Ondo buy flow need the same thing - so the hook moved out of the swap feature.Migration: rename the import and the call. The options (The reads are free to poll while the user sizes an order;
A global
A BCP-47 tag applied to number, date and currency formatting in every SDK component in the tree. Defaults to
Container / View pair, adds a second swap provider (Ondo) with a complete checkout UI, and introduces CheckoutContainer so a host can render any offer type without knowing which provider is behind it.Nothing below changes behaviour. Parameters and return types are unchanged unless a row says otherwise.Breaking Changes
Every remaining flat method moved into a namespace
CoinListClient and CoinListServer now expose nothing but namespaces. init() is the single exception on the client, because it is lifecycle rather than domain; CoinListServer has no top-level member at all.ClientServer
Migration: insert the namespace before the method name, and pass a single object to any method that used to take more than one argument.
coinlist.swap is now coinlist.superstate
A second swap provider shipped in this release, so a namespace called swap could only ever mean one of them. Provider namespaces are named after the provider; CoinList’s own namespaces stay named after what they do.Migration: replace
coinlist.swap. with coinlist.superstate., rename executeSwap to execute, and take the ownership challenge from coinlist.wallets. authorizeWallet keeps its name, its parameters, its phases, and its error steps.Token-sale and ERC-20 methods dropped their stuttering prefixes
coinlist.tokenSale.createParticipation(params) is unchanged.Offer.type values changed
OfferType was 'sale' | 'swap'. It is now 'coinlist::token_sale' | 'superstate::swap' | 'ondo::swap', so an offer names the provider that settles it rather than the shape of the transaction. Two providers now issue swap offers, and 'swap' could not tell them apart.Migration: switch on the new values exhaustively rather than testing for one. A
default branch that assumes “everything else is a token sale” now catches Ondo offers it cannot render.If you render
CheckoutContainer (below), you do not switch at all: it dispatches on offer.type for you, and a future offer type becomes a compile error in your CheckoutConfig rather than a blank screen.Components split into Container and View
Every component that has behaviour is now a Container (owns the props, calls the viewmodel) and a View (pure, driven by a state object). Both halves are exported, along with the viewmodel between them, so you can keep the SDK’s logic and supply your own markup.Migration: append
Container to the component name. Props are unchanged.OfferCard, RequirementItem and ConnectedWalletList are pure already and keep their names.useSwapTokenBalances is now useErc20TokenBalances
Reading ERC-20 balances is not specific to a swap - the token sale and the Ondo buy flow need the same thing - so the hook moved out of the swap feature.Migration: rename the import and the call. The options (address, chain, assets, pollIntervalMs, enabled) and the returned { balances, isLoading } are unchanged. The poll-interval constant is now ERC20_BALANCE_POLL_INTERVAL_MS.Added
Ondo buy flow
Ondo is the SDK’s second swap provider.coinlist.ondo covers the reads and the two halves of placing an order.The wallet-driven half is client-only, and is deliberately two calls rather than one:
coinlist.ondo.prepareSwap({ wallet, symbol, chain, tokenAddress, amount, onProgress? })submits the ERC-20 approval, then builds the transaction.coinlist.ondo.executeSwap({ wallet, transaction, chain, now?, onProgress? })broadcasts it.
Built calldata is only good for about a minute and an approval takes most of one to mine. Doing both behind a single button would hand the user an expired quote, so the SDK splits the flow where the user’s decision is. Both calls are total: every failure comes back as
{ type: "error", error: { step } } rather than throwing.prepareSwap is not, because building a transaction spends an attestation. No CoinList fee is applied to a read quote - buildSwapTransaction takes the gross amount and Ondo prices the remainder after the fee comes off.Ondo runs no sandbox, so the read params take no chain: every environment prices against Ondo production on Ethereum mainnet. buildSwapTransaction is the exception, because it names a real contract on a real chain.Also new: ondoSwapContractAddress(chain), ONDO_POLL_INTERVAL_MS, ONDO_QUOTE_EXPIRY_THRESHOLD_MS, ONDO_SUPPORTED_INPUT_ASSETS, and DEFAULT_ONDO_AMOUNT_TO_COMPUTE_PRICE.CheckoutContainer, a drop-in checkout for any offer type
CheckoutContainer switches on offer.type and renders the matching provider’s checkout, so a host renders one component for every offer in its catalogue.CheckoutConfig is keyed by OfferType with every key required, so a new offer type in the catalogue breaks the build rather than rendering nothing. defaultCheckoutConfig fills in the entries that have a sensible default.wallets is a CheckoutWalletSelection: the embedded wallets, the connected external one, and the two lambdas that connect and disconnect it. The SDK ships no wallet stack, so this is where you plug in Privy, AppKit, or your own.coinlist::token_sale is a host render slot until the SDK ships that flow. The Ondo symbol resolver must be total: React hooks cannot be called conditionally, so every provider’s viewmodel runs for every offer and the resolver is called for Superstate and token-sale offers too, where its answer is discarded. Return anything for an offer you do not recognise rather than throwing.Superstate swap checkout UI
The Superstate swap UI moved into the SDK from the reference app:SuperstateSwapCheckoutContainer and SuperstateSwapCheckoutView, the step views (SuperstateWalletView, SuperstateAmountView, SuperstateReviewView, SuperstateOrderConfirmed, SuperstateSidebarView, SlippagePicker), and the viewmodels behind them.Each product exposes a single god viewmodel wrapping the whole flow - useSuperstateSwapCheckoutViewModel(), useOndoBuyCheckoutViewModel() - plus the smaller hooks it is composed from, so you can write your own viewmodel against the same pieces.Token metadata from the CoinList registry
coinlist.tokens resolves display metadata - name, symbol, decimals, and light and dark logos - keyed by (chain, address) rather than by symbol, which can collide.It is public and unauthenticated: unlike every other namespace, its methods never require a logged-in user, and it works on the server with a read-only session store.
useTokenMetadata({ chain, address, enabled }) is the hook form.OfferDetail gained a tokens field carrying the (chain, address) pairs to look up. TokenLogo is VECTOR (one SVG) or RASTER (webp variants at 32-512px); pick the smallest variant that covers your render size.OfferToken.chain is a Chain, which spans Solana as well as EVM, while coinlist.tokens.get takes an EthereumChain. Narrow before you look a token up - an offer may list a token on a chain the registry routes do not serve.A global locale on CoinListProvider
'en-US' - a fixed constant, never navigator.language, so server and client render the same markup. A plain string, so a Next.js server layout can pass params.locale straight through.It does not reach embedded third-party flows: the Sumsub UI language stays on RequirementsChecklistContainer#identityVerificationOptions.locale.HttpError and apiErrorCode
HttpError is now exported from both @coinlist-co/react and @coinlist-co/react/shared; apiErrorCode from @coinlist-co/react/shared. HttpError is what every API call rejects with when the backend refuses a request, so without it there is no way to catch a 4xx by type. apiErrorCode(error) reads the code out of the response body, which is what tells two 422s apart.Smaller additions
SolanaChain('solana_mainnet' | 'solana_devnet') andChain, the union of it withEthereumChain, both with validating constructors that throwValidationErroron an unknown value. Solana offers are not executable yet - this is the type surface an offer’s tokens are parsed against, ahead of theSolanaWalletseam.EvmSigner, the signing-only half ofEvmWallet(address+signMessage). The external-wallet ownership proof needs nothing more, so a host can satisfy that flow without implementing on-chain capabilities.tokensBaseUrlonClientConfigandServerConfig, to pointcoinlist.tokensat a non-production registry.CoinListSignInButton, the button on its own for hosts that do not want the card.VerificationOverlay, and every requirements viewmodel and.typesmodule.useOndoPrice,useOndoTradingStatus,useOndoSwapTransactionfor composing your own Ondo viewmodel.- Formatting and presentation helpers:
useCountdown, and theasset-icon,dateanddurationformatters.
Changed
- Requirements, offers and wallets are the same namespace on both sides.
coinlist.offers,coinlist.requirementsandcoinlist.walletsexpose identical method names onCoinListClientandCoinListServer; the server adds an optional trailingclientCredson the reads that can run without a user session, and the client addsrequirements.handle. - Ondo reads live under
/v1/ondo/swap/*and take a requiredside. Ondo reports its limits per side, so a trading status fetched without one answers 422 rather than guessingbuy. getQuoterefuses a request sized by bothtokenAmountandnotionalValue, throwingValidationError. TypeScript accepts an object carrying both, and the previous behaviour silently droppednotionalValue.Participation,SwapQuoteand the other provider types moved modules inside the package. They are still exported under the same names from@coinlist-co/react/shared, so only deep imports break - and deep imports were removed in v0.5.0.
Removed
coinlist.swap.requestWalletOwnershipChallenge- usecoinlist.wallets.createOwnershipChallenge, which is the same call and is shared by the checklist and the allow-list flow.
July 27, 2026 — Fix token-sale participation amount sent in the wrong units
Fixed
Token-sale participations recorded the amount in the wrong units
coinlist.tokenSale.executeTokenSale recorded the participation with the raw base-unit amount (e.g. "25000000" for 25 USDC) instead of a decimal token amount ("25"). The participations API rescales the amount by the asset’s decimals to check it against the on-chain approval allowance, so the base-unit value overflowed the approved allowance — the backend rejected every participation and funds failed to commit. executeTokenSale now records the decimal amount, so participations go through as expected.If you drive the lower-level coinlist.tokenSale.createParticipation yourself, pass amount as a decimal token amount (e.g. "100" for 100 USDC), not raw base units. This has always been what the backend expects; only the CreateParticipationParams.amount doc comment was wrong, and it is now corrected.July 24, 2026 — Token-sale flow, erc20/tokenSale namespaces, and stricter offer models
Breaking Changes
Participation methods moved to the tokenSale namespace
The flat participation methods on CoinListClient and CoinListServer now live under coinlist.tokenSale, mirroring how swaps sit under coinlist.swap.Migration: insert the
tokenSale namespace before the method name. The parameters and return types are unchanged.ERC-20 reads moved from swap to a new erc20 namespace
getTokenAllowance and getTokenBalance are generic ERC-20 reads shared across the swap and token-sale flows, so they moved off coinlist.swap onto coinlist.erc20.Migration: replace
swap.getTokenAllowance with erc20.getTokenAllowance and swap.getTokenBalance with erc20.getTokenBalance. The endpoints and parameters are unchanged.Offer.endsAt and OfferDetail.endsAt are now nullable
An offer can legitimately have no end date, so endsAt is now Date | null (was Date). fromDto maps a missing end date to null.Migration: handle the null case when reading endsAt.Added
Token-sale flow
A newtokenSale namespace encapsulates the on-chain invest flow, mirroring executeSwap. On the client, coinlist.tokenSale.executeTokenSale() runs a sale end-to-end against a connected EvmWallet:approve() for the sale amount (resetting a stale non-zero allowance to 0 first for USDT-style tokens), waits for it to mine, and records the participation with CoinList. Wallet connection and chain switching remain the host’s responsibility. See CoinList Token Sale for the end-to-end integration.An
approve() is submitted even when the existing allowance already covers the amount: the backend requires a fresh approval transaction hash on every participation and verifies it on-chain before confirming.allowance-reset / allowance-reset-reverted versus approval / approval-reverted) so you can tell which of the two wallet prompts the user rejected, and the approval hash is surfaced on a backend failure so recording can be retried without re-approving on-chain. New types: ExecuteTokenSaleParams, TokenSaleExecutionPhase, TokenSaleExecutionError, TokenSaleExecutionResult, and the shared Erc20ApprovalError (reused across the swap and token-sale flows).erc20 namespace
coinlist.erc20 exposes the generic ERC-20 reads shared across on-chain flows:Offer type
Offer and OfferDetail now expose a type field (OfferType, one of 'sale' or 'swap') so you can distinguish token-sale offers from swap offers. OfferType is exported from @coinlist-co/react/shared.Changed
Stricter offer models
Fields the backend now guarantees as non-null are typed as required (string instead of string | null):Offer:tagline,bannerUrl,logoUrl.OfferDetail:tagline,bannerUrl,logoUrl,category.
OfferDetail.about stays nullable. OfferCard now hides its “Ends” row when an offer has no end date.July 20, 2026 — Swap namespace, external-wallet connect, and KYC/tax/PII flows
This release folds in the 0.7.0 and 0.8.0 development versions.Shared (
The provider is now an alias of
Added
Swap namespace
client.swap and server.swap wrap the swap, token, and wallet endpoints:On the client, the namespace also drives a caller-supplied wallet:
authorizeWallet({ wallet, offerId, contractAddress, chain, onProgress })— proves wallet ownership and allow-lists it for a swap offer, with typed progress phases and asuccess/errorresult. Idempotent: returns success immediately if the wallet is already authorized.executeSwap({ wallet, contractAddress, chain, inputTokenAddress, quote, slippageBps, onProgress })— runs the full on-chain swap: status check, ERC-20 approval (with USDT-style allowance reset), swap submission, and confirmation. The confirmed output is decoded from theSwappedevent.
viem ^2 is a new peer dependency.Swap hooks
useSwapOutputToken— reads the swap contract’s output token (the tokenized equity).useSwapQuote— polls a live quote (15s default), skipping until the output-token decimals and a valid amount are known.useSwapTokenBalances— polls the user’s balance for one or more input assets.
Wallet abstraction
EvmSigner / EvmWallet interfaces plus typed WalletError classification — bring your own wallet stack (wagmi, viem, Privy, …). New phase and error types: WalletAuthorizationPhase, WalletAuthorizationError, SwapExecutionPhase, SwapExecutionError, SwapExecutionResult.See Superstate Swap for the end-to-end integration.External wallet connect
Prove and bind an external wallet to an offer option:createWalletOwnershipChallenge(params)→POST /v1/wallet-ownershipconnectExternalWallet(offerId, params)→POST /v1/offers/{offer_id}/addresseslistOptionAddresses(offerId, offerOptionId)→GET /v1/offers/{offer_id}/addressesremoveOptionAddress(offerId, addressId)→DELETE /v1/offers/{offer_id}/addresses/{id}
ConnectWalletModal and ConnectedWalletList (list, change, and remove bound wallets), with the useConnectWallet and useOptionAddresses hooks.Identity, KYC, and tax documents
createKycToken(levelName?, reset?)→POST /v1/kyc-token(Sumsub)fetchPii()→GET /v1/pii, pre-fill data for tax formssubmitDocument(documentType, fields)→POST /v1/documents/{document_type}/submission- Components
IdentityVerificationandTaxDocumentModal; hooksuseKycTokenanduseTaxDocument. handleRequirementnow resolves thekyc_approved,identity_verified,proof_of_address,source_of_funds,accreditation,external_wallet,whitelisted_wallet,document, andjurisdictionrequirement types.
identity_verified, proof_of_address, and source_of_funds have since been removed from the API. The SDK still handles them, but offers no longer return them, so you do not need to write branches for those three.App-level authentication
CoinListServer.clientCredentialsOAuth() performs the OAuth 2.0 client_credentials grant for app-level access without a user session. The server offer reads (fetchOffers, fetchOffersPage, fetchOfferDetails, fetchOfferRequirements) accept an optional clientCreds argument to use it.Shared (@coinlist-co/react/shared)
BlockchainAmount(withadd/sub),parseBlockchainAmount,formatAmount,computeSlip, and theBpsnewtype.- Constants and helpers:
DEFAULT_SLIPPAGE_BPS,SLIPPAGE_OPTIONS_BPS,SWAP_POLL_INTERVAL_MS,SUPERSTATE_SWAP_CONTRACT_ADDRESS_SEPOLIA,TOKEN_REGISTRY,USDC_SYMBOL,txExplorerUrl. - Swap, KYC, PII, document-submission, and wallet-ownership types.
Changed
CoinListProvider is safe to mount app-wide
The provider is now an alias of CoinListContextProvider and renders no DOM or styles. Components self-scope their styling through CoinListStyleScope, so mounting the provider high in your tree no longer affects the rest of the app.July 2, 2026 — Required approvalTransactionHash, stricter wallet type, CSS isolation
Breaking Changes
approvalTransactionHash is required on createParticipation
CreateParticipationParams now requires approvalTransactionHash — the hash of the ERC-20 allowance transaction that precedes the participation. Submit the approval on-chain first, then pass its hash.WalletAddress narrowed to `0x${string}`
WalletAddress is now the template-literal type `0x${string}` instead of string. Values that aren’t 0x-prefixed literals need validation or a cast at the boundary.Added
CSS isolation
SDK styles are isolated behind a prefixed Tailwind build with scoped provider injection, and context is separated from styling so the context functions can be used without pulling in SDK styles. This work completes in v0.9.0, whereCoinListProvider becomes safe to mount app-wide.coinlist.co support
Added first-class support for the coinlist.co environment.May 7, 2026 — Read-only SessionStore support
Breaking Changes
SessionStore.setSession is now optional
setSession has been changed from a required method to an optional one (setSession?). This formalises read-only store mode for execution contexts — such as Next.js Server Components — that can read cookies but cannot write them.Previously the only workaround was a no-op setSession: async () => {}, which silently discarded refreshed sessions after consuming the refresh token over the network, effectively causing a silent logout. Omitting setSession is now the explicit, safe contract: the SDK skips token refresh entirely, making no network calls and consuming no refresh tokens.Migration: if you currently pass a no-op setSession, remove it. If your store is writable, no change is needed.Added
WritableSessionStoreRequiredError
New error class exported from @coinlist-co/react/server. completeOAuth() and logout() throw this immediately when called on a read-only store (no setSession), before any network call is made.Fixed
No unnecessary network retries on expired tokens in read-only mode
Previously, when a request returned a 401 and the store was read-only, the SDK would retry the request with the same expired token — wasting a round-trip that always failed. The SDK now detects the read-only store and surfaces the 401 immediately without retrying.May 5, 2026 — API consistency, new /shared entry point, and Base* component removal
Breaking Changes
Client methods renamed: fetchAll* → fetch*
fetchAllOffers and fetchAllParticipations have been renamed on both CoinListClient and CoinListServer to drop the redundant All prefix.Migration: do a global find-and-replace in your codebase:
Hooks renamed: useCoinList* → use*
The CoinList infix has been dropped from all hook names and their associated option/result/reason types.Migration: rename the hook calls and any imported types. Example:
SSR prop renamed: serverOffers / serverData → data
The SSR pre-fetch prop has been unified to data across all hooks and components that accept server-side data. The RequirementsServerData type is also renamed to RequirementsData.Migration: rename the prop/option to
data wherever you pass pre-fetched server results.LoadRequirementsState CONTENT shape: requirementsByOptionId → requirements
If you read the CONTENT state returned by useRequirements (or previously useCoinListRequirements) directly, the field name has changed.Base* components removed
BaseOffersGrid, BaseOffersGridProps, BaseRequirementsChecklist, and BaseRequirementsChecklistProps have been removed. The connected components (OffersGrid, RequirementsChecklist) now accept all the same customization props directly — including the optional data prop for pre-fetched server data — so there is no longer a need for a separate base variant.Migration: replace BaseOffersGrid and BaseRequirementsChecklist usage with the main components and pass the same props directly.Import paths restructured — new @coinlist-co/react/shared entry point
Sub-path exports (/client, /client/hooks, /client/components, /client/core) have been removed. The package now exposes three canonical entry points:Domain types that were previously re-exported from both
@coinlist-co/react and @coinlist-co/react/server are now the sole responsibility of @coinlist-co/react/shared. They remain re-exported from the client and server entry points as well, so most imports will continue to work without changes. However, if you were importing from the now-deleted sub-paths, update your imports:OffersGridProps type renamed from Props
The exported type for OffersGrid props was the generic name Props. It is now exported as OffersGridProps.April 30, 2026 — SSR data fetching, useParticipations hook, and requirement action defaults
Added
Server (@coinlist-co/react/server)
CoinListServernow exposes the full data-fetching surface previously only available onCoinListClient:fetchAllOffers(),fetchOffersPage(),fetchOfferDetails(),fetchAllParticipations(),fetchParticipationsPage(),fetchParticipation(),createParticipation(),fetchOfferRequirements(), andfetchRequirementStatuses(). Use these in Next.js Route Handlers and Server Components without shipping any client bundle.@coinlist-co/react/servernow re-exports all shared types —Offer,OfferDetail,Participation,Requirement,RequirementStatusInfo, pagination helpers,NotAuthenticatedError, and related types — so you no longer need to import them from the client entry.
Client (@coinlist-co/react, @coinlist-co/react/client)
useParticipations(offerId?)hook — loads all participations for the authenticated user with aLOADING / CONTENT / ERRORstate machine, optionally filtered by offer. New exported types:UseParticipationsResult,LoadParticipationsState,LoadParticipationsReason.handleRequirement(requirement)onCoinListClient— opens the corresponding CoinList page for completing a requirement in a new tab (/verify-identity,/wallet, etc.). No-op forjurisdictionrequirements.contactSupport()onCoinListClient— opens the CoinList support ticket page in a new tab.
Changed
Components
RequirementsChecklist:onRequirementActionandonContactSupportprops have been renamed toonRequirementActionOverrideandonContactSupportOverride. Both now default toCoinListClient#handleRequirementandCoinListClient#contactSupportrespectively, so most integrations can omit them entirely. Passnullto disable the corresponding button/link.RequirementItem:onActionandonContactSupportnow acceptnull(in addition toundefined) to suppress rendering of action buttons.
Removed
Client (@coinlist-co/react, @coinlist-co/react/client)
sandboxoption removed fromClientConfig. Sandbox offers are no longer toggled via the SDK config.StaticRequirementsChecklistPropstype removed. UseRequirementsChecklistwith the connected API orBaseRequirementsChecklistfor fully custom rendering.
April 23, 2026 — Requirements API, sandbox mode, and participations filtering
Added
Client (@coinlist-co/react, @coinlist-co/react/client)
fetchOfferRequirements(offerId)onCoinListClient— returns requirements grouped by option ID (Record<OfferOptionId, Requirement[]>).fetchRequirementStatuses(offerId)onCoinListClient— returns the authenticated user’s status for each requirement.useCoinListRequirements(offerId)hook for loading requirements and statuses with aLOADING / CONTENT / ERRORstate machine.sandboxoption onClientConfig— whentrue, passessandbox=trueto offers API calls so sandbox offers are included.- New exported types:
Requirement,RequirementId,RequirementType,RequirementStatusValue,RequirementStatusInfo,ParticipationsPaginationParams. - New exported enums/constants:
RequirementVariant,RequirementStatus,ChecklistStatus. - New hook types:
UseCoinListRequirementsResult,LoadRequirementsState,LoadRequirementsReason. fetchAllParticipations(offerId?)andfetchParticipationsPage(params)now accept an optionalofferIdto fetch participations for a specific offer.fetchParticipationsPagetakes the newParticipationsPaginationParamstype (superset ofPaginationParams) which carries theofferIdfield.
Fixed
Components
- Fixed missing dark mode CSS variables in Next.js projects — prebuilt styles now include the full set of design-system tokens so components render correctly under
darkclass orprefers-color-scheme: dark.
April 13, 2026 — Participations API
Added
Client (@coinlist-co/react, @coinlist-co/react/client)
fetchAllParticipations()onCoinListClientfor fetching all participations across pages.fetchParticipationsPage()onCoinListClientfor paginated participation fetching.fetchParticipation()onCoinListClientfor fetching a single participation by id.createParticipation()onCoinListClientfor creating a new participation.- New exported types:
Participation,ParticipationId,ParticipationStatus,CreateParticipationParams,Blockchain,WalletAddress.
April 8, 2026 — Support UI component customization
Added
Client (@coinlist-co/react, @coinlist-co/react/client)
- Added support for passing
classNameandcontainerClassNameto<OffersGrid />,<OfferCard />, and<CoinListSignInCard />.
April 7, 2026 — Publish missing exports
Fixed
Client (@coinlist-co/react, @coinlist-co/react/client)
- Re-export offer, offer detail, and pagination types from the package root and client core entry so you can type against
Offer,OfferDetail, pagination params, and related helpers without reaching into internal modules. - Export
BaseCoinListSignInCardandBaseCoinListSignInCardPropsfrom@coinlist-co/react/clientfor custom sign-in layouts built on the same primitives asCoinListSignInCard.
April 2026 — Offers UI and OAuth helpers
Added
Client (@coinlist-co/react/client)
fetchAllOffers(),fetchOffersPage(), andfetchOfferDetails()onCoinListClientfor fetching offers data.<OffersGrid />— batteries-included component that loads offers and displays them in a responsive grid, with<OfferCard />for each tile.useCoinListOffers()hook for loading offers when you want full control over layout instead of the grid.useCoinListOfferDetails()hook for a single offer’s details.useCompleteCoinListOAuth()hook to run the OAuth redirect callback once on mount.- Optional
authorizationPageUrlon client config so you can pointstartOAuth()at a non-production authorization page.
March 2026 — Initial release
Added
Client (@coinlist-co/react/client)
CoinListProvideranduseCoinList()hook for React context-based SDK initialization.createCoinListClient(config)factory for manual or non-React usage.- OAuth 2.0 with PKCE via
startOAuth()andcompleteOAuth(). getAuthState()andlogout().
Server (@coinlist-co/react/server)
createCoinListServer(config)factory for BFF / Next.js API routes.completeOAuth(),accessToken()(auto-refreshing), andlogout().
Components
CoinListSignInCardandCoinListSignInButtonfor OAuth sign-in flows.RequirementsChecklist/RequirementItem— eligibility checklist with accordion UI.PoweredByCoinListattribution badge.- Prebuilt CSS — no
tailwindcsspeer dependency required.
Infrastructure
- Subpath exports:
@coinlist-co/react,@coinlist-co/react/client,@coinlist-co/react/server. - Requires React 18+.