Add Solana and Bitcoin support#1
Conversation
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Keep credential name as quicknodeApi (not quicknodeEvmApi) and all EVM parameter names at their v1 values (operation, address, block, txHash, from, to, data, value, rpcMethod, rpcParams) so existing saved workflows continue to resolve credentials and parameters without silent fallbacks. Bump typeVersion to [1,2] with defaultVersion:2 and fall back chain to 'evm' so v1 workflows (no chain field) still route correctly. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
| return /^[1-9A-HJ-NP-Za-km-z]{32,44}$/.test(address); | ||
| } | ||
| function isValidSolanaSignature(sig: string): boolean { | ||
| return /^[1-9A-HJ-NP-Za-km-z]{87,88}$/.test(sig); |
There was a problem hiding this comment.
Signature validation regex rejects valid shorter signatures
Medium Severity
isValidSolanaSignature uses {87,88} for the base58 length check, but a 64-byte Ed25519 signature can base58-encode to 86 characters (or fewer) when the underlying byte array has leading zero bytes. The first byte of a signature (the least significant byte of the R point's y-coordinate) is ~uniformly distributed, giving roughly a 1-in-256 chance of a leading zero byte, which can produce an 86-character encoding. This causes the getTransaction operation to reject valid signatures with no workaround besides the custom RPC fallback.
Additional Locations (1)
…ction Solana's RPC rejects the 'processed' commitment level for getBlock and getTransaction. Split into a separate solanaBlockTxCommitment parameter (finalized/confirmed only) shown for those two operations, keeping solanaCommitment (all three levels) for getBalance, getAccountInfo, and getSlot which support processed. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
isValidBitcoinTxid and isValidBitcoinBlockHash had byte-for-byte identical implementations. Extracted to isValid64CharHex with named aliases. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Replace Number(BigInt)/1e18 and /1e9 with BigInt division to avoid
float precision loss on large ETH/Gwei/SOL values
- Wrap BigInt(response.result) in try/catch for malformed RPC responses
- Use isValidEvmTxHash() in getBlock case instead of inline duplicate regex
- Tighten data field validation to require even-length hex pairs
(/^0x([a-fA-F0-9]{2})*$/ instead of /^0x[a-fA-F0-9]*$/)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
There are 2 total unresolved issues (including 1 from previous review).
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
| const whole = lamportsBig / BigInt('1000000000'); | ||
| const frac = lamportsBig % BigInt('1000000000'); | ||
| resultData.balanceSol = `${whole}.${frac.toString().padStart(9, '0')}`; | ||
| } |
There was a problem hiding this comment.
Solana balance conversion lacks defensive try-catch
Medium Severity
The Solana getBalance result processing performs BigInt(lamports) and property access on response.result.value without a try-catch, unlike the EVM getBalance and getGasPrice conversions which both wrap their BigInt conversions in try-catch with a /* malformed result — raw result still returned */ comment. If response.result.value is unexpectedly null, undefined, or non-numeric, the Solana path throws, losing the successfully-fetched raw result already stored in resultData. The EVM path gracefully survives and still returns the raw result.
Additional Locations (1)
2 participants
No description provided.