Blockchain verification returns simulated data: verifyBlockchainTransaction fabricates block numbers and addresses

[nanaf6203-bit]

Blockchain verification returns simulated data: verifyBlockchainTransaction fabricates block numbers and addresses

Labels / Complexity: bug · High Complexity — High

Problem

BlockchainService.verifyBlockchainTransaction (src/blockchain/blockchain.service.ts:595) — the endpoint that tells clients whether a transaction is confirmed on-chain — calls simulateTransactionVerification (line 626) whenever the transaction is not already cached. The simulation fabricates everything:

blockNumber: Math.floor(Math.random() * 1000000),
from: '0x' + crypto.randomBytes(20).toString('hex'),
to: '0x' + crypto.randomBytes(20).toString('hex'),
value: '1000000000000000000', // 1 ETH in wei
status: 'success',
confirmations: Math.floor(Math.random() * 10) + 1,

The comment above it says: // In a real implementation, query the blockchain RPC / For now, simulate verification. getBlockchainStats has the same shape of stub — averageGasUsed: '0', // Would be calculated from actual on-chain data (line 738).

• Clients are told transactions are verified when nothing was checked. Any caller of verifyBlockchainTransaction receives verified: true with random block/confirmations for a hash that was never looked up — a transaction the API claims is confirmed may not exist on-chain at all.
• The fabricated from/to are random addresses unrelated to the actual transaction, so downstream displays of sender/receiver are fiction.

Why this is architecturally hard

1. This is a real RPC integration, not a toggle. The service already has an RPC provider list (rpcProviders at line 70) and a real eth_blockNumber call path (line 165); the fix is wiring verification to the provider and handling confirmation counts, which is a genuine provider-integration task.
2. Failure semantics must be defined. When the RPC is unreachable or the hash is unknown, the API must distinguish "not found", "pending", and "provider error" — returning verified: true from a fallback is not an option.
3. The cache (Fix: Improve Code Documentation and Comments #48 #61) and the real path interact. Cached transactions bypass simulation today; the migration must keep the cache consistent with real verification results.

Acceptance criteria

• verifyBlockchainTransaction returns data obtained from the RPC provider (or the existing real RPC path), never from simulateTransactionVerification.
• Unknown, pending, and confirmed hashes produce distinct, truthful results; no fabricated verified: true.
• getBlockchainStats reports real gas/on-chain values or omits them.
• Tests cover confirmed, pending, and unknown-hash cases with a stubbed provider.

Out of scope

The placeholder-URL config default (tracked separately); the transaction-cache durability migration (#61).

Getting started

• src/blockchain/blockchain.service.ts:595-642 — the verify path and simulation
• src/blockchain/blockchain.service.ts:160-215 — the existing real RPC call path

Commands: npm test, npx tsc --noEmit.

Good first files to read: src/blockchain/blockchain.service.ts (verify + RPC paths).

[Temmy2026]

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

I have a solid understanding of the underlying architecture required for this task and am ready to start testing a solution immediately.

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

[mjkayinla1]

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

I’d like to work on this issue because it addresses a critical correctness problem in blockchain verification. Returning fabricated block numbers, addresses, confirmations, and successful statuses can cause clients to trust transaction data that was never actually verified on-chain. I’m particularly interested in replacing this simulation with a proper RPC-backed verification flow and defining clear behavior for confirmed, pending, unknown, and provider-error states.

I have relevant experience with backend TypeScript/Node.js development, blockchain integrations, RPC-based services, asynchronous provider calls, caching, and automated testing. I’m comfortable tracing existing service and provider logic, integrating with established RPC paths, handling failure and edge cases, and writing tests with stubbed providers. I’d focus on reusing the existing RPC infrastructure, ensuring cached and freshly verified transactions remain consistent, removing the simulated fallback, and making sure the API only reports data that can be supported by actual on-chain results.

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

[gloriaelishahabu]

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

I have a solid understanding of the underlying architecture required for this task and am ready to start testing a solution immediately.

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

[drips-wave]

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

🧑‍💻 @gloriaelishahabu: 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 @gloriaelishahabu as part of the Stellar Wave Program's 8th Wave 🥳

😎 @gloriaelishahabu: 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.