bug-bounty-intelligence-mcp 1.0.3 → 1.1.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (7) hide show
  1. package/BENCHMARK.md +15 -1
  2. package/LICENSE +21 -0
  3. package/METHODOLOGY.md +33 -18
  4. package/README.md +266 -158
  5. package/index.mjs +286 -266
  6. package/package.json +43 -18
  7. package/vulnerability-acceptance-rates.json +72 -78
package/BENCHMARK.md CHANGED
@@ -51,6 +51,20 @@ contains an incorrect shift operation: ...
51
51
 
52
52
  This is in `lib/solady/`, a third-party library. It is out of scope for any 3FLabs audit.
53
53
 
54
+ **Update:** while triaging these, we noticed a related pattern on the same `lib/solady` code:
55
+ `divide-before-multiply` fired 38 times on `FixedPointMathLib`'s `fullMulDivUnchecked`, `cbrt`,
56
+ `invMod`, `rpow`, and `cbrtWad`. We initially described all 38 as the same false-positive class
57
+ (divided variable fully reassigned before the multiply) and reported it upstream —
58
+ [crytic/slither#3039](https://github.com/crytic/slither/issues/3039). That was an overclaim on our
59
+ part. A maintainer merged a fix for the specific reassignment pattern we described
60
+ ([crytic/slither#3040](https://github.com/crytic/slither/pull/3040), not yet in a PyPI release as
61
+ of 2026-08-01), and re-testing against the merged code ourselves shows it correctly resolves 11 of
62
+ the 38 (down to 27 remaining on this file). The other 27 keep the divided variable in the same
63
+ expression rather than through a clean reassignment, which is a different pattern this fix
64
+ correctly leaves untouched — we haven't yet re-analyzed whether those are genuine false positives
65
+ too or something else. Filed as a lesson: verify a fix against the actual code before describing
66
+ it as resolving the full scope of what you reported.
67
+
54
68
  ### Group B: 3 findings in `src/` — all false positives
55
69
 
56
70
  Slither flagged 3 uses of `safeTransferFrom(offer.maker, ...)` as "arbitrary from in transferFrom":
@@ -153,7 +167,7 @@ scan_contract({ repo_url: "https://github.com/3FLabs/grunt", protocol_type: "LEN
153
167
 
154
168
  ## About Bug Bounty Intelligence
155
169
 
156
- Trained on 27,681 real accepted audit findings from Sherlock and Code4rena. Uses the Al-Mizaan v3 framework — a 7-gate validation chain (Code, Reachability, Threat-Model, Invariant, Protocol-Intent, Impact, Proof) — to filter signals into confirmed findings.
170
+ Pattern-aware from a corpus of 56,657 submitted Sherlock findings across 212 measured contests, acceptance-rate numbers (used by `list_vulnerability_patterns`) are limited to the 7,388 findings across 35 contests that could be exact-reconciled against contest outcomes (3,694 accepted), see METHODOLOGY.md. Uses the Al-Mizaan v3 framework, a 7-gate validation chain (Code, Reachability, Threat-Model, Invariant, Protocol-Intent, Impact, Proof), to filter signals into confirmed findings.
157
171
 
158
172
  **Cost:** $5 USDC on Base (eip155:8453) via x402.
159
173
  **Install:** `npx -y bug-bounty-intelligence-mcp@latest`
package/LICENSE ADDED
@@ -0,0 +1,21 @@
1
+ MIT License
2
+
3
+ Copyright (c) 2026 Abdellah Ouadoudi
4
+
5
+ Permission is hereby granted, free of charge, to any person obtaining a copy
6
+ of this software and associated documentation files (the "Software"), to deal
7
+ in the Software without restriction, including without limitation the rights
8
+ to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9
+ copies of the Software, and to permit persons to whom the Software is
10
+ furnished to do so, subject to the following conditions:
11
+
12
+ The above copyright notice and this permission notice shall be included in all
13
+ copies or substantial portions of the Software.
14
+
15
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18
+ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20
+ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21
+ SOFTWARE.
package/METHODOLOGY.md CHANGED
@@ -1,6 +1,6 @@
1
1
  # Methodology: acceptance-rate data behind `list_vulnerability_patterns`
2
2
 
3
- **Last updated: 2026-07-21.**
3
+ **Last updated: 2026-11-12.**
4
4
 
5
5
  ## What this covers
6
6
 
@@ -12,8 +12,8 @@ are computed, what they don't claim, and how to reproduce them from public data.
12
12
 
13
13
  Sherlock runs public GitHub repos for judging each audit contest
14
14
  (`sherlock-audit/<contest>-judging`), where security researchers ("Watsons") open one GitHub
15
- issue per submitted finding. 105 of these judging repos were crawled (27,681 raw submitted
16
- findings total, 2024-02 through 2025-07).
15
+ issue per submitted finding. 218 of these judging repos were crawled; a real issue count could be
16
+ confirmed for 212 of them, 56,657 raw submitted findings total (2022-09 through 2025-02).
17
17
 
18
18
  ## The problem: "was this accepted?" is not reliably answerable from GitHub alone
19
19
 
@@ -36,16 +36,23 @@ We only trust this for a given contest if it **reconciles exactly**:
36
36
  `accepted_issue_numbers + invalid_issue_numbers === total_submitted_issues`.
37
37
 
38
38
  If a contest's folder structure doesn't exist, or doesn't reconcile exactly, that contest is
39
- **excluded entirely** — not estimated, not approximated. Of 105 crawled contests:
39
+ **excluded entirely** — not estimated, not approximated. Of 218 crawled contests:
40
40
 
41
- - **10 reconcile exactly** and are used for `list_vulnerability_patterns`: 1,032 findings, 461
41
+ - **35 reconcile exactly** and are used for `list_vulnerability_patterns`: 7,388 findings, 3,694
42
42
  accepted.
43
- - **95 do not** — either no accepted/invalid folder structure exists in that judging repo (a
43
+ - **183 do not** — either no accepted/invalid folder structure exists in that judging repo (a
44
44
  likely explanation: some contests use a different Sherlock judging workflow that doesn't
45
- generate this structure), or the counts don't sum to the known total (a likely explanation for
46
- many of these: the original crawl capped issue retrieval at 500 per contest, so large contests'
47
- true totals exceed what was captured — a fixable crawler limitation, not a Sherlock data
48
- problem, but not yet re-verified).
45
+ generate this structure), or the counts don't sum to the real total.
46
+
47
+ **2026-11-12 re-verification.** The original 2026-07-21 run (105 contests, 1,032 reconciled
48
+ findings) turned out to rest on a locally cached issue count that was itself wrong for most
49
+ contests, not only for the handful capped at the documented 500-issue crawl limit. Spot check: the
50
+ cache said `2022-09-knox-judging` had 12 submissions; the real count is 153.
51
+ `2024-02-optimism-2024-judging` showed 4; the real count is 251. The fix was to stop trusting any
52
+ locally cached total and re-derive it fresh from GitHub's search API for every contest, which is
53
+ also how the reconciliation check itself works (see Reproducing this, below). Re-running the exact
54
+ same reconciliation rule this way, with no local cache in the loop, is what produced the 35/7,388/
55
+ 3,694 figures above.
49
56
 
50
57
  ## What the resulting numbers mean
51
58
 
@@ -64,8 +71,9 @@ number of distinct vulnerabilities found.
64
71
  - The keyword-based pattern tagging is a simple substring matcher (see `detectPatterns()` in the
65
72
  crawler scripts), not a semantic classifier — a manual audit found roughly 65% tagging
66
73
  precision on a sample. Pattern labels are directional, not exact classifications.
67
- - The 10-contest sample is small. Some pattern rows have thin n (e.g. `liquidation`, n=14) —
68
- treat low-n rows as lower-confidence than high-n rows (e.g. `trusted-actor`, n=311).
74
+ - The 35-contest sample is still small relative to the full Sherlock history. Some pattern rows
75
+ have thin n (e.g. `idor`, n=18) — treat low-n rows as lower-confidence than high-n rows (e.g.
76
+ `trusted-actor`, n=1,814).
69
77
 
70
78
  ## Reproducing this
71
79
 
@@ -80,15 +88,22 @@ gh repo list sherlock-audit --limit 1000 --json name | jq -r '.[] | select(.name
80
88
  gh api repos/sherlock-audit/<contest>-judging/git/trees/main?recursive=1 \
81
89
  | jq '[.tree[].path | select(test("^[0-9]{3}-[HM]/|^invalid/"))]'
82
90
 
83
- # 3. Cross-check reconciliation against the contest's total issue count
84
- gh api "repos/sherlock-audit/<contest>-judging/issues?state=all&per_page=100" | jq 'length'
91
+ # 3. Cross-check reconciliation against the contest's REAL total issue count. Do not paginate
92
+ # an issues?state=all list and take its length: that silently undercounts the moment a
93
+ # contest has more issues than one page covers, which is most of them. The search API's
94
+ # own total_count does not have this problem.
95
+ gh api "search/issues?q=repo:sherlock-audit/<contest>-judging+type:issue" --jq .total_count
85
96
  ```
86
97
 
87
- A finding's issue number appearing under any `NNN-[HM]/` path = accepted. Under `invalid/` =
88
- rejected. If `accepted + invalid !== total`, do not use that contest's data.
98
+ A finding's issue number appearing under any `NNN-[HM]/` path = accepted (strip any leading
99
+ zeros before comparing to the issue number from the GitHub API, the folder names are zero-padded
100
+ and the API numbers are not). Under `invalid/` = rejected. If `accepted + invalid !== total`, do
101
+ not use that contest's data.
89
102
 
90
103
  ## Why we publish this instead of just the bigger, older number
91
104
 
92
105
  An earlier draft of this tool advertised acceptance percentages computed from the full,
93
- unverified 27,681-finding corpus. Independent review caught that those specific percentages
94
- were unreliable. We would rather ship a smaller number we can prove than a bigger one we can't.
106
+ unverified raw corpus. Independent review caught that those specific percentages were
107
+ unreliable. We would rather ship a smaller number we can prove than a bigger one we can't. That
108
+ is still true today: the raw corpus is 56,657 findings, the reconciled, trustworthy number
109
+ published here is 7,388.
package/README.md CHANGED
@@ -1,158 +1,266 @@
1
- # Bug Bounty Intelligence — MCP Server
2
-
3
- AI-powered smart contract security analysis for AI agents and developers.
4
-
5
- **Drawn from a corpus of 27,681 submitted findings across 105 Sherlock and Code4rena contests.**
6
- **Cost: $5 USDC on Base (eip155:8453) via x402.**
7
- **Free tool: `list_vulnerability_patterns` — no payment needed.**
8
-
9
- `list_vulnerability_patterns`' acceptance-rate numbers are computed only from the subset where
10
- results could be exactly reconciled against Sherlock's own published outcomes — 1,032 findings
11
- across 10 contests. We'd rather show fewer, verified numbers than a bigger set we can't stand
12
- behind. See [METHODOLOGY.md](METHODOLOGY.md) for exactly why, and how to reproduce it.
13
-
14
- ## Free dataset — no server, no MCP, no payment
15
-
16
- [`vulnerability-acceptance-rates.json`](vulnerability-acceptance-rates.json) is the same data
17
- `list_vulnerability_patterns` serves, as a static file. No API call, no account, no network
18
- dependency at all — download it, or copy it into your own tool's rule set. CC0 licensed, use it
19
- however you want, credit optional.
20
-
21
- ```bash
22
- curl -sO https://raw.githubusercontent.com/holistis/bug-bounty-intelligence-mcp/main/vulnerability-acceptance-rates.json
23
- ```
24
-
25
- If you're building a local-first / offline security scanner and the paid `scan_contract` tool
26
- below isn't a fit for your project's architecture, this file might still be useful on its own.
27
-
28
- ## Benchmark: vs Slither
29
-
30
- **[See the full benchmark →](BENCHMARK.md)**
31
-
32
- On 3FLabs/grunt (ERC-4626 + Morpho vaults, 218 contracts): Slither reports 27 "High" findings. After analysis: 24 are in `lib/solady` (out-of-scope dependency with known Slither false positive patterns), and 3 are EIP-712 design patterns. False positive rate: **100%**.
33
-
34
- Bug Bounty Intelligence scopes to `src/` only and filters through the Al-Mizaan 7-gate framework before reporting anything.
35
-
36
- ## What it does
37
-
38
- Submit a public GitHub repo containing Solidity smart contracts. Receive a full vulnerability report within 24 hours, powered by the Al-Mizaan v3 analysis framework.
39
-
40
- ## Tools
41
-
42
- | Tool | Description | Cost |
43
- |------|-------------|------|
44
- | `scan_contract` | Submit repo for security analysis | $5 USDC |
45
- | `get_scan_report` | Poll status and get report URL | Free |
46
- | `list_vulnerability_patterns` | Show acceptance rates from exact-reconciled Sherlock contests | Free |
47
-
48
- ## Quick start (Claude Desktop / Claude Code)
49
-
50
- Add to your `claude_desktop_config.json`:
51
-
52
- ```json
53
- {
54
- "mcpServers": {
55
- "bug-bounty-intelligence": {
56
- "command": "npx",
57
- "args": ["-y", "bug-bounty-intelligence-mcp@latest"]
58
- }
59
- }
60
- }
61
- ```
62
-
63
- Or run directly:
64
-
65
- ```bash
66
- npx -y bug-bounty-intelligence-mcp@latest
67
- ```
68
-
69
- ## Payment
70
-
71
- If `scan_contract` returns `PAYMENT REQUIRED`, send exactly $5 USDC on Base to the address shown, then retry. Payment = acceptance of [service terms](https://wazir-x402.duckdns.org/terms).
72
-
73
- **x402 info:**
74
- - Network: Base mainnet (eip155:8453)
75
- - Amount: 5,000,000 (= 5 USDC, 6 decimals)
76
- - Asset: 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 (USDC)
77
- - Wallet: 0xdffcC75a674257be6FE1b5549FE52e8f8a6A3A5A
78
-
79
- ## Example session
80
-
81
- ```
82
- > list_vulnerability_patterns({ protocol_type: "LENDING" })
83
-
84
- Vulnerability patterns for LENDING protocols (from Sherlock audit findings, exact-reconciled contests only):
85
-
86
- oracle-manipulation 36% accepted (131 cases)
87
- liquidation 29% accepted (14 cases)
88
- staleness 49% accepted (174 cases)
89
- rounding 40% accepted (63 cases)
90
- flash-loan 46% accepted (13 cases)
91
- access-control 47% accepted (74 cases)
92
-
93
- > scan_contract({ repo_url: "https://github.com/myprotocol/contracts", protocol_type: "LENDING" })
94
-
95
- PAYMENT REQUIRED to start the scan.
96
-
97
- Amount: 5.00 USDC
98
- Network: Base mainnet (eip155:8453)
99
- Pay to: 0xdffcC75a674257be6FE1b5549FE52e8f8a6A3A5A
100
- Asset: USDC — 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913
101
-
102
- After paying, retry scan_contract with the same repo_url.
103
- ```
104
-
105
- ## Sample scan output
106
-
107
- Real scan of `sherlock-audit/2025-03-crestal-network` (Derivatives protocol, 29 contracts):
108
-
109
- ```
110
- Summary: 0 Critical | 1 High | 0 Medium | 0 Low
111
- Analyzed: 29 contracts | Model: qwen2.5:7b | Duration: 25min
112
-
113
- FINDING #1 — HIGH
114
- Title: Owner Can Arbitrarily Set Payment Addresses
115
- File: Blueprint.sol
116
- Functions: setCreateAgentTokenCost, setUpdateCreateAgentTokenCost,
117
- addPaymentAddress, removePaymentAddress
118
- Category: ACCESS
119
-
120
- Description:
121
- The owner can arbitrarily set payment addresses and costs without
122
- any external validation or timelock.
123
-
124
- Attack path:
125
- An attacker with ownership calls setCreateAgentTokenCost or
126
- addPaymentAddress to modify fees or redirect user payments to
127
- an attacker-controlled wallet.
128
-
129
- Impact:
130
- Extremely high costs (griefing) or redirection of user funds.
131
-
132
- Recommendation:
133
- Implement a governance mechanism or timelock to restrict fee
134
- and address changes.
135
-
136
- Confidence: 0.90 (CONFIRMED by Al-Mizaan validation)
137
- ```
138
-
139
- ## About the analysis
140
-
141
- The Al-Mizaan v3 framework checks 7 gates:
142
-
143
- 1. Code reading (literal, not docs)
144
- 2. Reachability chain (entry to exploit)
145
- 3. Threat model (who can trigger it)
146
- 4. Invariant breach (what rule is violated)
147
- 5. Protocol intent (was this intended?)
148
- 6. Impact (real financial damage)
149
- 7. Formal proof (reproducible PoC)
150
-
151
- Only findings that survive all 7 gates are reported.
152
-
153
- ## Service info
154
-
155
- - **API endpoint**: https://wazir-x402.duckdns.org/api/bug-intel
156
- - **Terms**: https://wazir-x402.duckdns.org/terms
157
- - **Delivery**: within 24h
158
- - **Source code**: deleted after analysis
1
+ # Bug Bounty Intelligence: MCP Server
2
+
3
+ AI-powered smart contract security analysis for AI agents and developers.
4
+
5
+ ## Verify us in two minutes
6
+
7
+ You need Node 22 or newer (what our recount workflow uses) and nothing else.
8
+
9
+ ```
10
+ git clone https://github.com/holistis/bug-bounty-intelligence-mcp
11
+ cd bug-bounty-intelligence-mcp
12
+ node results/2026-11-02-shop-setup-five-audits/check.mjs
13
+ node tools/checker-selftest.mjs
14
+ node tools/ranges-check.mjs
15
+ ```
16
+
17
+ The first command recounts one result folder from its verdict files and checks its hashes. It runs offline.
18
+
19
+ The second command tests the checkers. It copies every result folder to a temp directory, plants a made-up finding id and a flipped verdict, and runs the check.mjs of that folder. CAUGHT is good. BLIND means the checker accepted the planted fault. Today no folder is BLIND. The last one, results/2026-10-26-evmbench, was fixed on 3 November 2026 in pull request 89. To see where we started, test the state before our fixes:
20
+
21
+ The third command checks the central index (results/README.md): every folder it names with a voided-answer count above zero must also be named under its "Ranges if the voided answers are counted" section. Tom Smart found that this was missing for five older folders on 4 November 2026 (issue 41). It covers that one index, not yet a newer folder's own README.
22
+
23
+ ```
24
+ git worktree add ../selftest-before 0fafa23
25
+ node tools/checker-selftest.mjs ../selftest-before/results
26
+ ```
27
+
28
+ Three of the five checkers a made-up id can reach were BLIND then.
29
+
30
+ First issues, each scoped to one folder or one audit: [good first issues](https://github.com/holistis/bug-bounty-intelligence-mcp/labels/good%20first%20issue). How a change is reviewed and how credit works: [CONTRIBUTING.md](CONTRIBUTING.md). The scan engine itself is not in this repository.
31
+
32
+ Every public statement of ours that turned out wrong is listed, with the date and the fix, in [ERRATA.md](ERRATA.md). The counting rule behind our results is [MEASUREMENT-RULE-two-judge-strict.md](MEASUREMENT-RULE-two-judge-strict.md).
33
+
34
+ ## Update, 2 November 2026: the scan you can buy, counted
35
+
36
+ The setup behind our deep scan found 14 of 20 known High findings on five public audits, one run each, graded by a copy of the benchmark's own judge. On the same five audits the leader's own report finds 15 of 20 under that copy. Every verdict, the exact reports the judge read and a script that recounts everything are in [results/2026-11-02-shop-setup-five-audits](results/2026-11-02-shop-setup-five-audits/README.md), with the limits listed. All our result folders are listed in [results/README.md](results/README.md), and the longer story is on [our blog](https://tokenizen.nl/notes/the-scan-you-can-buy-measured).
37
+
38
+ ## Update, 25 October 2026, night: two free tools next to the scan
39
+
40
+ We ran Slither 0.11.6 and Aderyn 0.6.8 with default settings on the same contests and had the same two judges compare their output with the known High and Medium findings. They found none: Slither 0 of 34 and Aderyn 0 of 70, on the contests where our setup could run them. On the same contests our scan found 6 of 34 and 10 of 70 in its first 15 hypotheses. Static tools are not built for the business-logic flaws that contests reward, the older contests may be in the training data of the model behind our scan, and the judges are language models, so read it as a description and not as a ranking: [results/2026-10-25-free-tools/README.md](results/2026-10-25-free-tools/README.md).
41
+
42
+ ## Update, 25 October 2026, night: a quick scan for 1 dollar
43
+
44
+ There are now two prices. The quick scan, POST https://x402.tokenizen.nl/api/bug-intel-quick for 1 USDC on Base, returns the 15 hypotheses the model is most confident about. The full scan, POST https://x402.tokenizen.nl/api/bug-intel for 5 USDC, adds 15 more with lower confidence. It is the same engine and the same kind of report. The hit rates we measured (8 of 105 and 5 of 66) are for the first 15 hypotheses, so they are the numbers of the quick scan; the second list is the extra of the full scan. The quick scan costs exactly 1 dollar because the official x402 client refuses payments above 1 dollar per request unless its owner raises the limit, and we checked with a real purchase that an agent with default settings can buy it: [results/2026-10-25-v31/quick-scan-purchase/README.md](results/2026-10-25-v31/quick-scan-purchase/README.md). Both routes sign their offers.
45
+
46
+ ## Update, 25 October 2026, night: a standard x402 client can now buy the scan
47
+
48
+ Until today the scan endpoint accepted only a transaction hash from a payment you had made by hand, and it answered 400 to the signed authorization that standard x402 clients send, although its 402 answer said that would work. That is fixed. A standard client (@x402/fetch 2.28.0) bought the scan from a throwaway address, got the receipt in the response, and the six checks on the receipt pass: [results/2026-10-25-v31/standard-client-purchase/README.md](results/2026-10-25-v31/standard-client-purchase/README.md). It was a self test with our own money, one purchase. One thing a buyer needs to know: the official client refuses payments above 1 dollar per request unless its owner raises the limit, and the scan costs 5 dollars.
49
+
50
+ ## Update, 25 October 2026, night: the scan on contests from the last year
51
+
52
+ We ran the scan once on 9 Code4rena contests from September 2025 to March 2026 (66 known High and Medium findings), with the rule for reading the result written beforehand. The first 15 hypotheses of a report held 5 of the 66 (7.6 percent) and the first 30 held 8 (12.1 percent). That is the same rate as on the 8 Sherlock contests, so by our own rule the result holds on newer contests. It is still a low rate: 58 of the 66 known findings were not in the first 15. Numbers, judgements, the whole lists and the limits: [results/2026-10-25-c4-fresh/README.md](results/2026-10-25-c4-fresh/README.md).
53
+
54
+ A report can now show up to 30 hypotheses, in two lists: the 15 the model is most confident about and 15 more with lower confidence. On the stored lists the second list held 8 known findings that the first list did not (5 on Sherlock, 3 on Code4rena), at a slightly lower precision. We chose this after seeing the numbers, so it is a product choice and not a pre-registered test.
55
+
56
+ ## Update, 25 October 2026, evening: the offer is signed
57
+
58
+ The paid endpoint now declares the x402 offer-receipt extension and signs its offer. You can check it yourself without paying: `npx -y agent-receipt-verify https://x402.tokenizen.nl/api/bug-intel` reaches level 2 (asks for payment the way x402 says, declares the extension, and the signature of the offer verifies). The signer is 0xf30b0706E78b3166745E6a2f351992321088058f. That key only signs offers and receipts and holds no funds. The key is bound to the service domain in DNS, the way section 4.5.1 of the offer-receipt specification describes: `dig TXT _controllers.x402.tokenizen.nl` lists it as a controller (set on 25 October 2026). The address that receives payments is the one in the payment section below.
59
+
60
+ After a payment the answer to the paid request carries a signed receipt for that payment transaction, in the body as `receipt` and in the `PAYMENT-RESPONSE` header (level 3). We have seen this on one real payment, a self test on Base mainnet with 5.1 USDC from the project's own address to the payment address of the service. The receipt, the transaction, the delivered report and a script that checks all of it are in [results/2026-10-25-v31/first-real-payment/](results/2026-10-25-v31/first-real-payment/README.md). Nobody else has used the receipt yet, and the conformance checker still shows level 3 as not measured because it checks without paying. A receipt says that our service saw payment transaction X for this resource. It says nothing about how good the report is.
61
+
62
+ ## Update, 25 October 2026: version 3.1 is live
63
+
64
+ Paid scans now run on a newer version, V3.1. On the same 8 contests as the sealed run it found 8 of 105 known High and Medium findings (7.6 percent), against 4 for the version before it and 1 for the scan that was in production until the evening of 25 October: [results/2026-10-25-v31/README.md](results/2026-10-25-v31/README.md). Two things changed at once and those contests are no longer secret, so this is a doubling from a low level and not a proof. 97 of the 105 were still not found. A scan takes about 20 to 45 seconds and costs us 0.02 to 0.15 dollar. The earlier version stays in place as the fallback.
65
+
66
+ ## Update, 24 October 2026, evening: the sealed run
67
+
68
+ The one run on the sealed set is done, with the rule written before it: [results/2026-10-24-sealed/README.md](results/2026-10-24-sealed/README.md). On 8 contests that nobody here had run anything on, the scan as it runs today found 1 of 105 known High and Medium findings. A newer version, not in production, found 4 of 105. The rule needed at least 5 findings that production does not find, and it found 3, so production stays as it is. The scan still produces hypotheses to review by hand, and it has not been shown to find what a human audit finds.
69
+
70
+ ## Update, 24 October 2026, later the same day: version 2 of the scan
71
+
72
+ The defects described below were fixed and the new version is live. What changed: git submodules are fetched when they point to github.com, tests, mocks, scripts, interfaces and vendored libraries are left out, files are ranked by how likely they move funds and sent in at most six parts, every report states how much of the in-scope code was read, a scan without hypotheses is delivered as such and not as a normal report, hypotheses that name files or functions that are not in the code are dropped, and file links inside a repository are never followed. A free precheck at https://x402.tokenizen.nl/api/bug-intel/precheck?repo=owner/name says before you pay whether the scan counts any Solidity in your repository and roughly how much of it will be read.
73
+
74
+ The measurement of this version was pre-registered before it ran: [PREREGISTRATION-v2-2026-10-24.md](PREREGISTRATION-v2-2026-10-24.md). The frozen files are in [pipeline/v2](pipeline/v2).
75
+
76
+ Result, in [RESULTS-v2-2026-10-24.md](RESULTS-v2-2026-10-24.md): none of the 40 known High and Medium findings was found, 0 of 31 on the four contests of the first run and 0 of 9 on three new contests, while 29 percent of the in-scope code was read (8 to 100 percent per contest). 15 of the 40 known findings sit in a file that was read, and none of those was found. The scan produces hypotheses to review by hand. It has not been shown to find the issues that audit contests reward.
77
+
78
+ ## Correction and limits (24 October 2026, before version 2)
79
+
80
+ Reading the production scan code on 24 October 2026 showed that earlier text on this page overstated what the paid scan does. What it does today:
81
+
82
+ - It sends the model at most about 22,000 characters of Solidity source per job, taken from up to 60 files in directory order, and it does not skip test or mock folders. On three recent audit-contest repositories (code-423n4/2025-11-merkl, 2025-11-sukukfi and 2026-04-monetrix) that is 3 to 7 percent of the Solidity source.
83
+ - The 7-gate filter is not part of the paid scan. It was taken out because the small model also eliminated real bugs. The report lists raw hypotheses with a self-reported confidence of 0.4 or higher, at most eight, and its disclaimer says so.
84
+ - The sample below ran on a repository that belongs to the corpus the framework was built from. It does not show how the scan does on projects it has not seen, and its label "CONFIRMED by Al-Mizaan validation" does not apply to the scan as it runs today.
85
+ - We have not measured how many real bugs the scan finds on contests it has not seen. A test on closed audit contests is pre-registered in [PREREGISTRATION-2026-10-24.md](PREREGISTRATION-2026-10-24.md). The baseline ran on 24 October 2026: 0 of 31 findings found, 2 hypotheses reported and neither matches, one job failed and two reports were empty. See [RESULTS-2026-10-24.md](RESULTS-2026-10-24.md). Until a changed version is pre-registered and measured, do not read this scan as something that finds bugs on projects it has not seen.
86
+
87
+ Official source: this repository and the payment address in the payment section below are the only official ones for Bug Bounty Intelligence. If a listing, a reply or a website gives a different payment address, it is not ours. Check the address against the one below before you pay.
88
+
89
+ **Drawn from a corpus of 56,657 submitted findings across 212 measured Sherlock audit competitions.**
90
+ **Cost: $5 USDC on Base (eip155:8453) via x402 for the full scan, $1 USDC for the quick scan.**
91
+ **Free tool: `list_vulnerability_patterns`, no payment needed.**
92
+
93
+ `list_vulnerability_patterns`' acceptance-rate numbers are computed only from the subset where
94
+ results could be exactly reconciled against Sherlock's own published outcomes: 7,388 findings
95
+ across 35 contests. We'd rather show fewer, verified numbers than a bigger set we can't stand
96
+ behind. See [METHODOLOGY.md](METHODOLOGY.md) for exactly why, and how to reproduce it.
97
+
98
+ ## Free dataset: no server, no MCP, no payment
99
+
100
+ [`vulnerability-acceptance-rates.json`](vulnerability-acceptance-rates.json) is the same data
101
+ `list_vulnerability_patterns` serves, as a static file. No API call, no account, no network
102
+ dependency at all. Download it, or copy it into your own tool's rule set. CC0 licensed, use it
103
+ however you want, credit optional.
104
+
105
+ ```bash
106
+ curl -sO https://raw.githubusercontent.com/holistis/bug-bounty-intelligence-mcp/main/vulnerability-acceptance-rates.json
107
+ ```
108
+
109
+ If you're building a local-first / offline security scanner and the paid `scan_contract` tool
110
+ below isn't a fit for your project's architecture, this file might still be useful on its own.
111
+
112
+ ## Just want pattern search, nothing paid? Use 3ilm-mcp instead
113
+
114
+ [3ilm-mcp](https://github.com/holistis/3ilm-mcp) is a smaller, free-only MCP server built from
115
+ the same verified dataset. It has no paid tier at all, just pattern search
116
+ (`search_vulnerabilities`, `get_pattern_details`, `list_patterns`). Use this repo
117
+ (bug-bounty-intelligence-mcp) if you also want the paid `scan_contract` scan; use
118
+ 3ilm-mcp if you only ever wanted the free lookup tools and prefer the lighter package.
119
+
120
+ Two more tools in the same Al-Mizaan toolkit, for the rest of the workflow: [al-mizaan-judge](https://github.com/holistis/al-mizaan-judge) is a local CLI that pressure-tests a candidate finding through the same 7-gate framework before you submit it, and [DeFi Signal API](https://github.com/holistis/defi-signal-api) exposes the same vuln-search/bug-intel routes as a pay-per-call HTTP API for anyone who wants this outside MCP.
121
+
122
+ ## Benchmark: vs Slither
123
+
124
+ **[See the full benchmark →](BENCHMARK.md)**
125
+
126
+ On 3FLabs/grunt (ERC-4626 + Morpho vaults, 218 contracts): Slither reports 27 "High" findings. After analysis: 24 are in `lib/solady` (out-of-scope dependency with known Slither false positive patterns), and 3 are EIP-712 design patterns. False positive rate: **100%**.
127
+
128
+ In that comparison Bug Bounty Intelligence was pointed at `src/` only. The paid scan now leaves out tests, mocks, scripts, interfaces and vendored libraries by rule. It does not run the 7-gate filter.
129
+
130
+ We also reported a related `divide-before-multiply` pattern on the same `lib/solady` code directly to the Slither project: [crytic/slither#3039](https://github.com/crytic/slither/issues/3039). A maintainer merged a fix for part of it ([crytic/slither#3040](https://github.com/crytic/slither/pull/3040)); see [BENCHMARK.md](BENCHMARK.md) for the honest scope of what that fix does and doesn't cover, we overclaimed in the original report.
131
+
132
+ ## What it does
133
+
134
+ Submit a public GitHub repo containing Solidity smart contracts. Receive a report of AI-generated hypotheses, usually within a few minutes, that states how much of the code was read (see the update and the limits at the top of this page).
135
+
136
+ ## Tools
137
+
138
+ | Tool | Description | Cost |
139
+ |------|-------------|------|
140
+ | `scan_contract` | Submit repo for security analysis | $5 USDC |
141
+ | `get_scan_report` | Poll status and get report URL | Free |
142
+ | `list_vulnerability_patterns` | Show acceptance rates from exact-reconciled Sherlock contests | Free |
143
+
144
+ ## Quick start (Claude Desktop / Claude Code)
145
+
146
+ Also listed in [PuPu](https://github.com/haoxiang-xu/PuPu)'s MCP store as of release v0.1.11 ([registration issue](https://github.com/haoxiang-xu/PuPu/issues/186)).
147
+
148
+ Add to your `claude_desktop_config.json`:
149
+
150
+ ```json
151
+ {
152
+ "mcpServers": {
153
+ "bug-bounty-intelligence": {
154
+ "command": "npx",
155
+ "args": ["-y", "bug-bounty-intelligence-mcp@latest"]
156
+ }
157
+ }
158
+ }
159
+ ```
160
+
161
+ Or run directly:
162
+
163
+ ```bash
164
+ npx -y bug-bounty-intelligence-mcp@latest
165
+ ```
166
+
167
+ ## Payment
168
+
169
+ If `scan_contract` returns `PAYMENT REQUIRED`, send exactly $5 USDC on Base to the address shown, then retry. Payment = acceptance of [service terms](https://x402.tokenizen.nl/terms).
170
+
171
+ **x402 info:**
172
+ - Network: Base mainnet (eip155:8453)
173
+ - Amount: 5,000,000 (= 5 USDC, 6 decimals)
174
+ - Asset: 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 (USDC)
175
+ - Wallet: 0x015Eb036560216B3051339061FF68A207E0fe88f
176
+
177
+ The wallet address can change. Always pay the address `scan_contract` actually returns in its `PAYMENT REQUIRED` response, not a copy of this README. This document is updated when the address changes, but the live tool response is the source of truth.
178
+
179
+ ## Example session
180
+
181
+ ```
182
+ > list_vulnerability_patterns({ protocol_type: "LENDING" })
183
+
184
+ Vulnerability patterns for LENDING protocols (from Sherlock audit findings, exact-reconciled contests only):
185
+
186
+ oracle-manipulation 36% accepted (131 cases)
187
+ liquidation 29% accepted (14 cases)
188
+ staleness 49% accepted (174 cases)
189
+ rounding 40% accepted (63 cases)
190
+ flash-loan 46% accepted (13 cases)
191
+ access-control 47% accepted (74 cases)
192
+
193
+ > scan_contract({ repo_url: "https://github.com/myprotocol/contracts", protocol_type: "LENDING" })
194
+
195
+ PAYMENT REQUIRED to start the scan.
196
+
197
+ Amount: 5.00 USDC
198
+ Network: Base mainnet (eip155:8453)
199
+ Pay to: 0x015Eb036560216B3051339061FF68A207E0fe88f
200
+ Asset: USDC — 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913
201
+
202
+ After paying, retry scan_contract with the same repo_url.
203
+ ```
204
+
205
+ ## Sample scan output
206
+
207
+ Real scan of `sherlock-audit/2025-03-crestal-network` (Derivatives protocol, 29 contracts):
208
+
209
+ ```
210
+ Summary: 0 Critical | 1 High | 0 Medium | 0 Low
211
+ Analyzed: 29 contracts | Model: qwen2.5:7b | Duration: 25min
212
+
213
+ FINDING #1 — HIGH
214
+ Title: Owner Can Arbitrarily Set Payment Addresses
215
+ File: Blueprint.sol
216
+ Functions: setCreateAgentTokenCost, setUpdateCreateAgentTokenCost,
217
+ addPaymentAddress, removePaymentAddress
218
+ Category: ACCESS
219
+
220
+ Description:
221
+ The owner can arbitrarily set payment addresses and costs without
222
+ any external validation or timelock.
223
+
224
+ Attack path:
225
+ An attacker with ownership calls setCreateAgentTokenCost or
226
+ addPaymentAddress to modify fees or redirect user payments to
227
+ an attacker-controlled wallet.
228
+
229
+ Impact:
230
+ Extremely high costs (griefing) or redirection of user funds.
231
+
232
+ Recommendation:
233
+ Implement a governance mechanism or timelock to restrict fee
234
+ and address changes.
235
+
236
+ Confidence: 0.90 (CONFIRMED by Al-Mizaan validation)
237
+ ```
238
+
239
+ ## About the analysis
240
+
241
+ The Al-Mizaan v3 framework defines 7 gates:
242
+
243
+ 1. Code reading (literal, not docs)
244
+ 2. Reachability chain (entry to exploit)
245
+ 3. Threat model (who can trigger it)
246
+ 4. Invariant breach (what rule is violated)
247
+ 5. Protocol intent (was this intended?)
248
+ 6. Impact (real financial damage)
249
+ 7. Formal proof (reproducible PoC)
250
+
251
+ This is the framework used for manual review (the `al-mizaan-judge` CLI). The paid scan does not run it end to end, see the correction at the top of this page.
252
+
253
+ ## Service info
254
+
255
+ - **API endpoint**: https://x402.tokenizen.nl/api/bug-intel
256
+ - **Free precheck**: https://x402.tokenizen.nl/api/bug-intel/precheck?repo=owner/name
257
+ - **Terms**: https://x402.tokenizen.nl/terms
258
+ - **Delivery**: usually within the hour, at most 48 hours according to the terms
259
+ - **If it fails or does not help**: write to info@holistischadviseur.nl with the job id for a new attempt or a refund, see the terms
260
+ - **Source code**: deleted after analysis
261
+
262
+ ## Support this project
263
+
264
+ This is a free, open-source MCP server maintained in my spare time. If it caught something useful before you shipped, tips are welcome and appreciated (never expected):
265
+
266
+ `0xdffcC75a674257be6FE1b5549FE52e8f8a6A3A5A` (USDC, Base)