@vultisig/core-chain 5.1.0 → 5.3.0

package/CHANGELOG.md

@@ -1,5 +1,72 @@
 # @vultisig/core-chain
 
+## 5.3.0
+
+### Minor Changes
+
+- [#2325](https://github.com/vultisig/vultisig-sdk/pull/2325) [`7c95286`](https://github.com/vultisig/vultisig-sdk/commit/7c9528622702a1e6f10cd5ff72017779d25e509a) Thanks [@Ehsan-saradar](https://github.com/Ehsan-saradar)! - EVM fee quotes now size the gas reserve from the transaction itself instead of a flat 600k floor. An aggregator swap is signed with the larger of the route's own gas and 1.5x its simulation (1.5x the 600k default when it cannot be simulated, e.g. a token route quoted before its allowance exists); a THORChain or Maya swap deposit (any transaction carrying the native swap payload) takes a fixed 120k; a plain transfer, including a memo-carrying vault deposit that carries no swap payload, takes its simulation raised to a per-chain floor with no inflation (when it cannot be simulated, that floor plus the intrinsic cost of its memo calldata); a dApp or other contract call keeps 1.5x headroom over its simulation. Base-fee headroom drops from 50% to 20% (32% for swaps), legacy-priced chains (BSC) are priced from `eth_gasPrice` with no tip, and the tip is the highest recent 5th-percentile reward from `eth_feeHistory`, capped at the gas price, with per-chain floors (1 gwei on tip-auction chains, 30 gwei on Polygon, 20 wei on OP-stack rollups) and a zero tip on Arbitrum, Mantle and Robinhood.
+
+  `getEvmFeeQuote`'s `minimumGasLimit` now only raises the value that stands in for a failed simulation and never a successful estimate. `getEvmTransferGasLimit`, `getEvmContractCallGasLimit` and `evmRouterDepositGasLimit` are exported from `@vultisig/core-chain/tx/fee/evm/evmGasLimit`, and `getEvmGasPrice` from `@vultisig/core-chain/tx/fee/evm/gasPrice`.
+
+- [#2328](https://github.com/vultisig/vultisig-sdk/pull/2328) [`741272f`](https://github.com/vultisig/vultisig-sdk/commit/741272f8d3872afdf12d9487d2121dee04c2f363) Thanks [@Ehsan-saradar](https://github.com/Ehsan-saradar)! - Move `slippage_bps` on a native swap quote from the top level into `fees`, where THORChain and MayaChain actually send it.
+
+  `NativeSwapQuote.slippage_bps` was never populated: THORChain's `QuoteSwapResponse` has no such property, and its `QuoteFees` schema declares `slippage_bps` as a required integer. MayaChain's spec agrees. Because the field was optional, every consumer reading it silently got `undefined` rather than a compile error — which is how the price-impact row went missing in the desktop app and extension.
+
+  `NativeSwapFees` now carries `slippage_bps?: number`, and the phantom top-level field is gone so the wrong read cannot compile. This is a type-only change; `getNativeSwapQuote` already spreads the response through verbatim, so no runtime behavior changes.
+
+  Note that `slippage_bps` is the price impact alone and is not interchangeable with the neighbouring `total_bps`, which is the total fee relative to the amount out.
+
+- [#2331](https://github.com/vultisig/vultisig-sdk/pull/2331) [`982d464`](https://github.com/vultisig/vultisig-sdk/commit/982d4645467272f32e33a2df20883c1a7171a7ee) Thanks [@Ehsan-saradar](https://github.com/Ehsan-saradar)! - Publish the SwapKit swap-fee work to the core packages that hold it. [#2315](https://github.com/vultisig/vultisig-sdk/issues/2315) landed
+  `swap_fee` on `SwapKitSwapPayload`, the `getKeysignSwapFeeFields` reader, and the
+  `sub_provider` route tag in `@vultisig/core-mpc`, plus the transfer-route fee
+  resolution in `@vultisig/core-chain` — but its changeset named only
+  `@vultisig/sdk`, so neither core package was versioned and the release skipped
+  both. Clients that consume `@vultisig/core-mpc` directly, rather than through
+  `@vultisig/sdk`, cannot reach the new fee group or its reader until these are
+  republished.
+
+- [#2339](https://github.com/vultisig/vultisig-sdk/pull/2339) [`95cf397`](https://github.com/vultisig/vultisig-sdk/commit/95cf39722b8a4d3e197b26bcef9983ecef6c3703) Thanks [@Ehsan-saradar](https://github.com/Ehsan-saradar)! - feat(solana): verified / unverified / scam classification for SPL tokens, and verified-only discovery
+
+  Solana discovery kept a mint when a price id could be found for it. That hid legitimate tokens that simply had no CoinGecko listing, and did nothing about the airdropped counterfeits and zero-decimal spam a Solana wallet accumulates — a priced impostor was auto-added, an unpriced real token was not, and neither carried a label.
+
+  `findSolanaCoins` now returns **verified mints only**, priced or not, mirroring TON. Zero-balance token accounts are skipped, Jupiter's search endpoint answers for a hundred mints per call instead of one call per token, CoinGecko ids come from its on-chain multi-token endpoint thirty mints per call, decimals come from the token account itself, and curated metadata wins for tokens we ship ourselves. When Jupiter cannot be reached, listed mints are still discovered from the registry's metadata; a failed price-id lookup, by contrast, fails the round instead of saving the token without a price id for good. Unverified and scam mints can still be added by hand, where the UI labels them.
+
+  Verification lives in `@vultisig/core-chain/chains/solana/spl/verification`. The registry of verified mints (`chains/solana/spl/verifiedRegistry`) merges our curated Solana tokens with Jupiter's verified list, fetched once an hour and degrading to the curated list alone when unreachable. `resolveSolanaTokenVerification` is pure: a listed mint — or one Jupiter itself flags verified — is `verified`; an unlisted mint is `scam` when its symbol or name collapses onto a verified token's, and `unverified` otherwise. `getSolanaTokenVerification({ id, ticker })` is the one-call form for token rows and approval cards; a listed mint is answered from the registry alone, any other mint is judged by what it claims on Jupiter, falling back to the local ticker offline. The tiers are the chain-agnostic `TokenVerification` type.
+
+  The symbol normaliser behind the counterfeit heuristic moves to `@vultisig/core-chain/coin/tokenSymbol` as `normalizeTokenSymbol`; `chains/ton/jetton/symbol` keeps exporting `normalizeJettonSymbol` as an alias. `coin/jupiter/api` gains `getJupiterTokens` (batched, keyed by mint, filtered to the mints asked for) and `getJupiterVerifiedTokens`, `SolanaJupiterToken` carries Jupiter's `isVerified` flag and `tags`, and `coin/coingecko/getCoingeckoId` gains the batched `getSolanaCoingeckoIds`. `getSolanaTokenMetadata` now fails with a clear error for a mint Jupiter does not index instead of a `TypeError`.
+
+### Patch Changes
+
+- [#2002](https://github.com/vultisig/vultisig-sdk/pull/2002) [`2e1ed70`](https://github.com/vultisig/vultisig-sdk/commit/2e1ed704ccd0a360eaf760f1258c7cd8a4401e22) Thanks [@gomesalexandre](https://github.com/gomesalexandre)! - Net Solana Blockaid simulation diffs by resolved mint (native SOL and the WSOL mint share a bucket) before classifying the result as a `swap` or `transfer`. The wrap-then-spend case previously surfaced as a bogus "SOL to WSOL swap" whose destination amount was only the token account's rent-exempt residual, at up to ~29x smaller than the amount actually leaving. The reverse unwrap/close-account case now rejects the receive-only result instead of inventing a transfer. The parser now nets same-mint legs and only classifies as a swap when two distinct mints remain.
+
+## 5.2.0
+
+### Minor Changes
+
+- [#2306](https://github.com/vultisig/vultisig-sdk/pull/2306) [`a5def09`](https://github.com/vultisig/vultisig-sdk/commit/a5def098e06cf7269174eb6840dc516d78ec55f9) Thanks [@Ehsan-saradar](https://github.com/Ehsan-saradar)! - feat(ton): explain TON failures in plain language — seqno replay, expired deadline, fees, and the rest
+
+  A TON send that fails today comes back as an opaque `exitcode=133` in a toncenter rejection, or as a bare `error` status with nothing attached. Those two codes — 133 (W5) / 33 (v4) for a replayed seqno and 136 / 36 for an expired `valid_until`, which is almost always a device clock that drifted — dominate TON support load, and the fix is different for each.
+
+  `@vultisig/core-chain/chains/ton/failure` maps a failure to a `TonTxFailure`: a stable `reason` (`seqno-mismatch`, `expired`, `invalid-signature`, `wallet-id-mismatch`, `insufficient-funds`, `out-of-gas`, `invalid-destination`, `not-enough-jettons`, `jetton-unauthorized`, `action-failed`, `action-partially-failed`, `aborted`, `contract-rejected`), the phase it came from, the raw exit code, and an English `message` that says what happened and what to do ("make sure your device's date and time are set automatically, then send it again"; "keep about 0.05 TON spare for fees"). Compute-phase codes cover wallet v3/v4 and W5 alike, the TVM out-of-gas codes and the standard jetton wallet's 705/706 (707 and 709 stay generic: the reference contract reuses each for two unrelated checks); action-phase codes distinguish 36 (invalid destination) from the wallet's 36 (expired), and read 37 as not enough TON. Action code 40 stays generic on purpose: it reads "not enough funds, the message is too large, or its Merkle depth is too big", so it is a funding failure only when the node's own `no_funds` flag backs it, and any other unnamed code is treated the same way.
+
+  A generic action-phase failure only claims "nothing was sent" when the node reports `msgs_created: 0`. Every Vultisig TON send goes out with `IGNORE_ERRORS`, under which a failing action is skipped and the rest still leave, so a batch can lose one transfer and deliver the others — telling that user to retry is how a transfer goes out twice. Without that evidence the failure is `action-partially-failed`, whose message says at least one transfer did not happen, that others may have, and to check the transaction history before sending again.
+
+  `TxStatusResult` gains an optional `failure?: TxFailureInfo` (`reason`, `message`, `exitCode?`, `phase?`), which the TON status resolver now fills for every `error`. `broadcastTonTx` classifies a wallet-contract refusal at broadcast time: the failed result's `cause` is a `TonBroadcastRejectedError` carrying the same `failure`, its `message` is the human explanation, the original toncenter error stays in `cause`, and the refusal is marked non-retryable — resending the same bytes can only be refused again. A seqno refusal whose message is already on chain (a co-signer broadcast first) is still accepted through the existing hash verification. The types, `getTonTxFailure`, `parseTonBroadcastRejection` and `TonBroadcastRejectedError` are re-exported from `@vultisig/sdk`, including its React Native entry — RN broadcasts TON itself and its `broadcastTonTx` rejects with toncenter's raw `exitcode=<n>` text.
+
+- [#2299](https://github.com/vultisig/vultisig-sdk/pull/2299) [`bcca32c`](https://github.com/vultisig/vultisig-sdk/commit/bcca32c885066e2bf224aa37d6666c68a3684956) Thanks [@Ehsan-saradar](https://github.com/Ehsan-saradar)! - feat(ton): W5 (wallet v5r1) support as an explicit per-account opt-in
+
+  Every Vultisig TON account has been hard-pinned to the V4R2 wallet contract. W5 is the default for new wallets in Tonkeeper and Telegram Wallet and is the gateway to what users now expect from TON — up to 255 messages per request instead of 4, lower fees, and relayer-paid ("gasless") transactions. WalletCore has supported it for a while; nothing here used it.
+
+  A W5 wallet is a _different address_ for the same key, with its own balance, so this is not a switch: V4R2 stays the default everywhere and W5 is selected per account.
+
+  - `@vultisig/core-chain/chains/ton/wallet` (new): `TonWalletVersion` (`'v4r2' | 'v5r1'`), `deriveTonAddress` for either contract, `resolveTonWalletVersion` to tell which contract an address is for a key, the W5 mainnet wallet id, and the per-contract message limits.
+  - `vault.setTonWalletVersion('v5r1')` selects which of the key's two TON accounts the vault acts on: `send`, balances, swaps, fee estimation and every other address lookup follow it, so one selected account is used consistently. `vault.address(chain, { tonWalletVersion })` — like `deriveAddress` / `getChainAddress` / `deriveAddressFromKeys` — names a contract for a single lookup without changing the selection, so a client can show both accounts side by side for a migration flow.
+  - Balance cache keys name a chain and an asset, not an account, so switching between the two accounts drops the balance scope and any fetch already in flight for the old account is neither cached nor announced: it still answers its own caller, but `balanceUpdated` carries no account identity, so emitting it after a switch would credit the old account's balance to the new one.
+  - The keysign signing-input resolver derives the contract from the sender address — the payload has no wallet-version field, and every co-signer reaches the same answer from the shared vault key — and refuses an address that is neither of the key's wallets rather than assuming V4R2. W5 requests carry `IGNORE_ACTION_PHASE_ERRORS`, which the W5 code requires of every external action (its replay protection) and WalletCore enforces; the TON status resolver's action-phase check covers the blindness that flag would otherwise cause. Message counts are capped per contract.
+  - The RN-safe builders (`buildTonSendTx`, `buildTonJettonTransferTx`, `buildTonTxFromSigningPayload`, `deriveTonAddress`, `prepareJettonTransferTxFromKeys`) take `walletVersion`; W5 uses the `signed_external` request layout with the signature appended, byte-identical to WalletCore. New `buildV5R1Wallet` / `TON_V5R1_WALLET_ID` alongside the V4R2 helpers.
+
+  Golden vectors (`testdata/cross-encoder-golden/ton-w5-*.json`) pin the W5 pre-images and are verified against real WalletCore, including the full signed external message. Client-side migration UI (show both accounts, move funds, reconnect dApps) is separate work per platform.
+
 ## 5.1.0
 
 ### Minor Changes

package/dist/chains/solana/spl/verification.d.ts

@@ -0,0 +1,38 @@
+import { TokenVerification } from '@vultisig/core-chain/coin/tokenVerification';
+import { SolanaVerifiedTokenRegistry } from './verifiedRegistry.js';
+type ResolveSolanaTokenVerificationInput = {
+    /** Mint address. */
+    address: string;
+    symbol?: string;
+    name?: string;
+    /** Jupiter's own verification flag for the mint, when known. */
+    isVerified?: boolean | null;
+    registry: SolanaVerifiedTokenRegistry;
+};
+/**
+ * Classifies a mint against the verified registry. A listed mint is `verified`
+ * whatever it calls itself, and so is one Jupiter itself marks verified — that
+ * covers a listing newer than the registry's hourly refresh and the degraded,
+ * curated-only registry. An unlisted mint is `scam` when its symbol or name
+ * collapses (see `normalizeTokenSymbol`) onto a verified token's symbol or
+ * name — the fake-USDT pattern, where the counterfeit is only distinguishable
+ * by address. Anything else is `unverified`.
+ */
+export declare const resolveSolanaTokenVerification: ({ address, symbol, name, isVerified, registry, }: ResolveSolanaTokenVerificationInput) => TokenVerification;
+type GetSolanaTokenVerificationInput = {
+    /** Mint address. */
+    id: string;
+    /** Ticker already known locally, used when Jupiter has no entry for the mint. */
+    ticker?: string;
+};
+/**
+ * Verification tier for one mint, for token rows and approval cards. A mint the
+ * registry lists is verified without any further lookup, so a token list full
+ * of legitimate tokens costs no Jupiter calls. For any other mint the symbol
+ * and name are read from Jupiter so a counterfeit is judged by what it actually
+ * claims to be, not by the ticker stored locally; falls back to that ticker
+ * when the lookup fails, so the label still renders offline.
+ */
+export declare const getSolanaTokenVerification: ({ id, ticker, }: GetSolanaTokenVerificationInput) => Promise<TokenVerification>;
+export {};
+//# sourceMappingURL=verification.d.ts.map

package/dist/chains/solana/spl/verification.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"verification.d.ts","sourceRoot":"","sources":["../../../../../../../packages/core/chain/chains/solana/spl/verification.ts"],"names":[],"mappings":"AAEA,OAAO,EAAE,iBAAiB,EAAE,MAAM,6CAA6C,CAAA;AAG/E,OAAO,EAAkC,2BAA2B,EAAE,MAAM,oBAAoB,CAAA;AAEhG,KAAK,mCAAmC,GAAG;IACzC,oBAAoB;IACpB,OAAO,EAAE,MAAM,CAAA;IACf,MAAM,CAAC,EAAE,MAAM,CAAA;IACf,IAAI,CAAC,EAAE,MAAM,CAAA;IACb,gEAAgE;IAChE,UAAU,CAAC,EAAE,OAAO,GAAG,IAAI,CAAA;IAC3B,QAAQ,EAAE,2BAA2B,CAAA;CACtC,CAAA;AAED;;;;;;;;GAQG;AACH,eAAO,MAAM,8BAA8B,GAAI,kDAM5C,mCAAmC,KAAG,iBAUxC,CAAA;AAED,KAAK,+BAA+B,GAAG;IACrC,oBAAoB;IACpB,EAAE,EAAE,MAAM,CAAA;IACV,iFAAiF;IACjF,MAAM,CAAC,EAAE,MAAM,CAAA;CAChB,CAAA;AAED;;;;;;;GAOG;AACH,eAAO,MAAM,0BAA0B,GAAU,iBAG9C,+BAA+B,KAAG,OAAO,CAAC,iBAAiB,CAc7D,CAAA"}

package/dist/chains/solana/spl/verification.js

@@ -0,0 +1,45 @@
+import { getJupiterTokens } from '@vultisig/core-chain/coin/jupiter/api';
+import { normalizeTokenSymbol } from '@vultisig/core-chain/coin/tokenSymbol';
+import { attempt } from '@vultisig/lib-utils/attempt';
+import { getSolanaVerifiedTokenRegistry } from './verifiedRegistry.js';
+/**
+ * Classifies a mint against the verified registry. A listed mint is `verified`
+ * whatever it calls itself, and so is one Jupiter itself marks verified — that
+ * covers a listing newer than the registry's hourly refresh and the degraded,
+ * curated-only registry. An unlisted mint is `scam` when its symbol or name
+ * collapses (see `normalizeTokenSymbol`) onto a verified token's symbol or
+ * name — the fake-USDT pattern, where the counterfeit is only distinguishable
+ * by address. Anything else is `unverified`.
+ */
+export const resolveSolanaTokenVerification = ({ address, symbol, name, isVerified, registry, }) => {
+    if (registry.byAddress[address] || isVerified)
+        return 'verified';
+    const impersonates = [symbol, name].some(label => {
+        const skeleton = label ? normalizeTokenSymbol(label) : '';
+        return !!skeleton && (registry.symbols.has(skeleton) || registry.names.has(skeleton));
+    });
+    return impersonates ? 'scam' : 'unverified';
+};
+/**
+ * Verification tier for one mint, for token rows and approval cards. A mint the
+ * registry lists is verified without any further lookup, so a token list full
+ * of legitimate tokens costs no Jupiter calls. For any other mint the symbol
+ * and name are read from Jupiter so a counterfeit is judged by what it actually
+ * claims to be, not by the ticker stored locally; falls back to that ticker
+ * when the lookup fails, so the label still renders offline.
+ */
+export const getSolanaTokenVerification = async ({ id, ticker, }) => {
+    const registry = await getSolanaVerifiedTokenRegistry();
+    if (registry.byAddress[id])
+        return 'verified';
+    const tokens = await attempt(getJupiterTokens([id]));
+    const token = 'data' in tokens ? tokens.data?.[id] : undefined;
+    return resolveSolanaTokenVerification({
+        address: id,
+        symbol: token?.symbol ?? ticker,
+        name: token?.name,
+        isVerified: token?.isVerified,
+        registry,
+    });
+};
+//# sourceMappingURL=verification.js.map

package/dist/chains/solana/spl/verification.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"verification.js","sourceRoot":"","sources":["../../../../../../../packages/core/chain/chains/solana/spl/verification.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,gBAAgB,EAAE,MAAM,uCAAuC,CAAA;AACxE,OAAO,EAAE,oBAAoB,EAAE,MAAM,uCAAuC,CAAA;AAE5E,OAAO,EAAE,OAAO,EAAE,MAAM,6BAA6B,CAAA;AAErD,OAAO,EAAE,8BAA8B,EAA+B,MAAM,oBAAoB,CAAA;AAYhG;;;;;;;;GAQG;AACH,MAAM,CAAC,MAAM,8BAA8B,GAAG,CAAC,EAC7C,OAAO,EACP,MAAM,EACN,IAAI,EACJ,UAAU,EACV,QAAQ,GAC4B,EAAqB,EAAE;IAC3D,IAAI,QAAQ,CAAC,SAAS,CAAC,OAAO,CAAC,IAAI,UAAU;QAAE,OAAO,UAAU,CAAA;IAEhE,MAAM,YAAY,GAAG,CAAC,MAAM,EAAE,IAAI,CAAC,CAAC,IAAI,CAAC,KAAK,CAAC,EAAE;QAC/C,MAAM,QAAQ,GAAG,KAAK,CAAC,CAAC,CAAC,oBAAoB,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,EAAE,CAAA;QAEzD,OAAO,CAAC,CAAC,QAAQ,IAAI,CAAC,QAAQ,CAAC,OAAO,CAAC,GAAG,CAAC,QAAQ,CAAC,IAAI,QAAQ,CAAC,KAAK,CAAC,GAAG,CAAC,QAAQ,CAAC,CAAC,CAAA;IACvF,CAAC,CAAC,CAAA;IAEF,OAAO,YAAY,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,YAAY,CAAA;AAC7C,CAAC,CAAA;AASD;;;;;;;GAOG;AACH,MAAM,CAAC,MAAM,0BAA0B,GAAG,KAAK,EAAE,EAC/C,EAAE,EACF,MAAM,GAC0B,EAA8B,EAAE;IAChE,MAAM,QAAQ,GAAG,MAAM,8BAA8B,EAAE,CAAA;IACvD,IAAI,QAAQ,CAAC,SAAS,CAAC,EAAE,CAAC;QAAE,OAAO,UAAU,CAAA;IAE7C,MAAM,MAAM,GAAG,MAAM,OAAO,CAAC,gBAAgB,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,CAAA;IACpD,MAAM,KAAK,GAAG,MAAM,IAAI,MAAM,CAAC,CAAC,CAAC,MAAM,CAAC,IAAI,EAAE,CAAC,EAAE,CAAC,CAAC,CAAC,CAAC,SAAS,CAAA;IAE9D,OAAO,8BAA8B,CAAC;QACpC,OAAO,EAAE,EAAE;QACX,MAAM,EAAE,KAAK,EAAE,MAAM,IAAI,MAAM;QAC/B,IAAI,EAAE,KAAK,EAAE,IAAI;QACjB,UAAU,EAAE,KAAK,EAAE,UAAU;QAC7B,QAAQ;KACT,CAAC,CAAA;AACJ,CAAC,CAAA"}

package/dist/chains/solana/spl/verifiedRegistry.d.ts

@@ -0,0 +1,34 @@
+/** A mint we treat as legitimate, keyed by its exact base58 address. */
+export type VerifiedSolanaToken = {
+    address: string;
+    symbol: string;
+    name?: string;
+    decimals?: number;
+    logo?: string;
+};
+/**
+ * Verified mints indexed for the two questions verification asks: "is this
+ * mint listed?" and "does this symbol or name belong to a listed token?".
+ * `symbols` and `names` hold `normalizeTokenSymbol` skeletons. Mints are
+ * case-sensitive base58, so `byAddress` is keyed exactly.
+ */
+export type SolanaVerifiedTokenRegistry = {
+    byAddress: Record<string, VerifiedSolanaToken>;
+    symbols: Set<string>;
+    names: Set<string>;
+};
+/**
+ * Builds a registry from a list of verified tokens. On a mint collision the
+ * earlier entry's metadata is kept in `byAddress`, but every entry's symbol and
+ * name are indexed: two entries for one mint describe the same verified token,
+ * and a counterfeit may copy either spelling.
+ */
+export declare const makeSolanaVerifiedTokenRegistry: (tokens: VerifiedSolanaToken[]) => SolanaVerifiedTokenRegistry;
+/**
+ * The mints we consider verified: our own curated Solana tokens (which win, so
+ * their tickers and logos are kept) merged with Jupiter's verified list.
+ * Degrades to the curated list alone when Jupiter cannot be fetched, so
+ * discovery and labels keep working offline — with fewer tokens recognised.
+ */
+export declare const getSolanaVerifiedTokenRegistry: () => Promise<SolanaVerifiedTokenRegistry>;
+//# sourceMappingURL=verifiedRegistry.d.ts.map

package/dist/chains/solana/spl/verifiedRegistry.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"verifiedRegistry.d.ts","sourceRoot":"","sources":["../../../../../../../packages/core/chain/chains/solana/spl/verifiedRegistry.ts"],"names":[],"mappings":"AAQA,wEAAwE;AACxE,MAAM,MAAM,mBAAmB,GAAG;IAChC,OAAO,EAAE,MAAM,CAAA;IACf,MAAM,EAAE,MAAM,CAAA;IACd,IAAI,CAAC,EAAE,MAAM,CAAA;IACb,QAAQ,CAAC,EAAE,MAAM,CAAA;IACjB,IAAI,CAAC,EAAE,MAAM,CAAA;CACd,CAAA;AAED;;;;;GAKG;AACH,MAAM,MAAM,2BAA2B,GAAG;IACxC,SAAS,EAAE,MAAM,CAAC,MAAM,EAAE,mBAAmB,CAAC,CAAA;IAC9C,OAAO,EAAE,GAAG,CAAC,MAAM,CAAC,CAAA;IACpB,KAAK,EAAE,GAAG,CAAC,MAAM,CAAC,CAAA;CACnB,CAAA;AAED;;;;;GAKG;AACH,eAAO,MAAM,+BAA+B,GAAI,QAAQ,mBAAmB,EAAE,KAAG,2BAc/E,CAAA;AAwCD;;;;;GAKG;AACH,eAAO,MAAM,8BAA8B,QAAa,OAAO,CAAC,2BAA2B,CAO1F,CAAA"}

package/dist/chains/solana/spl/verifiedRegistry.js

@@ -0,0 +1,65 @@
+import { Chain } from '@vultisig/core-chain/Chain';
+import { getJupiterVerifiedTokens } from '@vultisig/core-chain/coin/jupiter/api';
+import { knownTokens } from '@vultisig/core-chain/coin/knownTokens';
+import { normalizeTokenSymbol } from '@vultisig/core-chain/coin/tokenSymbol';
+import { attempt } from '@vultisig/lib-utils/attempt';
+import { memoizeAsync } from '@vultisig/lib-utils/memoizeAsync';
+import { convertDuration } from '@vultisig/lib-utils/time/convertDuration';
+/**
+ * Builds a registry from a list of verified tokens. On a mint collision the
+ * earlier entry's metadata is kept in `byAddress`, but every entry's symbol and
+ * name are indexed: two entries for one mint describe the same verified token,
+ * and a counterfeit may copy either spelling.
+ */
+export const makeSolanaVerifiedTokenRegistry = (tokens) => {
+    const registry = { byAddress: {}, symbols: new Set(), names: new Set() };
+    for (const token of tokens) {
+        registry.byAddress[token.address] ??= token;
+        const symbol = normalizeTokenSymbol(token.symbol);
+        if (symbol)
+            registry.symbols.add(symbol);
+        const name = token.name ? normalizeTokenSymbol(token.name) : '';
+        if (name)
+            registry.names.add(name);
+    }
+    return registry;
+};
+const getCuratedTokens = () => knownTokens[Chain.Solana].flatMap(({ id, ticker, decimals, logo }) => id ? [{ address: id, symbol: ticker, decimals, logo }] : []);
+const fetchJupiterVerifiedTokens = async () => (await getJupiterVerifiedTokens()).flatMap(({ id, symbol, name, decimals, icon }) => {
+    const ticker = symbol.trim();
+    if (!ticker)
+        return [];
+    return [
+        {
+            address: id,
+            symbol: ticker,
+            ...(name ? { name } : {}),
+            ...(typeof decimals === 'number' ? { decimals } : {}),
+            ...(icon ? { logo: icon } : {}),
+        },
+    ];
+});
+// Only a successful fetch is cached: a rejected promise is never stored, so an
+// outage is retried on the next call instead of pinning the degraded registry.
+const getFullRegistry = memoizeAsync(async () => makeSolanaVerifiedTokenRegistry([...getCuratedTokens(), ...(await fetchJupiterVerifiedTokens())]), { cacheTime: convertDuration(1, 'h', 'ms') });
+let curatedRegistry;
+const getCuratedRegistry = () => {
+    if (!curatedRegistry) {
+        curatedRegistry = makeSolanaVerifiedTokenRegistry(getCuratedTokens());
+    }
+    return curatedRegistry;
+};
+/**
+ * The mints we consider verified: our own curated Solana tokens (which win, so
+ * their tickers and logos are kept) merged with Jupiter's verified list.
+ * Degrades to the curated list alone when Jupiter cannot be fetched, so
+ * discovery and labels keep working offline — with fewer tokens recognised.
+ */
+export const getSolanaVerifiedTokenRegistry = async () => {
+    const result = await attempt(getFullRegistry());
+    if ('data' in result && result.data)
+        return result.data;
+    console.warn('[solana] verified token list unavailable; using the curated list only', result.error);
+    return getCuratedRegistry();
+};
+//# sourceMappingURL=verifiedRegistry.js.map

package/dist/chains/solana/spl/verifiedRegistry.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"verifiedRegistry.js","sourceRoot":"","sources":["../../../../../../../packages/core/chain/chains/solana/spl/verifiedRegistry.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,EAAE,MAAM,4BAA4B,CAAA;AAClD,OAAO,EAAE,wBAAwB,EAAE,MAAM,uCAAuC,CAAA;AAChF,OAAO,EAAE,WAAW,EAAE,MAAM,uCAAuC,CAAA;AACnE,OAAO,EAAE,oBAAoB,EAAE,MAAM,uCAAuC,CAAA;AAC5E,OAAO,EAAE,OAAO,EAAE,MAAM,6BAA6B,CAAA;AACrD,OAAO,EAAE,YAAY,EAAE,MAAM,kCAAkC,CAAA;AAC/D,OAAO,EAAE,eAAe,EAAE,MAAM,0CAA0C,CAAA;AAuB1E;;;;;GAKG;AACH,MAAM,CAAC,MAAM,+BAA+B,GAAG,CAAC,MAA6B,EAA+B,EAAE;IAC5G,MAAM,QAAQ,GAAgC,EAAE,SAAS,EAAE,EAAE,EAAE,OAAO,EAAE,IAAI,GAAG,EAAE,EAAE,KAAK,EAAE,IAAI,GAAG,EAAE,EAAE,CAAA;IAErG,KAAK,MAAM,KAAK,IAAI,MAAM,EAAE,CAAC;QAC3B,QAAQ,CAAC,SAAS,CAAC,KAAK,CAAC,OAAO,CAAC,KAAK,KAAK,CAAA;QAE3C,MAAM,MAAM,GAAG,oBAAoB,CAAC,KAAK,CAAC,MAAM,CAAC,CAAA;QACjD,IAAI,MAAM;YAAE,QAAQ,CAAC,OAAO,CAAC,GAAG,CAAC,MAAM,CAAC,CAAA;QAExC,MAAM,IAAI,GAAG,KAAK,CAAC,IAAI,CAAC,CAAC,CAAC,oBAAoB,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,EAAE,CAAA;QAC/D,IAAI,IAAI;YAAE,QAAQ,CAAC,KAAK,CAAC,GAAG,CAAC,IAAI,CAAC,CAAA;IACpC,CAAC;IAED,OAAO,QAAQ,CAAA;AACjB,CAAC,CAAA;AAED,MAAM,gBAAgB,GAAG,GAA0B,EAAE,CACnD,WAAW,CAAC,KAAK,CAAC,MAAM,CAAC,CAAC,OAAO,CAAC,CAAC,EAAE,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE,IAAI,EAAE,EAAE,EAAE,CACnE,EAAE,CAAC,CAAC,CAAC,CAAC,EAAE,OAAO,EAAE,EAAE,EAAE,MAAM,EAAE,MAAM,EAAE,QAAQ,EAAE,IAAI,EAAE,CAAC,CAAC,CAAC,CAAC,EAAE,CAC5D,CAAA;AAEH,MAAM,0BAA0B,GAAG,KAAK,IAAoC,EAAE,CAC5E,CAAC,MAAM,wBAAwB,EAAE,CAAC,CAAC,OAAO,CAAC,CAAC,EAAE,EAAE,EAAE,MAAM,EAAE,IAAI,EAAE,QAAQ,EAAE,IAAI,EAAE,EAAE,EAAE;IAClF,MAAM,MAAM,GAAG,MAAM,CAAC,IAAI,EAAE,CAAA;IAC5B,IAAI,CAAC,MAAM;QAAE,OAAO,EAAE,CAAA;IAEtB,OAAO;QACL;YACE,OAAO,EAAE,EAAE;YACX,MAAM,EAAE,MAAM;YACd,GAAG,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,IAAI,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;YACzB,GAAG,CAAC,OAAO,QAAQ,KAAK,QAAQ,CAAC,CAAC,CAAC,EAAE,QAAQ,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;YACrD,GAAG,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,IAAI,EAAE,IAAI,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;SAChC;KACF,CAAA;AACH,CAAC,CAAC,CAAA;AAEJ,+EAA+E;AAC/E,+EAA+E;AAC/E,MAAM,eAAe,GAAG,YAAY,CAClC,KAAK,IAAI,EAAE,CAAC,+BAA+B,CAAC,CAAC,GAAG,gBAAgB,EAAE,EAAE,GAAG,CAAC,MAAM,0BAA0B,EAAE,CAAC,CAAC,CAAC,EAC7G,EAAE,SAAS,EAAE,eAAe,CAAC,CAAC,EAAE,GAAG,EAAE,IAAI,CAAC,EAAE,CAC7C,CAAA;AAED,IAAI,eAAwD,CAAA;AAE5D,MAAM,kBAAkB,GAAG,GAAgC,EAAE;IAC3D,IAAI,CAAC,eAAe,EAAE,CAAC;QACrB,eAAe,GAAG,+BAA+B,CAAC,gBAAgB,EAAE,CAAC,CAAA;IACvE,CAAC;IAED,OAAO,eAAe,CAAA;AACxB,CAAC,CAAA;AAED;;;;;GAKG;AACH,MAAM,CAAC,MAAM,8BAA8B,GAAG,KAAK,IAA0C,EAAE;IAC7F,MAAM,MAAM,GAAG,MAAM,OAAO,CAAC,eAAe,EAAE,CAAC,CAAA;IAC/C,IAAI,MAAM,IAAI,MAAM,IAAI,MAAM,CAAC,IAAI;QAAE,OAAO,MAAM,CAAC,IAAI,CAAA;IAEvD,OAAO,CAAC,IAAI,CAAC,uEAAuE,EAAE,MAAM,CAAC,KAAK,CAAC,CAAA;IAEnG,OAAO,kBAAkB,EAAE,CAAA;AAC7B,CAAC,CAAA"}

package/dist/chains/ton/failure.d.ts

@@ -0,0 +1,70 @@
+/**
+ * Why a TON transaction did not move funds, in terms a user can act on. The
+ * wallet contract's own checks (`seqno-mismatch`, `expired`, `invalid-signature`,
+ * `wallet-id-mismatch`) fire in the compute phase of the sender's wallet; the
+ * money-related ones fire when the wallet tries to emit the transfer (action
+ * phase) or in the jetton wallet's compute phase.
+ */
+export declare const tonTxFailureReasons: readonly ["seqno-mismatch", "expired", "invalid-signature", "wallet-id-mismatch", "insufficient-funds", "out-of-gas", "invalid-destination", "not-enough-jettons", "jetton-unauthorized", "action-failed", "action-partially-failed", "aborted", "contract-rejected"];
+export type TonTxFailureReason = (typeof tonTxFailureReasons)[number];
+/** Which phase of the TON transaction produced the code: TVM execution or emitting the outgoing messages. */
+export type TonTxPhase = 'compute' | 'action';
+export type TonTxFailure = {
+    reason: TonTxFailureReason;
+    phase: TonTxPhase;
+    exitCode?: number;
+    /** Plain-language explanation with the remedy, in English. */
+    message: string;
+};
+/** Classifies a compute-phase exit code (0 and 1 are success and yield `undefined`). */
+export declare const getTonComputeFailure: (exitCode: number | undefined) => TonTxFailure | undefined;
+type TonActionPhaseOutcome = {
+    success?: boolean;
+    no_funds?: boolean;
+    result_code?: number;
+    skipped_actions?: number;
+    /** Outgoing messages the phase actually produced, when the node reports it. */
+    msgs_created?: number;
+};
+/**
+ * Classifies a failed action phase. A result code the table names wins; an
+ * unnamed one is read as a funding failure only when `no_funds` backs it, and
+ * otherwise stays generic with the code attached. `no_funds` without any code
+ * still means the transfer could not be paid for, and a skipped or unsuccessful
+ * action with neither is generic — worded by `genericActionReason`, which will not
+ * claim nothing was sent unless the node says so.
+ */
+export declare const getTonActionFailure: (action: TonActionPhaseOutcome | undefined) => TonTxFailure | undefined;
+type TonTransactionOutcome = {
+    aborted?: boolean;
+    compute_ph?: {
+        exit_code?: number;
+    };
+    action?: TonActionPhaseOutcome;
+};
+/**
+ * Explains why an indexed TON transaction failed, or `undefined` when it did
+ * not. The compute phase is consulted first because it carries the specific
+ * exit code; an aborted transaction with no readable phase is reported as such.
+ */
+export declare const getTonTxFailure: (description: TonTransactionOutcome) => TonTxFailure | undefined;
+/**
+ * Reads the wallet contract's exit code out of a toncenter `sendBoc` rejection
+ * ("… inbound external message rejected by transaction …: exitcode=133, steps=49,
+ * gas_used=0 …"). The message never reached the chain, so the code is always the
+ * sender's wallet refusing it in its compute phase. Returns `undefined` for
+ * transport errors and any other rejection shape.
+ */
+export declare const parseTonBroadcastRejection: (error: unknown) => TonTxFailure | undefined;
+/**
+ * A TON broadcast the sender's wallet contract refused, with the refusal
+ * classified. `message` is the human-readable explanation so any consumer that
+ * only prints `error.message` already shows the right remedy; the original
+ * toncenter error stays in `cause`.
+ */
+export declare class TonBroadcastRejectedError extends Error {
+    readonly failure: TonTxFailure;
+    constructor(failure: TonTxFailure, cause: unknown);
+}
+export {};
+//# sourceMappingURL=failure.d.ts.map

package/dist/chains/ton/failure.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"failure.d.ts","sourceRoot":"","sources":["../../../../../../packages/core/chain/chains/ton/failure.ts"],"names":[],"mappings":"AAEA;;;;;;GAMG;AACH,eAAO,MAAM,mBAAmB,uQActB,CAAA;AAEV,MAAM,MAAM,kBAAkB,GAAG,CAAC,OAAO,mBAAmB,CAAC,CAAC,MAAM,CAAC,CAAA;AAErE,6GAA6G;AAC7G,MAAM,MAAM,UAAU,GAAG,SAAS,GAAG,QAAQ,CAAA;AAE7C,MAAM,MAAM,YAAY,GAAG;IACzB,MAAM,EAAE,kBAAkB,CAAA;IAC1B,KAAK,EAAE,UAAU,CAAA;IACjB,QAAQ,CAAC,EAAE,MAAM,CAAA;IACjB,8DAA8D;IAC9D,OAAO,EAAE,MAAM,CAAA;CAChB,CAAA;AAsFD,wFAAwF;AACxF,eAAO,MAAM,oBAAoB,GAAI,UAAU,MAAM,GAAG,SAAS,KAAG,YAAY,GAAG,SAIlF,CAAA;AAED,KAAK,qBAAqB,GAAG;IAC3B,OAAO,CAAC,EAAE,OAAO,CAAA;IACjB,QAAQ,CAAC,EAAE,OAAO,CAAA;IAClB,WAAW,CAAC,EAAE,MAAM,CAAA;IACpB,eAAe,CAAC,EAAE,MAAM,CAAA;IACxB,+EAA+E;IAC/E,YAAY,CAAC,EAAE,MAAM,CAAA;CACtB,CAAA;AAeD;;;;;;;GAOG;AACH,eAAO,MAAM,mBAAmB,GAAI,QAAQ,qBAAqB,GAAG,SAAS,KAAG,YAAY,GAAG,SAkB9F,CAAA;AAED,KAAK,qBAAqB,GAAG;IAC3B,OAAO,CAAC,EAAE,OAAO,CAAA;IACjB,UAAU,CAAC,EAAE;QAAE,SAAS,CAAC,EAAE,MAAM,CAAA;KAAE,CAAA;IACnC,MAAM,CAAC,EAAE,qBAAqB,CAAA;CAC/B,CAAA;AAED;;;;GAIG;AACH,eAAO,MAAM,eAAe,GAAI,aAAa,qBAAqB,KAAG,YAAY,GAAG,SAGJ,CAAA;AAIhF;;;;;;GAMG;AACH,eAAO,MAAM,0BAA0B,GAAI,OAAO,OAAO,KAAG,YAAY,GAAG,SAK1E,CAAA;AAED;;;;;GAKG;AACH,qBAAa,yBAA0B,SAAQ,KAAK;aAEhC,OAAO,EAAE,YAAY;gBAArB,OAAO,EAAE,YAAY,EACrC,KAAK,EAAE,OAAO;CAKjB"}

package/dist/chains/ton/failure.js

@@ -0,0 +1,170 @@
+import { extractErrorMsg } from '@vultisig/lib-utils/error/extractErrorMsg';
+/**
+ * Why a TON transaction did not move funds, in terms a user can act on. The
+ * wallet contract's own checks (`seqno-mismatch`, `expired`, `invalid-signature`,
+ * `wallet-id-mismatch`) fire in the compute phase of the sender's wallet; the
+ * money-related ones fire when the wallet tries to emit the transfer (action
+ * phase) or in the jetton wallet's compute phase.
+ */
+export const tonTxFailureReasons = [
+    'seqno-mismatch',
+    'expired',
+    'invalid-signature',
+    'wallet-id-mismatch',
+    'insufficient-funds',
+    'out-of-gas',
+    'invalid-destination',
+    'not-enough-jettons',
+    'jetton-unauthorized',
+    'action-failed',
+    'action-partially-failed',
+    'aborted',
+    'contract-rejected',
+];
+/**
+ * Compute-phase exit codes. The sender's wallet contract throws the first block
+ * from `recv_external`: wallet v3/v4 use 33–36, W5 uses 133–136 for the same
+ * checks. 13 / -14 are the TVM's out-of-gas codes. 705 and 706 come from the
+ * standard jetton wallet (TEP-74) and mean the same thing on a transfer and on
+ * a burn; its 707 and 709 are deliberately absent because the reference
+ * contract reuses each for two unrelated checks (707: unauthorized incoming
+ * transfer, or too little TON on a burn; 709: too little TON on a transfer, or
+ * an unexpected bounced op), and the code alone cannot tell which. Everything
+ * else is a contract-specific revert we can only report by number.
+ */
+const computeExitCodeReasons = {
+    33: 'seqno-mismatch',
+    133: 'seqno-mismatch',
+    34: 'wallet-id-mismatch',
+    134: 'wallet-id-mismatch',
+    35: 'invalid-signature',
+    135: 'invalid-signature',
+    36: 'expired',
+    136: 'expired',
+    13: 'out-of-gas',
+    [-14]: 'out-of-gas',
+    705: 'jetton-unauthorized',
+    706: 'not-enough-jettons',
+};
+/**
+ * Action-phase result codes that mean one thing. 36 here is an invalid destination,
+ * not the wallet's `expired` (36), which can only come from the compute phase. 37 is
+ * "Not enough GRAMs" and says so on its own.
+ *
+ * 40 is deliberately absent. It reads "Cannot process a message — not enough funds,
+ * the message is too large, or its Merkle depth is too big", so naming it a funding
+ * failure would send a user to top up their balance when the payload is what has to
+ * change. Codes like it fall through to `no_funds` below, the only authoritative
+ * funding signal in the phase.
+ */
+const actionResultCodeReasons = {
+    36: 'invalid-destination',
+    37: 'insufficient-funds',
+};
+/**
+ * Human-readable explanations. Each says what happened and what to do; the
+ * remedy matters more than the code, because the two failures that dominate
+ * TON support — a replayed seqno and an expired `valid_until` — both look like
+ * "the network rejected it" and have opposite fixes.
+ */
+const failureMessages = {
+    'seqno-mismatch': 'Another transaction from this wallet was processed first, so the network rejected this one as out of order. Check your history: if this transfer is not there, send it again.',
+    expired: "The transaction's time window closed before the network processed it. Make sure your device's date and time are set automatically, then send it again.",
+    'invalid-signature': 'The wallet contract rejected the signature. Sign the transaction again; if it keeps failing, the wallet contract at this address does not match this vault.',
+    'wallet-id-mismatch': 'The transaction was built for a different wallet contract version than the one deployed at this address.',
+    'insufficient-funds': 'Not enough TON to cover the amount plus network fees. Keep about 0.05 TON spare for fees and try again.',
+    'out-of-gas': 'The transaction ran out of gas before it could finish. Attach more TON to the transfer and try again.',
+    'invalid-destination': 'The destination address is not valid on TON. Check the address and try again.',
+    'not-enough-jettons': 'This wallet does not hold enough of the token to send that amount.',
+    'jetton-unauthorized': 'The token contract refused the transfer because this wallet is not allowed to move these tokens.',
+    'action-failed': 'The wallet accepted the transaction but could not carry out the transfer, so nothing was sent. The network fee was still charged. Check the transaction and try again.',
+    'action-partially-failed': 'The wallet could not carry out at least one transfer in this transaction, and others in it may have gone through. The network fee was still charged. Check your transaction history before sending again.',
+    aborted: 'The network aborted this transaction before it could carry out the transfer.',
+    'contract-rejected': 'The contract rejected the transaction.',
+};
+const describe = (reason, exitCode) => reason === 'contract-rejected' && exitCode !== undefined
+    ? `The contract rejected the transaction (exit code ${exitCode}).`
+    : failureMessages[reason];
+const makeFailure = (reason, phase, exitCode) => ({
+    reason,
+    phase,
+    ...(exitCode === undefined ? {} : { exitCode }),
+    message: describe(reason, exitCode),
+});
+/** Classifies a compute-phase exit code (0 and 1 are success and yield `undefined`). */
+export const getTonComputeFailure = (exitCode) => {
+    if (exitCode === undefined || exitCode === 0 || exitCode === 1)
+        return undefined;
+    return makeFailure(computeExitCodeReasons[exitCode] ?? 'contract-rejected', 'compute', exitCode);
+};
+/**
+ * Which generic explanation a failed action phase gets.
+ *
+ * Under `IGNORE_ERRORS` — the mode every Vultisig TON send uses — a failing action
+ * is skipped and the remaining ones still go out, so a batch can lose one transfer
+ * and deliver the rest. Telling that user nothing was sent and to try again is how a
+ * duplicate transfer happens, so only the node's own `msgs_created: 0` earns the
+ * "nothing was sent" wording. A node that reports nothing proves nothing either way
+ * and gets the neutral explanation, which reads correctly for both outcomes.
+ */
+const genericActionReason = ({ msgs_created }) => msgs_created === 0 ? 'action-failed' : 'action-partially-failed';
+/**
+ * Classifies a failed action phase. A result code the table names wins; an
+ * unnamed one is read as a funding failure only when `no_funds` backs it, and
+ * otherwise stays generic with the code attached. `no_funds` without any code
+ * still means the transfer could not be paid for, and a skipped or unsuccessful
+ * action with neither is generic — worded by `genericActionReason`, which will not
+ * claim nothing was sent unless the node says so.
+ */
+export const getTonActionFailure = (action) => {
+    if (!action)
+        return undefined;
+    const { success, no_funds, result_code, skipped_actions } = action;
+    if (result_code !== undefined && result_code !== 0) {
+        // A code the table does not name is a funding failure only when the node says so.
+        const reason = actionResultCodeReasons[result_code] ?? (no_funds === true ? 'insufficient-funds' : genericActionReason(action));
+        return makeFailure(reason, 'action', result_code);
+    }
+    if (no_funds === true)
+        return makeFailure('insufficient-funds', 'action');
+    if (success === false || (skipped_actions ?? 0) > 0)
+        return makeFailure(genericActionReason(action), 'action');
+    return undefined;
+};
+/**
+ * Explains why an indexed TON transaction failed, or `undefined` when it did
+ * not. The compute phase is consulted first because it carries the specific
+ * exit code; an aborted transaction with no readable phase is reported as such.
+ */
+export const getTonTxFailure = (description) => getTonComputeFailure(description.compute_ph?.exit_code) ??
+    getTonActionFailure(description.action) ??
+    (description.aborted === true ? makeFailure('aborted', 'compute') : undefined);
+const rejectionExitCodePattern = /exitcode=(-?\d+)/i;
+/**
+ * Reads the wallet contract's exit code out of a toncenter `sendBoc` rejection
+ * ("… inbound external message rejected by transaction …: exitcode=133, steps=49,
+ * gas_used=0 …"). The message never reached the chain, so the code is always the
+ * sender's wallet refusing it in its compute phase. Returns `undefined` for
+ * transport errors and any other rejection shape.
+ */
+export const parseTonBroadcastRejection = (error) => {
+    const match = rejectionExitCodePattern.exec(String(extractErrorMsg(error)));
+    if (!match)
+        return undefined;
+    return getTonComputeFailure(Number(match[1]));
+};
+/**
+ * A TON broadcast the sender's wallet contract refused, with the refusal
+ * classified. `message` is the human-readable explanation so any consumer that
+ * only prints `error.message` already shows the right remedy; the original
+ * toncenter error stays in `cause`.
+ */
+export class TonBroadcastRejectedError extends Error {
+    failure;
+    constructor(failure, cause) {
+        super(failure.message, { cause });
+        this.failure = failure;
+        this.name = 'TonBroadcastRejectedError';
+    }
+}
+//# sourceMappingURL=failure.js.map

package/dist/chains/ton/failure.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"failure.js","sourceRoot":"","sources":["../../../../../../packages/core/chain/chains/ton/failure.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,eAAe,EAAE,MAAM,2CAA2C,CAAA;AAE3E;;;;;;GAMG;AACH,MAAM,CAAC,MAAM,mBAAmB,GAAG;IACjC,gBAAgB;IAChB,SAAS;IACT,mBAAmB;IACnB,oBAAoB;IACpB,oBAAoB;IACpB,YAAY;IACZ,qBAAqB;IACrB,oBAAoB;IACpB,qBAAqB;IACrB,eAAe;IACf,yBAAyB;IACzB,SAAS;IACT,mBAAmB;CACX,CAAA;AAeV;;;;;;;;;;GAUG;AACH,MAAM,sBAAsB,GAAuC;IACjE,EAAE,EAAE,gBAAgB;IACpB,GAAG,EAAE,gBAAgB;IACrB,EAAE,EAAE,oBAAoB;IACxB,GAAG,EAAE,oBAAoB;IACzB,EAAE,EAAE,mBAAmB;IACvB,GAAG,EAAE,mBAAmB;IACxB,EAAE,EAAE,SAAS;IACb,GAAG,EAAE,SAAS;IACd,EAAE,EAAE,YAAY;IAChB,CAAC,CAAC,EAAE,CAAC,EAAE,YAAY;IACnB,GAAG,EAAE,qBAAqB;IAC1B,GAAG,EAAE,oBAAoB;CAC1B,CAAA;AAED;;;;;;;;;;GAUG;AACH,MAAM,uBAAuB,GAAuC;IAClE,EAAE,EAAE,qBAAqB;IACzB,EAAE,EAAE,oBAAoB;CACzB,CAAA;AAED;;;;;GAKG;AACH,MAAM,eAAe,GAAuC;IAC1D,gBAAgB,EACd,+KAA+K;IACjL,OAAO,EACL,wJAAwJ;IAC1J,mBAAmB,EACjB,6JAA6J;IAC/J,oBAAoB,EAClB,0GAA0G;IAC5G,oBAAoB,EAClB,yGAAyG;IAC3G,YAAY,EAAE,uGAAuG;IACrH,qBAAqB,EAAE,+EAA+E;IACtG,oBAAoB,EAAE,oEAAoE;IAC1F,qBAAqB,EACnB,kGAAkG;IACpG,eAAe,EACb,wKAAwK;IAC1K,yBAAyB,EACvB,2MAA2M;IAC7M,OAAO,EAAE,8EAA8E;IACvF,mBAAmB,EAAE,wCAAwC;CAC9D,CAAA;AAED,MAAM,QAAQ,GAAG,CAAC,MAA0B,EAAE,QAA4B,EAAU,EAAE,CACpF,MAAM,KAAK,mBAAmB,IAAI,QAAQ,KAAK,SAAS;IACtD,CAAC,CAAC,oDAAoD,QAAQ,IAAI;IAClE,CAAC,CAAC,eAAe,CAAC,MAAM,CAAC,CAAA;AAE7B,MAAM,WAAW,GAAG,CAAC,MAA0B,EAAE,KAAiB,EAAE,QAAiB,EAAgB,EAAE,CAAC,CAAC;IACvG,MAAM;IACN,KAAK;IACL,GAAG,CAAC,QAAQ,KAAK,SAAS,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,EAAE,QAAQ,EAAE,CAAC;IAC/C,OAAO,EAAE,QAAQ,CAAC,MAAM,EAAE,QAAQ,CAAC;CACpC,CAAC,CAAA;AAEF,wFAAwF;AACxF,MAAM,CAAC,MAAM,oBAAoB,GAAG,CAAC,QAA4B,EAA4B,EAAE;IAC7F,IAAI,QAAQ,KAAK,SAAS,IAAI,QAAQ,KAAK,CAAC,IAAI,QAAQ,KAAK,CAAC;QAAE,OAAO,SAAS,CAAA;IAEhF,OAAO,WAAW,CAAC,sBAAsB,CAAC,QAAQ,CAAC,IAAI,mBAAmB,EAAE,SAAS,EAAE,QAAQ,CAAC,CAAA;AAClG,CAAC,CAAA;AAWD;;;;;;;;;GASG;AACH,MAAM,mBAAmB,GAAG,CAAC,EAAE,YAAY,EAAyB,EAAsB,EAAE,CAC1F,YAAY,KAAK,CAAC,CAAC,CAAC,CAAC,eAAe,CAAC,CAAC,CAAC,yBAAyB,CAAA;AAElE;;;;;;;GAOG;AACH,MAAM,CAAC,MAAM,mBAAmB,GAAG,CAAC,MAAyC,EAA4B,EAAE;IACzG,IAAI,CAAC,MAAM;QAAE,OAAO,SAAS,CAAA;IAE7B,MAAM,EAAE,OAAO,EAAE,QAAQ,EAAE,WAAW,EAAE,eAAe,EAAE,GAAG,MAAM,CAAA;IAElE,IAAI,WAAW,KAAK,SAAS,IAAI,WAAW,KAAK,CAAC,EAAE,CAAC;QACnD,kFAAkF;QAClF,MAAM,MAAM,GACV,uBAAuB,CAAC,WAAW,CAAC,IAAI,CAAC,QAAQ,KAAK,IAAI,CAAC,CAAC,CAAC,oBAAoB,CAAC,CAAC,CAAC,mBAAmB,CAAC,MAAM,CAAC,CAAC,CAAA;QAElH,OAAO,WAAW,CAAC,MAAM,EAAE,QAAQ,EAAE,WAAW,CAAC,CAAA;IACnD,CAAC;IAED,IAAI,QAAQ,KAAK,IAAI;QAAE,OAAO,WAAW,CAAC,oBAAoB,EAAE,QAAQ,CAAC,CAAA;IAEzE,IAAI,OAAO,KAAK,KAAK,IAAI,CAAC,eAAe,IAAI,CAAC,CAAC,GAAG,CAAC;QAAE,OAAO,WAAW,CAAC,mBAAmB,CAAC,MAAM,CAAC,EAAE,QAAQ,CAAC,CAAA;IAE9G,OAAO,SAAS,CAAA;AAClB,CAAC,CAAA;AAQD;;;;GAIG;AACH,MAAM,CAAC,MAAM,eAAe,GAAG,CAAC,WAAkC,EAA4B,EAAE,CAC9F,oBAAoB,CAAC,WAAW,CAAC,UAAU,EAAE,SAAS,CAAC;IACvD,mBAAmB,CAAC,WAAW,CAAC,MAAM,CAAC;IACvC,CAAC,WAAW,CAAC,OAAO,KAAK,IAAI,CAAC,CAAC,CAAC,WAAW,CAAC,SAAS,EAAE,SAAS,CAAC,CAAC,CAAC,CAAC,SAAS,CAAC,CAAA;AAEhF,MAAM,wBAAwB,GAAG,mBAAmB,CAAA;AAEpD;;;;;;GAMG;AACH,MAAM,CAAC,MAAM,0BAA0B,GAAG,CAAC,KAAc,EAA4B,EAAE;IACrF,MAAM,KAAK,GAAG,wBAAwB,CAAC,IAAI,CAAC,MAAM,CAAC,eAAe,CAAC,KAAK,CAAC,CAAC,CAAC,CAAA;IAC3E,IAAI,CAAC,KAAK;QAAE,OAAO,SAAS,CAAA;IAE5B,OAAO,oBAAoB,CAAC,MAAM,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;AAC/C,CAAC,CAAA;AAED;;;;;GAKG;AACH,MAAM,OAAO,yBAA0B,SAAQ,KAAK;IAEhC;IADlB,YACkB,OAAqB,EACrC,KAAc;QAEd,KAAK,CAAC,OAAO,CAAC,OAAO,EAAE,EAAE,KAAK,EAAE,CAAC,CAAA;QAHjB,YAAO,GAAP,OAAO,CAAc;QAIrC,IAAI,CAAC,IAAI,GAAG,2BAA2B,CAAA;IACzC,CAAC;CACF"}

package/dist/chains/ton/jetton/symbol.d.ts

@@ -1,9 +1,7 @@
 /**
- * Collapses a jetton symbol or name to the Latin skeleton a user perceives, so
- * `USD₮`, `UЅDT` (Cyrillic Ѕ), `$USĐ₮` and `usdt` all compare equal to `USDT`.
- * Compatibility decomposition folds full-width and mathematical letter forms,
- * diacritics are dropped, known homoglyphs are mapped, and everything that is
- * not `A–Z`/`0–9` is removed. Returns an empty string when nothing survives.
+ * Jetton-named alias of the chain-agnostic `normalizeTokenSymbol`, kept so
+ * importers of this subpath keep working. New code should import the shared
+ * normalizer from `coin/tokenSymbol` directly.
  */
 export declare const normalizeJettonSymbol: (value: string) => string;
 //# sourceMappingURL=symbol.d.ts.map

package/dist/chains/ton/jetton/symbol.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"symbol.d.ts","sourceRoot":"","sources":["../../../../../../../packages/core/chain/chains/ton/jetton/symbol.ts"],"names":[],"mappings":"AAmDA;;;;;;GAMG;AACH,eAAO,MAAM,qBAAqB,GAAI,OAAO,MAAM,KAAG,MAIxB,CAAA"}
+{"version":3,"file":"symbol.d.ts","sourceRoot":"","sources":["../../../../../../../packages/core/chain/chains/ton/jetton/symbol.ts"],"names":[],"mappings":"AAEA;;;;GAIG;AACH,eAAO,MAAM,qBAAqB,2BAAuB,CAAA"}