I Built a Web3 Threat Intelligence Oracle Powered by Gemma 4

James Kabingu — Sun, 17 May 2026 23:35:36 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

OCTIO (On-Chain Threat Intelligence Oracle) is a system that monitors live phishing and malware feeds, runs each threat indicator through Gemma 4 for analysis and classification, and stores verified intelligence in a format that blockchain protocols can query before executing sensitive operations.
The problem it solves is real. Around 80% of funds stolen from Web3 projects come not from smart contract exploits but from attacks on surrounding Web2 infrastructure such as phishing campaigns, DNS hijacking, frontend supply chain compromise, and cloud misconfiguration. The Ronin Network hack ($625 million) started with a phishing email. The Ledger Connect Kit attack ($600,000) came from a poisoned npm package. The Curve Finance DNS hijack redirected legitimate users to a malicious server for hours.
In every case, observable signals existed before significant losses occurred. OCTIO is the infrastructure to collect, analyse, and distribute those signals with Gemma 4 at the core of the intelligence layer.

What makes OCTIO different from existing oracles:
Chainlink, API3, and Band Protocol solve the general oracle problem, they relay data from off-chain to on-chain reliably. OCTIO is not a general oracle. It is a security-specific intelligence primitive that no existing oracle network addresses.
The key difference is the intelligence layer. Existing oracles relay data they move a number or a string from a source to a smart contract. OCTIO reasons about data. Gemma 4 identifies impersonation targets, assesses severity, explains its reasoning, and flags suspicious domains not yet in any threat feed, from domain pattern alone. When metamask-security-alert.com was queried, it was not in the registry, but Gemma 4 returned SUSPICIOUS/CAUTION from the domain structure alone. No existing oracle does this.
The second difference is incident correlation. When a DeFi protocol queries Chainlink, it gets a data point. When it queries OCTIO, it gets a threat assessment correlated against documented historical losses from similar attack patterns, giving protocol teams the context they actually need to make decisions.

Demo

Demo: GitHub: github.com/OCTIO-Labs/octio

Running the full system takes nine commands:
python3 monitor.py # fetch and classify live phishing URLs with Gemma 4
python3 dns_monitor.py # enrich with VirusTotal DNS data -- dual-source confidence scoring
python3 reputation.py # score domain reputation over time -- CONFIRMED_THREAT classification
python3 profiles.py # build protocol-specific risk profiles -- CRITICAL/HIGH risk ratings
python3 prediction.py # Gemma 4 predictive threat intelligence -- next-target prediction
python3 web3_bridge.py # submit verified indicators to live Sepolia contract
python3 oracle.py # run protocol query interface
python3 correlation.py # correlate against documented incidents
python3 dashboard.py # display full system dashboard

Sample oracle output:
[BLOCK ] [CRITICAL ] http://www.dpdlocoqu.cyou/com
[PROCEED] [SAFE ] https://uniswap.org
[CAUTION] [SUSPICIOUS] http://metamask-security-alert.com/connect
[PROCEED] [SAFE ] https://aave.com
[BLOCK ] [CRITICAL ] http://instagram.com.universal-api.org/

Code

GitHub: github.com/OCTIO-Labs/octio
The repository includes:

monitor.py: Live phishing feed monitoring with Gemma 4 threat classification.

dns_monitor.py: VirusTotal DNS enrichment layer, dual-source confidence scoring.

reputation.py: Cumulative domain reputation engine. Tracks how many times each domain has been flagged across runs, accumulates VirusTotal malicious votes, and produces CONFIRMED_THREAT, HIGH_RISK, SUSPICIOUS, and WATCH classifications.

profiles.py: Protocol-specific risk profiles. Groups active threats by impersonated platform: MetaMask, Ledger, Google, Babylon Chain — and produces CRITICAL, HIGH, MEDIUM risk ratings per protocol based on confirmed threat count and reputation scores.

prediction.py: Gemma 4 predictive threat intelligence. Analyses reputation scores and protocol profiles to predict which attack campaigns are escalating, which platforms will be targeted next, and produces a forward-looking 24-72 hour threat advisory.

web3_bridge.py: Submits verified indicators directly to the live ThreatRegistry.sol contract on Sepolia.

registry.py: On-chain registry simulation with keccak256 hash storage.

oracle.py: DeFi protocol query interface with Gemma 4 risk assessment.

correlation.py: Incident correlation against documented real-world hacks.

dashboard.py: Terminal dashboard for live threat visibility
contracts/ThreatRegistry.sol. Solidity contract for Sepolia testnet deployment.

The smart contract implements the full indicator submission, validation, and query interface described in the system architecture. Target domains are stored as keccak256 hashes rather than plaintex, reducing storage costs by 60 to 90% and preventing the registry from being used as a phishing directory.

How I Used Gemma 4

I chose the Gemma 3 27B Instruct model (google/gemma-3-27b-it) via OpenRouter. The 27B model has the reasoning depth needed to make nuanced security judgements, not just pattern matching.
Gemma 4 powers four distinct functions inside OCTIO:

(1). Threat Classification (monitor.py):
OCTIO pulls live URLs from OpenPhish, a real phishing feed updated continuously. Each URL is sent to Gemma 4 with a structured prompt asking it to classify the threat, assess severity, identify the impersonation target, and explain its reasoning.
Given the URL http://www.dpdlocoqu.cyou/com, Gemma 4 returned:

{
"is_threat": true,
"threat_type": "PHISHING",
"severity": "HIGH",
"target": "DPD (Delivery Service)",
"reasoning": "The URL uses a misspelling of DPD and a suspicious domain extension to impersonate the legitimate delivery service, likely to steal credentials potentially leading to crypto access."
}

This is not keyword matching. Gemma 4 understood the typosquatting pattern, identified the impersonated brand, and connected it to the crypto threat context from the URL alone.

(2). Risk Assessment (oracle.py):
When a protocol queries the oracle, Gemma 4 produces a final risk assessment combining registry data with its own domain pattern analysis. For http://metamask-security-alert.com/connect, which was not in the registry, Gemma 4 returned SUSPICIOUS/CAUTION based on the domain pattern alone. A rule-based system would have returned CLEAN. Gemma 4 understood the social engineering intent from the URL structure.

(3). Incident Correlation (correlation.py):
Gemma 4 analyses the current indicator set against a database of documented real-world Web3 hacks. Given five live phishing URLs, it correctly correlated them with the Ronin Network hack ($625M), Curve Finance DNS hijack ($570K), and MyEtherWallet BGP attack ($17M), and produced actionable recommendations for DeFi protocols.

(4). Predictive Threat Intelligence (prediction.py):
Gemma 4 analyses the accumulated reputation scores and protocol risk profiles to predict what comes next. Given current data showing Google/Gmail at CRITICAL risk with a reputation score of 306, Gemma 4 predicted Microsoft/Outlook and MetaMask as the next likely targets, a forward-looking inference no rule-based system can make.

Why the 27B model:
The 27B model was necessary for this task. Smaller models returned surface-level classifications without the reasoning depth needed to distinguish between a legitimate security alert and a phishing site designed to look like one. What Gemma 4 unlocked was a system that gets smarter as the threat landscape evolves, without retraining or updating rule sets.

Update: May 19, 2026: Bridge is live
Since publishing this post, the Web3 bridge is complete and the system is fully connected end-to-end.
web3_bridge.py now takes validated indicators from Gemma 4 and submits them directly to the live ThreatRegistry.sol contract on Sepolia. Over 70 verified phishing indicators are now on-chain across multiple monitoring runs.
Proof of one of the five transactions:
0x1768792ee102b834eea9a7a5ecccece0341892200b56fe28b140227e12434eca
View the live contract:
https://sepolia.etherscan.io/address/0xb0F4ae6f47eE001804d933dc8AD4b34969C91A69

Limitations and Next Steps

OCTIO is a working end-to-end system. The contract is live, verified, and populated on Sepolia. The following limitations are worth being clear about for anyone evaluating it for production use:
ThreatRegistry.sol is deployed and verified on Sepolia. Submitter authorisation is currently manual, the governance layer (ValidationPool.sol) is the next milestone. A live deployment requires testnet ETH and a Foundry deployment script.
Primary monitoring source is OpenPhish - VirusTotal DNS enrichment added for dual-source confidence scoring. Certstream and npm audit feeds planned.
Indicators are validated by both Gemma 4 and VirusTotal for dual-source confidence scoring. A multi-party governance layer where registered researchers vote on submitted indicators is planned but not yet implemented.
Gemma 4 can produce false positives. The reputation engine mitigates this, domains must accumulate score across multiple runs before reaching CONFIRMED_THREAT status. Human review remains recommended for production deployments.
The oracle interface simulates Chainlink integration. A real deployment requires a running Chainlink node and a registered External Adapter.
Despite these limitations, the core thesis is demonstrated: Gemma 4 can perform nuanced threat classification, catch suspicious domains not yet in any registry, and correlate current indicators against historical incidents, all in real time. The prototype shows the system works. The remaining work is engineering, not concept validation.

PicoCTF General Skills - 5 Challenge Walkthrough (Beginner Friendly)

James Kabingu — Sun, 17 May 2026 08:16:27 +0000

I've been working through PicoCTF challenges as part of building my cyber-security foundation. These are my notes from the General Skills category, five challenges that cover the core terminal skills every CTF player needs. I'll show exactly what I ran, what came back, and what it means.

Nice netcat: The server sends back a wall of numbers, one per line: 112 105 99 111

My first instinct was to look them up one by one in an ASCII table. That works, but there's a faster way. Each number is a decimal ASCII value. 112 is p, 105 is i, 99 is c, 111 is o. Once I saw the pattern I piped the output straight through Python:

nc -w 2 wily-courier.picoctf.net 53619 | python3 -c "import sys; print(''.join(chr(int(n)) for n in sys.stdin.read().split()))"

The -w 2 flag tells netcat (nc) to close after 2 seconds of silence, which lets the pipe complete. chr(int(n)) converts each decimal to its character. Flag prints immediately.

What I learned: when a server returns a list of numbers, assume ASCII first. Three anchor points worth memorising: 48 is 0, 65 is A, 97 is a.

Magikarp Ground Mission: SSH into a server, navigate between directories, and collect three parts of a flag. The instructions are literally in the files themselves.

ssh ctf-player@wily-courier.picoctf.net -p 55070
ls
cat 1of3.flag.txt
cat instructions-to-2of3.txt
cd /
cat 2of3.flag.txt
cat instructions-to-3of3.txt
cd ~
cat 3of3.flag.txt

The three files contain picoCTF{xxsh_, then 0ut_0f_//4t3r_, then 0b24fc4f}. Put together: picoCTF{xxsh_0ut_0f_//4t3r_0b24fc4f}
What I learned: cd / is root, cd ~ is home. Flags are sometimes split across locations deliberately to teach navigation.

First Find: An archive with a file called uber-secret.txt buried somewhere inside. The directory tree is deep and one of the folders is hidden.

wget https://artifacts.picoctf.net/c/502/files.zip
unzip files.zip
find . -name "uber-secret.txt"

output: ./files/adequate_books/more_books/.secret/deeper_secrets/deepest_secrets/uber-secret.txt

cat ./files/adequate_books/more_books/.secret/deeper_secrets/deepest_secrets/uber-secret.txt

Flag: picoCTF{f1nd_15_f457_ab443fd1}

What I learned: find . -name searches recursively and goes into hidden directories that ls won't show you. Get comfortable with this command.

Static ain't always noise: A binary file and a bash script called ltdis.sh. I read the script before running it. It does two things: disassembles the binary with objdump and extracts readable text with strings.

chmod +x ltdis.sh
./ltdis.sh static
grep "picoCTF" static.ltdis.strings.txt

Output:
3020 picoCTF{d15a5m_t34s3r_20335e41}

What I learned: binaries often contain embedded readable strings. strings extracts them all. grep finds the one you want. This combination comes up constantly in reverse engineering.

Plumbing: The server floods you with output. The flag is somewhere in there. bash nc fickle-tempest.picoctf.net 49418 | grep "picoCTF" Flag prints immediately: picoCTF{digital_plumb3r_A01Bc3eC} What I learned: the pipe operator passes one command's output directly into another without saving anything to disk. command | grep "pattern" is probably the most used one-liner in CTF general skills challenges.

Tools used across these five challenges
nc, python3, ssh, find, strings, grep, and the pipe operator

I'm continuing through PicoCTF. Next up is the Cryptography category. Follow if you want the writeups as they come.

DEV Community: James Kabingu