brainblast 0.7.5 → 0.7.6

package/dist/packs/raydium-compute-zero-slippage/README.md

@@ -0,0 +1,43 @@
+# raydium-compute-zero-slippage
+
+**Severity:** HIGH
+
+## What's the trap?
+
+`@raydium-io/raydium-sdk-v2`'s `computeAmountOut()` takes a `slippage` parameter (a decimal fraction, e.g. `0.5` = 0.5%). When `slippage: 0`, the SDK sets `minAmountOut === amountOut` — the swap will only succeed if the received amount is exactly equal to the computed output with zero tolerance.
+
+In practice this means:
+
+- Any price movement between compute and on-chain execution causes the tx to fail (not protected, just fails)
+- A sandwich attack can front-run the swap and move the price; at `slippage: 0` there is no minimum-out floor, so the swap either fails with no protection or (depending on pool type) executes at a worse effective rate
+
+AI-generated swap bots frequently default to `slippage: 0` to "avoid slippage" without understanding that they're actually removing all minimum-output guarantees.
+
+## Why it's silent
+
+`computeAmountOut()` succeeds with `slippage: 0`. The route is computed, the tx is built, and the swap may execute. The trap only becomes apparent at the wallet level when MEV bots consistently extract value from the unprotected path.
+
+## The fix
+
+```typescript
+// BEFORE (vulnerable — no minimum output protection)
+return raydium.liquidity.computeAmountOut({
+  poolInfo: pool.poolInfo,
+  amountIn,
+  mintInfo: pool.mintInfos,
+  slippage: 0,    // ← trap
+});
+
+// AFTER (fixed — 0.5% tolerance)
+return raydium.liquidity.computeAmountOut({
+  poolInfo: pool.poolInfo,
+  amountIn,
+  mintInfo: pool.mintInfos,
+  slippage: 0.5,  // 0.5% — adjust to suit trade size and volatility
+});
+```
+
+## References
+
+- [Raydium SDK v2 GitHub](https://github.com/raydium-io/raydium-sdk-v2)
+- `ComputeAmountOutParam.slippage: number` — confirmed in `src/raydium/liquidity/type.ts`

package/dist/packs/raydium-compute-zero-slippage/brainblast-pack.yaml

@@ -0,0 +1,5 @@
+id: raydium-compute-zero-slippage
+name: Raydium computeAmountOut with zero slippage
+version: 0.1.0
+author: DSB-117
+description: Detects computeAmountOut called with slippage 0 enabling sandwich attacks

package/dist/packs/raydium-compute-zero-slippage/fixtures/raydium-compute-zero-slippage/fixed/swap.ts

@@ -0,0 +1,12 @@
+import { Raydium } from "@raydium-io/raydium-sdk-v2";
+
+export async function getSwapOutput(raydium: Raydium, poolId: string, amountIn: bigint) {
+  const pool = await raydium.liquidity.getPoolInfoFromRpc(poolId);
+  // FIXED: 0.5% slippage tolerance enforces a minimum output floor
+  return raydium.liquidity.computeAmountOut({
+    poolInfo: pool.poolInfo,
+    amountIn,
+    mintInfo: pool.mintInfos,
+    slippage: 0.5,
+  });
+}

package/dist/packs/raydium-compute-zero-slippage/fixtures/raydium-compute-zero-slippage/vulnerable/swap.ts

@@ -0,0 +1,12 @@
+import { Raydium } from "@raydium-io/raydium-sdk-v2";
+
+export async function getSwapOutput(raydium: Raydium, poolId: string, amountIn: bigint) {
+  const pool = await raydium.liquidity.getPoolInfoFromRpc(poolId);
+  // VULNERABLE: slippage: 0 means minAmountOut === amountOut — no sandwich protection
+  return raydium.liquidity.computeAmountOut({
+    poolInfo: pool.poolInfo,
+    amountIn,
+    mintInfo: pool.mintInfos,
+    slippage: 0,
+  });
+}

package/dist/packs/raydium-compute-zero-slippage/rules/raydium-compute-zero-slippage.yaml

@@ -0,0 +1,40 @@
+# Auto-synthesized from a research Finding (proof-as-classifier loop).
+# Pure data — every kind below resolves to a HUMAN-VETTED template in core.
+id: raydium-compute-zero-slippage
+severity: high
+title: "Raydium computeAmountOut called with slippage: 0 — no minimum output
+  protection against sandwich attacks"
+component:
+  name: "@raydium-io/raydium-sdk-v2"
+  type: Blockchain
+  version: ">=0.1.0"
+  sourceUrl: https://github.com/raydium-io/raydium-sdk-v2
+detect:
+  modules:
+    - "@raydium-io/raydium-sdk-v2"
+  nameRegex: swap|arb|trade|exchange|buy|sell
+  triggerCalls:
+    - computeAmountOut
+    - computeAmountIn
+check:
+  kind: object-arg-property-forbidden-literal
+  params:
+    call: computeAmountOut
+    argIndex: 0
+    propName: slippage
+    forbiddenValue: 0
+    passDetail: computeAmountOut is called with a nonzero slippage value — the swap
+      has minimum output protection against sandwich attacks.
+    failDetail: "computeAmountOut is called with slippage: 0, which sets
+      minAmountOut equal to amountOut with zero tolerance. Any price movement
+      between compute and execution — including a sandwich attack — will cause
+      the swap to execute at a worse price with no revert protection. Set
+      slippage to a nonzero value (e.g. 0.5 = 0.5%) to enforce a minAmountOut
+      floor."
+    absentCallDetail: Handler is in the swap scope but does not call
+      computeAmountOut(); this rule does not apply here.
+    absentArgDetail: computeAmountOut does not include a slippage literal in its
+      options object; the slippage tolerance cannot be confirmed statically.
+      Verify the resolved value is nonzero.
+test:
+  kind: none

package/dist/packs/solana-sendtx-unconfirmed/README.md

@@ -0,0 +1,34 @@
+# solana-sendtx-unconfirmed
+
+**Severity:** HIGH
+
+## What's the trap?
+
+`@solana/web3.js` exposes two ways to send a transaction:
+
+| Call | Behaviour |
+|------|-----------|
+| `connection.sendTransaction(tx, signers)` | Submits to the cluster and returns a signature **immediately** — fire-and-forget. |
+| `sendAndConfirmTransaction(connection, tx, signers)` | Waits until the transaction is **confirmed** before returning; throws if it fails or is dropped. |
+
+AI code generators routinely emit `sendTransaction()` because it matches the shape of "send a thing and get a result." The transaction returns a signature that *looks* like success, but the transaction may still be dropped due to network congestion, a validator restart, or blockhash expiry.
+
+## Why it's silent
+
+`sendTransaction()` resolves as soon as the RPC node accepts the transaction — not when it lands on-chain. The returned signature is valid regardless of whether the transaction was ever included in a block. Code that credits a user, debits inventory, or records a transfer immediately after this call will think it succeeded even when the on-chain state was never changed.
+
+## The fix
+
+```typescript
+// BEFORE (vulnerable)
+const sig = await connection.sendTransaction(tx, [signer]);
+
+// AFTER (fixed)
+import { sendAndConfirmTransaction } from "@solana/web3.js";
+const sig = await sendAndConfirmTransaction(connection, tx, [signer]);
+```
+
+## References
+
+- [Solana web3.js docs — sendAndConfirmTransaction](https://solana-labs.github.io/solana-web3.js/)
+- Solana Cookbook: "Sending Transactions" — always confirm before crediting

package/dist/packs/solana-sendtx-unconfirmed/brainblast-pack.yaml

@@ -0,0 +1,5 @@
+id: solana-sendtx-unconfirmed
+name: Solana sendTransaction without confirmation
+version: 0.1.0
+author: DSB-117
+description: Detects connection.sendTransaction() used in value-bearing paths without confirmation — transactions may silently drop on congestion or blockhash expiry

package/dist/packs/solana-sendtx-unconfirmed/fixtures/solana-sendtx-unconfirmed/fixed/payment.ts

@@ -0,0 +1,10 @@
+import { Connection, Transaction, Keypair, sendAndConfirmTransaction } from "@solana/web3.js";
+
+export async function sendPayment(
+  connection: Connection,
+  tx: Transaction,
+  signer: Keypair,
+): Promise<string> {
+  // FIXED: blocks until the transaction is confirmed by the cluster
+  return sendAndConfirmTransaction(connection, tx, [signer]);
+}

package/dist/packs/solana-sendtx-unconfirmed/fixtures/solana-sendtx-unconfirmed/vulnerable/payment.ts

@@ -0,0 +1,10 @@
+import { Connection, Transaction, Keypair } from "@solana/web3.js";
+
+export async function sendPayment(
+  connection: Connection,
+  tx: Transaction,
+  signer: Keypair,
+): Promise<string> {
+  // VULNERABLE: fire-and-forget — no confirmation that the transaction landed
+  return connection.sendTransaction(tx, [signer]);
+}

package/dist/packs/solana-sendtx-unconfirmed/rules/solana-sendtx-unconfirmed.yaml

@@ -0,0 +1,40 @@
+# Auto-synthesized from a research Finding (proof-as-classifier loop).
+# Pure data — every kind below resolves to a HUMAN-VETTED template in core.
+id: solana-sendtx-unconfirmed
+severity: high
+title: sendTransaction used instead of sendAndConfirmTransaction — transaction
+  may silently drop
+component:
+  name: "@solana/web3.js"
+  type: Blockchain
+  version: ">=1.0.0"
+  sourceUrl: https://solana-labs.github.io/solana-web3.js/
+detect:
+  modules:
+    - "@solana/web3.js"
+  nameRegex: send|transfer|execute|submit|payout|swap
+  triggerCalls:
+    - sendTransaction
+    - sendAndConfirmTransaction
+check:
+  kind: forbidden-call-replacement
+  params:
+    forbiddenCalls:
+      - sendTransaction
+    saferCalls:
+      - sendAndConfirmTransaction
+    passDetail: Handler calls sendAndConfirmTransaction, which waits for the cluster
+      to confirm the transaction before returning and propagates any on-chain
+      error as a thrown exception.
+    failDetail: Handler calls connection.sendTransaction() but not
+      sendAndConfirmTransaction(). sendTransaction() submits the transaction and
+      returns a signature immediately, with no confirmation that it landed. If
+      the transaction is dropped (congestion, validator restart, blockhash
+      expiry) the code continues as if it succeeded — tokens are not moved but
+      the caller assumes they were. Use sendAndConfirmTransaction(connection,
+      tx, signers) to block until confirmation.
+    absentDetail: Handler is in the send/transfer scope but calls neither
+      sendTransaction nor sendAndConfirmTransaction; this rule does not apply
+      here.
+test:
+  kind: none

package/dist/packs/spl-transfer-not-checked-in-payout/brainblast-pack.yaml

@@ -0,0 +1,5 @@
+id: spl-transfer-not-checked-in-payout
+name: SPL transfer not checked in payout
+version: 0.1.0
+author: DSB-117
+description: Flags SPL token payouts that use createTransferInstruction instead of createTransferCheckedInstruction

package/dist/packs/spl-transfer-not-checked-in-payout/fixtures/spl-transfer-not-checked-in-payout/fixed/payout-processor.ts

@@ -0,0 +1,29 @@
+import { Connection, Keypair, Transaction } from "@solana/web3.js";
+import { createTransferCheckedInstruction, getAssociatedTokenAddress } from "@solana/spl-token";
+
+const TOKEN_DECIMALS = 6;
+
+export async function executeSolanaPayout(
+  connection: Connection,
+  payer: Keypair,
+  mintAddress: string,
+  destinationOwner: string,
+  amountTokens: number,
+) {
+  const sourceAta = await getAssociatedTokenAddress(mintAddress as any, payer.publicKey);
+  const destinationAta = await getAssociatedTokenAddress(mintAddress as any, destinationOwner as any);
+
+  const amount = amountTokens * 10 ** TOKEN_DECIMALS;
+
+  const transferIx = createTransferCheckedInstruction(
+    sourceAta,
+    mintAddress as any,
+    destinationAta,
+    payer.publicKey,
+    amount,
+    TOKEN_DECIMALS,
+  );
+
+  const tx = new Transaction().add(transferIx);
+  return connection.sendTransaction(tx, [payer]);
+}

package/dist/packs/spl-transfer-not-checked-in-payout/fixtures/spl-transfer-not-checked-in-payout/vulnerable/payout-processor.ts

@@ -0,0 +1,22 @@
+import { Connection, Keypair, Transaction } from "@solana/web3.js";
+import { createTransferInstruction, getAssociatedTokenAddress } from "@solana/spl-token";
+
+const TOKEN_DECIMALS = 6;
+
+export async function executeSolanaPayout(
+  connection: Connection,
+  payer: Keypair,
+  mintAddress: string,
+  destinationOwner: string,
+  amountTokens: number,
+) {
+  const sourceAta = await getAssociatedTokenAddress(mintAddress as any, payer.publicKey);
+  const destinationAta = await getAssociatedTokenAddress(mintAddress as any, destinationOwner as any);
+
+  const amount = amountTokens * 10 ** TOKEN_DECIMALS;
+
+  const transferIx = createTransferInstruction(sourceAta, destinationAta, payer.publicKey, amount);
+
+  const tx = new Transaction().add(transferIx);
+  return connection.sendTransaction(tx, [payer]);
+}

package/dist/packs/spl-transfer-not-checked-in-payout/rules/spl-transfer-not-checked-in-payout.yaml

@@ -0,0 +1,49 @@
+# Pure-data rule (facts). Binds to the vetted `forbidden-call-replacement`
+# checker template.
+#
+# Real-world instance of this exact pattern:
+#   - elizaOS/eliza, payout-processor.ts — executeSolanaPayout() builds the
+#     transfer instruction with `createTransferInstruction(sourceAta,
+#     destinationAta, payer, amount)`, the legacy SPL Token instruction that
+#     does NOT validate the mint or decimals of the accounts it's given.
+#     `createTransferCheckedInstruction` is the drop-in replacement that adds
+#     mint+decimals validation, closing a class of bugs where a malicious or
+#     mismatched token account causes funds to move on the wrong mint or with
+#     the wrong decimal scaling.
+id: spl-transfer-not-checked-in-payout
+severity: high
+title: Token payout uses createTransferInstruction instead of createTransferCheckedInstruction
+component:
+  name: SPL Token
+  type: Blockchain
+  version: unversioned
+  sourceUrl: https://spl.solana.com/token
+detect:
+  modules: ["@solana/spl-token"]
+  nameRegex: "payout|withdraw|disburse|transfer|distribute"
+  triggerCalls: [createTransferInstruction, createTransferCheckedInstruction]
+check:
+  kind: forbidden-call-replacement
+  params:
+    forbiddenCalls: [createTransferInstruction]
+    saferCalls: [createTransferCheckedInstruction]
+    passDetail: >-
+      Payout uses createTransferCheckedInstruction, which validates the mint
+      and decimals of the source/destination token accounts before building
+      the transfer.
+    failDetail: >-
+      Payout builds its transfer with createTransferInstruction, the legacy
+      SPL Token instruction. It performs no on-chain validation that the
+      source and destination accounts belong to the expected mint or that the
+      amount is scaled to the correct decimals. If a caller (or a chain of
+      account-derivation bugs) supplies a token account for the wrong mint,
+      the transfer can move the wrong asset or move the right asset at the
+      wrong decimal scale, with no protocol-level check to stop it. Replace
+      with createTransferCheckedInstruction(source, mint, destination, owner,
+      amount, decimals).
+    absentDetail: >-
+      Handler is in the payout/transfer scope but neither
+      createTransferInstruction nor createTransferCheckedInstruction was
+      found; this rule does not apply here.
+test:
+  kind: none

package/dist/rules/metaplex-seller-fee-zero.yaml

@@ -1,4 +1,4 @@
-# Token Economics Validator (v0.7.5) — the generalized Bags exploit.
+# Fee Config Validator (v0.7.5) — the generalized Bags exploit.
 # A revenue-bearing field omitted from a config object silently defaults to
 # zero: the call succeeds, nothing is collected, forever. Here: Metaplex
 # `sellerFeeBasisPoints` — the on-chain royalty creators earn on secondary
@@ -18,7 +18,7 @@ detect:
   nameRegex: "metaplex|mpl|createNft|mint"
   triggerCalls: [create, createV1, createNft, createFungible, createAndMint]
 check:
-  kind: economic-value-zero-or-missing
+  kind: fee-configs-zero-or-missing
   params:
     calls: [create, createV1, createNft, createFungible, createAndMint]
     field: sellerFeeBasisPoints

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "brainblast",
-  "version": "0.7.5",
+  "version": "0.7.6",
   "type": "module",
   "description": "Deterministic auditor for catastrophic AI-integration bugs: scan a repo, find the silent money/auth traps, and generate the behavioral test that proves they're fixed.",
   "keywords": [

package/dist/tokenEconomics-HBF3DYNH.js

@@ -1,19 +0,0 @@
-import {
-  ECONOMIC_PATTERNS,
-  economicPatternsByCategory,
-  enforcedCount,
-  getEconomicPattern,
-  renderEconomicDetailText,
-  renderEconomicsMd,
-  renderEconomicsText
-} from "./chunk-S7X53LWF.js";
-import "./chunk-3RG5ZIWI.js";
-export {
-  ECONOMIC_PATTERNS,
-  economicPatternsByCategory,
-  enforcedCount,
-  getEconomicPattern,
-  renderEconomicDetailText,
-  renderEconomicsMd,
-  renderEconomicsText
-};