Wallet security checks are simulated: risk scores derive from address hex and scam checks always return false

[nanaf6203-bit]

Wallet security checks are simulated: risk scores derive from address hex and scam checks always return false

Labels / Complexity: bug · security · High Complexity — High

Problem

The wallet-security layer in src/utils/security/ presents fabricated results as real security signals. Verified examples:

• blockchainSecurity.ts line 381 simulateAddressRiskCheck — "Simulates address risk check (placeholder for real API)": it derives a deterministic fake score from the address's hex characters (// Parse first 8 hex chars as a 32-bit integer, then mod 100 for a 0–99 score), with the comment "useful for testing/demo purposes".
• walletValidator.ts line 459 hasSimilarityToKnownAddresses — always return false ("placeholder implementation").
• walletValidator.ts line 468 isKnownScamContract — checks against an empty hardcoded list (const knownScamContracts: string[] = [ // Add known scam contract addresses ]), so it always returns false.
• transactionMonitor.ts line 484 isSuspiciousAddress — // For now, return false as placeholder.

These feed the UI through src/hooks/useSecurity.ts and src/components/security/WalletAddressInput.tsx. Consequences:

• Users are shown risk scores and warnings that are fiction. A "73/100 risk" label on an address is just hexToInt(address) % 100; two different checks that claim to detect scams can never fire.
• The security UI creates false confidence. The presence of a risk badge implies screening happened; it did not, and users may rely on it (e.g. before approving a transfer) exactly when they should not.
• The failure is silent by design. Everything returns successfully with plausible-looking values, so nothing in tests or typechecking flags that the checks are stubs.

Root cause

src/utils/security/blockchainSecurity.ts (simulateAddressRiskCheck, line 381), walletValidator.ts (hasSimilarityToKnownAddresses, isKnownScamContract, lines 459/468), and transactionMonitor.ts (isSuspiciousAddress, line 484) — placeholder implementations that return deterministic/fixed values.

Why this is architecturally hard

1. The real integrations do not exist. Genuine address-risk and scam screening requires a data provider (chainalysis-style API, blocklist service, or on-chain heuristics). The contributor must decide what the product can actually ship: a real provider integration, an on-chain heuristic (e.g. token-symbol/age checks), or explicit removal of the fake checks so the UI never implies screening exists.
2. The UI contract must be redone. WalletAddressInput/useSecurity consume the fabricated scores; if real checks are unavailable, the UI must show "unverified" instead of a fake number — a UX change, not just a backend swap.
3. Tests currently pin the fiction. Any existing tests for these utils assert the deterministic values; they must be rewritten to assert the new (real or absent) behavior. Check src/utils/security/__tests__/ before assuming none exist.

Acceptance criteria

• No code path derives a risk score from the address's hex characters; simulateAddressRiskCheck is either backed by a real check or removed.
• isKnownScamContract/hasSimilarityToKnownAddresses/isSuspiciousAddress either implement real screening or are removed, and no UI element claims to have performed those checks.
• The UI shows an explicit "not verified" state where checks do not run, instead of a fabricated score.
• Tests cover the new behavior (a real check's pass/fail, or the absence of the fake score in the UI state).
• npm run typecheck, npm test, and npm run lint pass.

Out of scope

Choosing and integrating a specific third-party risk API (a separate service decision) is out of scope; this issue is about stopping the simulation and defining the honest fallback.

Getting started

• src/utils/security/blockchainSecurity.ts — simulateAddressRiskCheck (line 381)
• src/utils/security/walletValidator.ts — lines 459, 468
• src/utils/security/transactionMonitor.ts — line 484
• src/hooks/useSecurity.ts, src/components/security/WalletAddressInput.tsx — the consumers

Commands: npm run typecheck, npm test, npm run lint.

Good first files to read: src/utils/security/blockchainSecurity.ts, src/hooks/useSecurity.ts.

[chiemezie1]

@chiemezie1 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi, I'd like to work on this issue.

I've gone through the requirements, understand the problem, and have the skills needed to implement a solution.

Could you please assign it to me?

ℹ️ Repo Maintainers: To accept this application, review their application or assign @chiemezie1 to this issue.

[amossamuel851-tech]

@amossamuel851-tech has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi maintainer may I fix this issue please

ℹ️ Repo Maintainers: To accept this application, review their application or assign @amossamuel851-tech to this issue.

[victor-134]

@victor-134 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi, I can implement this Asap Kindly assign to me

ℹ️ Repo Maintainers: To accept this application, review their application or assign @victor-134 to this issue.

[drips-wave]

Congratulations, @amossamuel851-tech! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @amossamuel851-tech: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊

[drips-wave]

This issue has been completed by @amossamuel851-tech as part of the Stellar Wave Program's 8th Wave 🥳

😎 @amossamuel851-tech: You earned 200 Points for completing this issue! After the current Wave ends, you'll be eligible for a percentage of the Wave's reward pool based on the percentage of total points you've earned. Learn more here. You can also Leave a review to share your experience working on this issue.

🧑‍💻 Repo maintainers: How'd the contributor do? Leave a review to share your experience working with them.