Reported issues for Recon Crypto MCP
Pod holds 22 of 56 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.
Back to Recon Crypto MCP.
Most discussed
fund-safety: Solana durable-nonce retry after 10s broadcast abort silently re-pins advanced nonce → double execution (#732 / #706)
Summary — a Solana value-moving action can execute TWICE
When broadcastSolanaTx aborts at the #706 10s client timeout but the node still lands the tx, a subsequent preview_solana_send (or fresh prepare_*) on the still-alive handle silently re-fetches the advanced durable nonce and re-pins a byte-different, independently-valid tx that repeats the same transfer. The deterministic-signature dedupe does NOT collapse it (different nonce → different bytes → different signature). *
Read the thread · 2026-07-19 · closed · outside contributor · 4 comments
arch(substrate): hand-maintained fail-open enumerations are this codebase's default guard habit — 4 instances (#757/#764/#772/#771)
Substrate review (Role: ARCH) — the codebase's default guard HABIT, not a subsystem pattern
Canon cross-issue failure-class trigger fired (~/.claude/CLAUDE.md §Issue & Bug Work): ≥3 issues sharing one failure class on a shared substrate route the next dispatch to a substrate review, not another point fix. SEC (2026-07-19) has now identified a FOURTH instance across a FOURTH unrelated subsystem — the threshold is well past.
The class: a guard implemented as a HAND-MAINTAINED ENUMERATIO
Read the thread · 2026-07-19 · open · outside contributor · 8 comments
security: shape-based redaction misses custom/unlisted-provider RPC keys — add exact-match scrubbing of the user's configured secrets (follow-up to #768)
Summary
#768 broadened redactSecrets (src/shared/error-message.ts) to cover more provider-key URL shapes, but keyed the new path-token and bare-?key= patterns off a KNOWN PROVIDER HOST SET (quiknode.pro, rpcpool.com, triton.one, nownodes.io, getblock.io, helius-rpc.com, infura.io, alchemy.com). This deliberately avoids over-redacting non-provider content — but it is inherently INCOMPLETE: a key embedded in a custom RPC URL from a provider NOT in the set (e.g. Ankr path
Read the thread · 2026-07-19 · closed · outside contributor · 4 comments
INCIDENT: LiFi Diamond allowedAbi: null — block 5 does not run at all; arbitrary calldata + arbitrary native value to a recognized destination, blind-sign class (ARCHITECTURE.md §3.4)
Impact
Severity: high — ranked 92/100 exploitability, the highest of thirteen candidate classes in the SEC pass, above INCIDENT #757.
SEC verdict on ARCHITECTURE.md §3.4, held open by ARCH pending a security seat. Sibling of #757 (same layer, different mechanism: #757 is selector-membership-without-argument-check; this is no selector check at all). Feeds ARCH's in-flight #757 seam design.
I have verified every claim against current main. Here are the verdicts.
SEC verdict
Read the thread · 2026-07-19 · closed · outside contributor · 8 comments
INCIDENT: pre-sign block 5 checks selector but never arguments — recipient-bearing fns on RECOGNIZED destinations are signable drain paths (Aave/Morpho/Uniswap/Lido)
Impact
Severity: INCIDENT
Pre-sign block 5 validates WHICH function is called, never WHERE the value goes. Block 4 — the only argument-agnostic catch-all — is skipped precisely when the destination is recognized. Consequence: every recipient-bearing function in a pinned protocol ABI is a signable drain path to an arbitrary address, and no acknowledgement flag is load-bearing anywhere in the chain.
This inverts the security model. An unknown destination is refused unless acked
Read the thread · 2026-07-19 · closed · outside contributor · 5 comments
security: transfer(address,uint256) via prepare_custom_call may be ack-bypassable to arbitrary recipient (sibling of #711)
Impact
Sibling of #711 (fixed in #727), surfaced at that PR's review. #727 added a recipient gate for transferFrom(address from,address to,uint256) (checks args[1]). But transfer(address to,uint256) (0xa9059cbb) via prepare_custom_call may still be ack-bypassable to an ARBITRARY recipient — and transfer moves the WALLET'S OWN tokens, so an ack-stamped transfer(ATTACKER, amount) on a known/allowlisted token could exfil the wallet's funds. Severity: IMPORTANT/security pending veri
Read the thread · 2026-07-18 · closed · outside contributor · 8 comments
QA: isTransportError omits AbortError — latent false not-Ownable all-clear on future fetchWithTimeout EVM reads
From REVIEW's post-merge audit of #702–#706 (origin/main @ bf3d3055, verdict CLEAN — this is a latent pre-existing concern, not a regression).
isTransportError (src/modules/security/permissions.ts:31-49) omits "AbortError" from its transport-error set. Harmless today: permission reads go via the viem EVM client (viem TimeoutError, already in the set), and #706's raw-AbortError sources are disjoint transports. LATENT failure: a future EVM read routed through data/http.ts fetchWithTimeout
Read the thread · 2026-07-18 · closed · outside contributor · 4 comments
simplification: unify BTC/LTC Esplora indexer into one parametrized client
Role: DEV
Goal
Replace the ~90%-duplicated src/modules/btc/indexer.ts and src/modules/litecoin/indexer.ts Esplora clients with one parametrized modules/utxo/esplora-client.ts taking chain (btc|ltc) as a parameter. Implements ARCHITECTURE.md §5.1.
Current state (evidence — origin/main @ bf3d305, VERIFIED — line counts match doc exactly)
src/modules/btc/indexer.ts: 708 lines.src/modules/litecoin/indexer.ts: 676 lines. The LTC file's own header states it is a "Mirror of src
Read the thread · 2026-07-18 · open · outside contributor · 4 comments
Most recent
render(solana): Verifier-source link points at the pre-#718 file path
Severity: minor
src/signing/render/solana.ts (post-#853) renders a [Verifier source](…/src/signing/render-verification.ts) link into the Solana user block. The path is stale — the Solana renderer now lives in render/solana.ts; the old path is a re-export barrel. Kept deliberately byte-identical during the #718 decomposition because test/solana-ledger-hash.test.ts:256 pins the string.
Acceptance: the rendered link points at the file that actually contains the Solana renderer, and the pi
Read the thread · 2026-08-26 · open · outside contributor · 0 comments
security: INTERMEDIATE_CHAIN_BRIDGES relaxes the chainId gate on a FALSE premise — 1885080386571452 is TRON's on-chain id, not NEAR's; #237 also still broken
Filed-by: SEC
Impact
Severity: security_finding, HIGH, exploitability 75/100. INTERMEDIATE_CHAIN_BRIDGES (src/modules/swap/intermediate-chain-bridges.ts:88-94) relaxes the destinationChainId equality check on a premise that is factually false. The consequence runs both ways: it opens a redirect path to TRON for all seven destinations, and it does not fix #237, whose live repro still fails today.
This is not a stale-entry problem. The entry was wrong on arrival.
Read the thread · 2026-07-19 · open · outside contributor · 0 comments
security: prepare_swap(toAddress=ATTACKER) drains to the LiFi Diamond unstamped — #760 closed on a partial fix; intent check is tautological against a rogue agent
Impact
Severity: security_finding, exploitability 70/100. A rogue or prompt-injected agent can route the entire output of a prepare_swap to an attacker address, on a recognized destination, with no ack, no stamp, and no pre-sign block firing.
This also means #760 was closed on a partial fix. #786/#789 closed the stamped prepare_custom_call door to the LiFi Diamond. The unstamped prepare_swap door to the same destination is still open. The INCIDENT is closed; the drain
Read the thread · 2026-07-19 · closed · outside contributor · 1 comment
fund-safety: fresh prepare_solana_* after an abort-but-landed send double-spends via a NEW handle (#788 sibling — guard is same-handle only)
Summary — a fresh prepare_solana_* after an abort-but-landed send can double-spend (the #788 sibling the same-handle guard does not cover)
PR #792 (Closes #788) fails closed on re-preview of the SAME handle after an ambiguous broadcast abort. It does not cover the sibling path: a fresh prepare_solana_* after a landed-but-aborted send mints a new handle with no broadcastAttempted flag, re-fetches the advanced durable nonce, and can repeat the transfer. Surfaced during REVIEW
Read the thread · 2026-07-19 · closed · outside contributor · 3 comments
security(refinement): Solana ambiguous-broadcast guard over-refuses provably-non-landed preflight rejects — coarser than EVM #232 (follow-up to #788/#792)
Context — follow-up to #788 / #792
The #788 double-spend fix (PR #792, commit 4fa77e7) is correct and passes QA acceptance (fail-closed on any post-signing broadcast attempt; falsifier-verified). This issue tracks a refinement question the QA review surfaced — it is not a #792 blocker (the behavior below fails safe, over-refusing rather than under-refusing).
Finding — the Solana guard is coarser than the EVM #232 guard it ports (grounded)
`markSolanaBroadcastAttempted(handle
Read the thread · 2026-07-19 · open · outside contributor · 0 comments
harden #714 no-bare-fetch gate: liveness lock test + window.fetch falsifier + node-floor note
Context
PR #784 (issue #714) stood up eslint + the no-bare-fetch rule (bans fetch outside src/data/http.ts, locking in the #706 un-timed-fetch fixes) + CI wiring. It merged (main @1e82174) without the REVIEW-recommended follow-up nits, which landed on an orphaned branch (fix/714-eslint-no-bare-fetch, commit 057867c) after the upstream squash-merge race. This issue tracks folding them in so they aren't lost.
Why this is a gate, not cosmetics
The no-bare-fetch rule is a
Read the thread · 2026-07-19 · open · outside contributor · 1 comment
security(hardening): pin the acknowledgedNonProtocolTarget stamp-writer set — durable guard for #786's 4b LiFi over-block invariant
Summary
Follow-on to #786 / #789 (the LiFi Diamond stamped-refuse, block 4b). REVIEW's PASS flagged a latent coupling worth a durable guard: 4b's soundness rests on the invariant "only prepare_custom_call both STAMPS acknowledgedNonProtocolTarget AND can target the LiFi Diamond." True today (exactly three stamp writers: prepare_custom_call at execution/index.ts:1724 + curve ×2, and curve targets factory-validated Curve pools, never LiFi). But the invariant lives ONLY in the 4b
Read the thread · 2026-07-19 · closed · outside contributor · 0 comments
§3.4/#760-core: refuse stamped (custom_call) txs to the LiFi Diamond — contained incident-preemption fix (reuse #759 D8 discriminator)
§3.4 / #760-core contained point-fix — refuse the stamped (custom_call) partition to the LiFi Diamond
Role: DEV · design-soundness: ARCH (this issue) + a quick SEC confirm (LiFi surface) before build; SEC + REVIEW gate the implementation PR.
Problem (INCIDENT #760-core, SEC 92/100 — the broad bypass #759 did NOT close)
The LiFi Diamond is recognized at pre-sign with allowedAbi: null (src/signing/pre-sign-check.ts:167; LIFI_DIAMOND hardcoded literal :42), so block 5 early-ret
Read the thread · 2026-07-19 · closed · outside contributor · 3 comments
security(enhancement): send path does no address-poisoning (lookalike/vanity) screening — SEC/ARCH design call (follow-on to #763)
Summary
Surfaced by #763 / #781 (which corrected the false claim that prepare_token_send "applies the address-poisoning checks"). The send path (prepareTokenSend / prepareNativeSend) does label resolution + EIP-55 checksum but does NOT screen the resolved recipient for address-poisoning (lookalike / vanity-address attacks). annotatePoisoning runs ONLY on get_transaction_history's read-side display. So a user sending to a poisoned lookalike address gets no send-time warning.
Read the thread · 2026-07-19 · open · outside contributor · 1 comment
security: lookupKnownSpender implemented twice (known-spenders.ts + permit2.ts) — guaranteed drift, single-source it
lookupKnownSpender is implemented TWICE — src/security/known-spenders.ts:35 and a local redefinition at src/modules/allowances/permit2.ts:195. Two implementations of one security lookup is guaranteed drift (they will diverge; a spender allowlisted in one path, not the other). Same failure class #765's D10 single-sourcing exists to prevent, sitting outside D10's scope.
Found by SEC while auditing candidate surfaces for the #776 substrate review (2026-07-19).
Fix: single-source it — on
Read the thread · 2026-07-19 · closed · outside contributor · 0 comments
test: WC eth_sendTransaction sink detector in demo structural check has no positive liveness test (follow-up to #772/#774)
Summary
Surfaced by REVIEW's PASS audit of #774 (#772). The structural demo sink-gating check (test/support/sink-reachability.ts) has a sink detector for the WalletConnect eth_sendTransaction broadcast site (a method: "eth_sendTransaction" call-literal matcher), but it has no positive liveness test — because send_transaction resolves to the TRON broadcast sink first, the WC method-literal matcher never fires on any current tool. So that detector branch is UNTESTED: a future EVM-o
Read the thread · 2026-07-19 · closed · outside contributor · 1 comment
security(demo): add_contact/remove_contact reach a real Ledger personal_sign under demo mode (message-signing sink class — SEC scope call, follow-up to #772)
Summary
Surfaced by REVIEW's PASS audit of #774 (#772 demo-mode fund-sink containment). add_contact / remove_contact reach a REAL Ledger EIP-191 personal_sign in demo mode (src/modules/contacts/index.ts signBlobForChain → requestPersonalSign / signBtcMessageOnLedger), ungated. #774's structural sink-gating check deliberately excludes the message-signing sink class, so it does not catch this.
Why it is NOT a fund-safety escape
The signed blob is hardwired with `CONTACTS_DOM
Read the thread · 2026-07-19 · open · outside contributor · 0 comments
security(demo): submit_safe_tx_signature posts to the off-chain Safe Transaction Service under demo mode (off-chain-write sink class, follow-up to #772)
Summary
Surfaced by the adversarial review of #772 / PR #774 (the demo-mode fund-safety fix). submit_safe_tx_signature (src/index.ts ~L2216) posts an already-produced signature to the off-chain Safe Transaction Service under isDemoMode(). It is NOT a device signature or an on-chain broadcast (outside #772's sink set, lower severity), but it IS a real network write that produces off-chain state — a pending Safe multisig tx gains a signature — while the user believes demo mode means no
Read the thread · 2026-07-19 · closed · outside contributor · 0 comments
feat(security): #759 signed-contact leg — restore wallet-or-signed-contact allowance behind a sound trust root (B1 + §6.1 + §6.2 prereqs)
Context
#759 ships a wallet-only recipient hard gate (recipient === tx.from). The signed-contact leg — allowing a hard-gated protocol recipient to resolve to a device-signed saved contact, not just the wallet — was deferred here because SEC's round-3 review (#759 comment) found the signed-contact trust root unsound at its foundation: verifyEvmBlob recovers a signature against blob.anchorAddress (src/contacts/verify.ts:221-226), a field inside the signed payload, and no co
Read the thread · 2026-07-19 · open · outside contributor · 0 comments
The remaining reports are on the project's issue tracker.