brainblast 0.7.4 → 0.7.6

package/dist/packs/meteora-dlmm-zero-min-out/rules/meteora-dlmm-zero-min-out.yaml

@@ -0,0 +1,47 @@
+# Pure-data rule. Binds to the vetted `object-arg-property-forbidden-literal`
+# checker (BN(0)-aware as of brainblast v0.7.6).
+#
+# Meteora DLMM's swap() takes `minOutAmount` — the floor the swap must return or
+# it reverts. Passing `new BN(0)` (or 0) removes that floor entirely: any price
+# movement between quote and execution, including a sandwich, fills the swap at
+# whatever price results. AI-written swap bots reach for minOutAmount: new BN(0)
+# to "just make the swap go through," silently disabling slippage protection.
+id: meteora-dlmm-zero-min-out
+severity: high
+title: Meteora DLMM swap called with minOutAmount of 0 — no slippage floor
+component:
+  name: "@meteora-ag/dlmm"
+  type: Blockchain
+  version: unversioned
+  sourceUrl: https://docs.meteora.ag/product-overview/meteora-liquidity-pools/dlmm-overview
+detect:
+  modules:
+    - "@meteora-ag/dlmm"
+  nameRegex: swap|trade|exchange|buy|sell|arb
+  triggerCalls:
+    - swap
+check:
+  kind: object-arg-property-forbidden-literal
+  params:
+    call: swap
+    argIndex: 0
+    propName: minOutAmount
+    forbiddenValue: 0
+    passDetail: >-
+      swap() is called with a nonzero minOutAmount — the swap reverts if it
+      would return less, enforcing a minimum-output floor.
+    failDetail: >-
+      swap() is called with minOutAmount of 0 (or new BN(0)), which removes the
+      minimum-output floor. Any price movement between quote and on-chain
+      execution — including a sandwich attack — fills the swap at whatever price
+      results, with no revert protection. Compute minOutAmount from the quote
+      and a slippage tolerance (e.g. quote.minOutAmount or quote * (1 - 0.005)).
+    absentCallDetail: >-
+      Handler is in the Meteora DLMM swap scope but does not call swap(); this
+      rule does not apply here.
+    absentArgDetail: >-
+      swap()'s options object does not set minOutAmount as an inline literal;
+      the minimum-output floor cannot be confirmed statically. Verify it is
+      derived from the quote and a nonzero slippage tolerance.
+test:
+  kind: none

package/dist/packs/pyth-price-unchecked-staleness/README.md

@@ -0,0 +1,34 @@
+# pyth-price-unchecked-staleness
+
+**Severity:** HIGH
+
+## What's the trap?
+
+Pyth `PriceFeed` objects expose two ways to read a price:
+
+- **`getPriceUnchecked()`** — returns the most recent price **regardless of how old it is**.
+- **`getPriceNoOlderThan(maxAgeSeconds)`** — returns the price only if it's fresh, otherwise `undefined`.
+
+Using `getPriceUnchecked()` means that if the feed stops updating — a publisher outage, network congestion, a halted market — your protocol keeps pricing swaps, loans, and liquidations against a **stale price** with no guard.
+
+## Why it's silent
+
+`getPriceUnchecked()` always succeeds and always returns a number. Nothing throws. The bug only surfaces when the feed goes stale at exactly the wrong moment — and by then someone has been liquidated at a wrong price, or drained an over-valued position.
+
+## The fix
+
+```typescript
+// BEFORE (vulnerable — ignores staleness)
+const price = feed.getPriceUnchecked();
+
+// AFTER (fixed — refuse stale prices)
+const price = feed.getPriceNoOlderThan(60); // 60s max age
+if (!price) throw new Error("Pyth price is stale — refusing to trade");
+```
+
+Pyth's own best-practices doc says to **never** use `getPriceUnchecked()` in production.
+
+## References
+
+- [Pyth — price availability best practices](https://docs.pyth.network/price-feeds/best-practices#price-availability)
+- Companion: `brainblast oracle <account>` checks the same staleness question live, on-chain.

package/dist/packs/pyth-price-unchecked-staleness/brainblast-pack.yaml

@@ -0,0 +1,5 @@
+id: pyth-price-unchecked-staleness
+name: Pyth unchecked price staleness
+version: 0.1.0
+author: DSB-117
+description: "Flags Pyth price reads via getPriceUnchecked() (ignores staleness) instead of getPriceNoOlderThan(maxAge), which can return an arbitrarily old price."

package/dist/packs/pyth-price-unchecked-staleness/fixtures/pyth-price-unchecked-staleness/fixed/price.ts

@@ -0,0 +1,14 @@
+import { PriceServiceConnection } from "@pythnetwork/price-service-client";
+
+const connection = new PriceServiceConnection("https://hermes.pyth.network");
+const SOL_USD = "0xef0d8b6fda2ceba41da15d4095d1da392a0d2f8ed0c6c7bc0f4cfac8c280b56d";
+
+// FIXED — getPriceNoOlderThan(60) returns undefined when the feed is more than
+// 60 seconds old, so we refuse to price against a stale oracle.
+export async function getSolPrice() {
+  const feeds = await connection.getLatestPriceFeeds([SOL_USD]);
+  const feed = feeds![0];
+  const price = feed.getPriceNoOlderThan(60);
+  if (!price) throw new Error("Pyth SOL/USD price is stale (>60s) — refusing to trade");
+  return Number(price.price) * 10 ** price.expo;
+}

package/dist/packs/pyth-price-unchecked-staleness/fixtures/pyth-price-unchecked-staleness/vulnerable/price.ts

@@ -0,0 +1,14 @@
+import { PriceServiceConnection } from "@pythnetwork/price-service-client";
+
+const connection = new PriceServiceConnection("https://hermes.pyth.network");
+const SOL_USD = "0xef0d8b6fda2ceba41da15d4095d1da392a0d2f8ed0c6c7bc0f4cfac8c280b56d";
+
+// VULNERABLE — getPriceUnchecked() ignores staleness. If the SOL/USD feed
+// stops updating, this returns the last (possibly very old) price and the
+// caller trades against it with no guard.
+export async function getSolPrice() {
+  const feeds = await connection.getLatestPriceFeeds([SOL_USD]);
+  const feed = feeds![0];
+  const price = feed.getPriceUnchecked();
+  return Number(price.price) * 10 ** price.expo;
+}

package/dist/packs/pyth-price-unchecked-staleness/rules/pyth-price-unchecked-staleness.yaml

@@ -0,0 +1,47 @@
+# Pure-data rule. Binds to the vetted `forbidden-call-replacement` checker.
+#
+# Pyth's own docs are explicit: NEVER use getPriceUnchecked() in production —
+# it returns the last price regardless of how old it is. A feed can stop
+# updating (publisher outage, network congestion) and getPriceUnchecked() will
+# happily hand you a stale price, which a protocol then prices liquidations /
+# swaps against. Use getPriceNoOlderThan(maxAge), which returns undefined when
+# the price is older than maxAge so the caller can refuse to trade.
+id: pyth-price-unchecked-staleness
+severity: high
+title: Pyth price read with getPriceUnchecked() instead of getPriceNoOlderThan()
+component:
+  name: Pyth Network price feeds
+  type: Blockchain
+  version: unversioned
+  sourceUrl: https://docs.pyth.network/price-feeds/best-practices#price-availability
+detect:
+  modules:
+    - "@pythnetwork/price-service-client"
+    - "@pythnetwork/pyth-solana-receiver"
+    - "@pythnetwork/hermes-client"
+  nameRegex: price|oracle|quote|value|fetch|get
+  triggerCalls:
+    - getPriceUnchecked
+    - getPriceNoOlderThan
+check:
+  kind: forbidden-call-replacement
+  params:
+    forbiddenCalls:
+      - getPriceUnchecked
+    saferCalls:
+      - getPriceNoOlderThan
+    passDetail: >-
+      Handler reads the Pyth price via getPriceNoOlderThan(maxAge), which
+      returns no price when the feed is older than maxAge — the caller can
+      refuse to trade on a stale oracle.
+    failDetail: >-
+      Handler calls getPriceUnchecked(), which returns the most recent Pyth
+      price REGARDLESS of how old it is. If the feed stops updating (publisher
+      outage, congestion), the protocol prices swaps/liquidations against a
+      stale value with no guard. Use getPriceNoOlderThan(maxAge) (e.g. 60s) and
+      handle the undefined/stale case explicitly.
+    absentDetail: >-
+      Handler is in Pyth scope but calls neither getPriceUnchecked nor
+      getPriceNoOlderThan; the staleness rule does not apply here.
+test:
+  kind: none

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

@@ -0,0 +1,41 @@
+# 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
+# sales. Omit it (or set 0) and the creators earn nothing, permanently.
+id: metaplex-seller-fee-zero
+severity: high
+title: Metaplex token created with sellerFeeBasisPoints omitted or zero — creators earn no royalties
+component:
+  name: Metaplex Token Metadata
+  type: Blockchain
+  version: unversioned
+  sourceUrl: https://developers.metaplex.com/token-metadata/mint
+detect:
+  modules:
+    - "@metaplex-foundation/mpl-token-metadata"
+    - "@metaplex-foundation/js"
+  nameRegex: "metaplex|mpl|createNft|mint"
+  triggerCalls: [create, createV1, createNft, createFungible, createAndMint]
+check:
+  kind: fee-configs-zero-or-missing
+  params:
+    calls: [create, createV1, createNft, createFungible, createAndMint]
+    field: sellerFeeBasisPoints
+    omittedDetail: >-
+      The Metaplex create call omits sellerFeeBasisPoints, which defaults to 0.
+      The token mints fine, but creators earn ZERO royalties on every secondary
+      sale — permanently and silently. There is no after-the-fact fix once
+      minted. Set sellerFeeBasisPoints explicitly (e.g. 500 = 5%).
+    zeroDetail: >-
+      sellerFeeBasisPoints is set to a literal 0 — creators will earn no royalty
+      on secondary sales. If this token is meant to be royalty-free that's fine;
+      otherwise set a non-zero basis-points value.
+    passDetail: >-
+      sellerFeeBasisPoints is set to a non-zero value — secondary-sale royalties
+      are configured.
+    absentDetail: >-
+      Handler is in Metaplex scope but does not call a token-create function;
+      the royalty-allocation rule does not apply here.
+test:
+  kind: none

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "brainblast",
-  "version": "0.7.4",
+  "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": [