DEV Community: Mabera

What a call-graph traversal sees that contract-by-contract review cannot

Mabera — Sat, 17 Oct 2026 21:00:57 +0000

Most smart-contract review reads one contract at a time. You open the file, you look for the usual shapes — reentrancy, unchecked calls, oracle reads — and you write down what you find. The contract is the unit of analysis, and the audit report is a list of findings about that contract.

But the largest exploits of the last decade did not happen inside one contract. They happened on a route through several.

This post is about building an agent that refuses to certify a contract when its call graph reaches a weakness a real exploit actually used — and what the graph told me that reading contracts one at a time does not.

The thing that doesn't show up contract-by-contract

I seeded a small graph — 144 nodes and 217 edges at seed time (23 contracts, 76 functions, 34 CALLS edges, 20 SWC patterns, 10 exploits, plus libraries and auditors; 160 nodes once the agent files its own verdicts). Then I asked one question of it:

MATCH p = (a:Function)-[:CALLS*1..6]->(b:Function)
WHERE a.contract <> b.contract
RETURN a.contract, a.name, b.contract, b.name, length(p)
ORDER BY length(p) DESC

30 routes cross a contract boundary. Some of them are worth staring at:

from	to	hops
`bZx.executeTrade`	`AaveV2LendingPool.flashLoan`	2
`bZx.executeTrade`	`AaveV2LendingPool.executeOperation`	3
`bZx.liquidate`	`cUSDC.redeem`	3
`MakerVault.liquidate`	`cUSDC.redeem`	2
`1inchv3.swap`	`UniswapV2Router02._swap`	2

Every one of these functions is individually unremarkable. cUSDC.redeem is not a vulnerability. AaveV2LendingPool.flashLoan is the feature working as designed. MakerVault.liquidate is a liquidation function doing liquidation.

The risk is not in any node. It is in the route — and a review that opens one file at a time never sees a route, because a route lives in the joins between files.

That is the whole thesis, and it is why the graph is not decoration here. There is no contract you can point at and say "this is the dangerous one." There is a path.

Making the graph say what's actually dangerous

Once you can walk routes, the next problem is that most of them are fine. You need a rule that separates a route worth refusing from a route that is just... code calling code.

The naive rule is "flag if any node on the path has a vulnerability." That rule is bad, and it took a real run to show me how bad.

What I used instead: a route blocks only if a node on it carries a vulnerability that is connected to a real exploit — a two-hop join, evaluated per node on the path:

UNWIND $path AS fname
MATCH (f:Function {name: fname})-[hv:HAS_VULNERABILITY]->(v:Vulnerability)
WHERE hv.status IN ['exploited', 'pattern']
OPTIONAL MATCH (v)-[:EXPLOITED_BY]->(e:Exploit)
RETURN fname, v.swc, v.title, v.severity, hv.status,
       collect(DISTINCT e.name) AS exploits,
       collect(DISTINCT e.loss_usd) AS losses

The EXPLOITED_BY edge is doing the real work. A vulnerability pattern that no exploit ever used is a detector flag, not evidence — so the agent drops rows with no exploit behind them. What survives is a claim with teeth: this shape was used, in this incident, for this much money.

The result that made the design worth it

KyberSwapPool gets refused. The graph names its own evidence:

route reaching KyberSwapPool.getAmountsOut
blocked by SWC-128 (Oracle Manipulation)
which the graph connects to five real exploits: KyberSwap Flash Loan Attack ($307M), Cream Finance ($130M), Mango Markets ($112M), Beanstalk ($182M), Euler Finance ($197M)

$928M of documented loss behind one edge in the graph. The agent is not computing a risk score from a heuristic. It is reading the connections and refusing on them, and it can show you the path it read.

And the refusal is written back into the graph rather than into a log — a CertificationRequest{status: BLOCKED} linked via BLOCKED_BY_PATH to the exact functions responsible, with the evidence path stored as JSON on the request. That matters for one reason: the decision becomes replayable. Load the request, re-run the same traversal, get the same verdict. All 12 blocked contracts replay identical.

Two things that caught me out

1. A parameterised variable-length bound doesn't work.

I wanted the hop count configurable:

MATCH p = (a:Function {name: $fn})-[e:CALLS*1..$hops]->(b:Function)

That fails:

Encountered unhandled type in inlined properties

The confusing part is the error text. It says inlined properties, which sends you looking at your property maps — but {name: $fn} works fine, and the parameter is a plain Python int. The failure is specific to the hop bound: it has to be a literal in the pattern. I expanded a validated integer from Python instead, and wrote the reason into the code comment so the next person doesn't lose the same hour.

It fails at inline time, so the error points at the wrong part of the query. If you hit it: it's the *1..N, not your properties.

2. My detection rule was wrong, and the test caught it by disagreeing with itself.

First full run, the agent refused UniswapV2Router02 on an SWC-103 finding tagged pattern. Which was fine, except the verdict's own wording said "used in a real exploit" — and that SWC-103 node had no EXPLOITED_BY edge at all. Zero exploits behind it.

The bug was mine, not the graph's: I was treating "has a vulnerability" as the blocking condition. But a vulnerability node that no exploit ever touched is a theoretical pattern. Filtering those out flipped UniswapV2Router02 to CERTIFIED, which is correct — and it made the verdict text true, which it wasn't before.

The lesson I'd generalise: a detection rule that can't explain itself in the same words it reports is probably wrong. My one-line pitch claimed evidence-based refusal; the code was doing pattern-matching. The gap between the two is where the false positive lived.

What this does not do

Worth being precise, because "AI security tool" invites overclaiming:

It does not analyse source code. No Slither, no static analysis, no bytecode. It reasons over vulnerabilities and exploits already recorded in the graph.
It is not a live audit tool. The dataset is compiled from public post-mortems and the SWC registry, seeded into the graph. Ingestion from Etherscan is explicitly out of scope.
It is not a scanner. It will not find a new bug. It will tell you when the recorded evidence about a contract's reachable functions says "don't sign off on this."

That's a narrower claim than "AI audits your contracts," and it's the one the code actually supports.

Why a graph and not tables

The remove-the-database test: delete FalkorDB and does the product still work?

No. The product's core operation is "walk outward from this function, match what you reach against real exploit shapes, and file the result on the graph." In a table store that is a recursive CTE for the walk, another join chain per node for the matching, and then you have to reconstruct the path from row sets — and you still don't get the route list back in one shot, which is the thing the verdict has to name.

Cypher gives you the route as a value:

MATCH p = (a:Function {name: $fn})-[e:CALLS*1..6]->(b:Function)
RETURN length(p) AS hops,
       [n IN nodes(p) | n.name] AS path,
       [n IN nodes(p) | n.contract] AS contracts

path is a first-class result. That's what lets a refusal say "here is the 2-hop route through Aave that got you blocked" instead of "risk detected."

The takeaway

If your domain has relationships that carry meaning — call graphs, dependency chains, counterparty exposure, attack surfaces — the interesting findings live in the paths, not the rows. A per-entity review will look complete and miss the thing that actually took $928M.

The move that made this work wasn't a clever query. It was asking a question that only has an answer in a graph: is there a route from here to a weakness someone has already used?

Built for Graph Hacks 2026 (WeMakeDevs × FalkorDB), track: Agents That Act on Connected Data. Source: github.com/HusseinAdeiza/graphhacks-refusal-agent. Built with AI coding assistance (Hermes Agent), disclosed per the event rules; every query, schema decision, and verdict rule was verified against a live FalkorDB, and the repo's end-to-end suite (python3 -m agent.verify, 55 checks) is the proof it works as claimed.

I built an open-weight-model agent that finds OSS issues worth your time

Mabera — Tue, 13 Oct 2026 07:52:24 +0000

What I Built

ClaimScout — a tool that tells you which open-source issues are actually worth your time.

Point it at the repos you care about and it hands back a short list of issues that are genuinely yours to take: unclaimed, low-traffic, bounded bugs — not assigned work, not bot chores, not architecture epics dressed up as quick wins. Then, if you want, an open-weight model ranks that shortlist against your skills so the best first contribution floats to the top.

Who would pay for this? Anyone trying to land merged pull requests — hackathon entrants, bug-bounty hunters, developers building a hiring portfolio. The problem is real and expensive: I lost days this month trawling issue trackers for work that turned out to be already claimed, vaguely scoped, or a months-long epic. ClaimScout turns that grep-and-pray into a one-line command.

It found the two bugs I actually shipped PRs for — so I'm user number one, with receipts.

👉 Repo: https://github.com/HusseinAdeiza/claimscout

Demo

Here's a real run, not a mockup. Scanning marginfi-v2:

$ claimscout scan --repos 0dotxyz/marginfi-v2

0dotxyz/marginfi-v2: 10 claimable
  #705   unclaimed, 0 comment(s), created 2026-10-12  Same-asset-emode weight inversion
         labels: bug
  #682   unclaimed, 0 comment(s), created 2026-09-18  Allow empty-but-active integration balances to close
         labels: bug, good first issue
  #701   unclaimed, 0 comment(s), created 2026-10-10  Liquidation interplay with Order tagging
         labels: bug, low priority

Every line is a real, open, unassigned issue. Then the open-weight model ranks the shortlist against a Rust/Anchor skill profile:

$ claimscout scan --repos 0dotxyz/marginfi-v2 --max-comments 0 --json \
    | claimscout-rank --profile "rust,anchor,solana,security"

 1. #682   [90]  Allow empty-but-active integration balances to close
      Bounded bug with clear reproduction, matches contributor's skills
 2. #705   [80]  Same-asset-emode weight inversion
      Bounded bug, matches contributor's skills

Those two — #682 and #705 — are exactly the issues I went on to build and open PRs for. The ranker put them at the top on its own.

Run the whole thing yourself with ./examples/demo.sh.

Code

The core is ~250 lines of dependency-free Python (stdlib only, Python 3.9+). The scanner fetches and filters deterministically; the ranker is a separate, optional single-call step.

# The filter that does the real work — an issue is reported only if it is ALL of:
#   an issue (not a PR), unassigned, low-traffic, not architecture, not bot-authored,
#   and actionable (bug / good-first-issue / help-wanted, or a recent unlabelled report)
for i in issues:
    if "pull_request" in i:            continue   # PRs are not claimable issues
    if i.get("assignees"):             continue   # already assigned
    if i["comments"] > max_comments:   continue   # contested / already discussed
    labels = [l["name"] for l in i.get("labels", [])]
    if any(ARCH_LABELS.search(l) for l in labels): continue  # epic/roadmap/spike
    if (i.get("user") or {}).get("login", "").endswith("[bot]"): continue
    ...

Full source, tests, and the ranker are in the repo.

How I Built It

Two deliberate pieces:

1. The fetch/filter loop is plain code — no model in it. This is the whole design. I spent weeks watching small open-weight models try to drive multi-step agent loops, and they fail in a specific, ugly way: they call one tool five to eight times, give up, and the run still reports "ok." So ClaimScout never asks the model to fetch or filter. That's deterministic, testable Python. The model is only invoked at the very end, on an already-clean shortlist.

2. The model does one stateless call. When you enable ranking, ClaimScout sends the filtered shortlist to an open-weight model (meta/llama-3.2-11b via NVIDIA's OpenAI-compatible endpoint by default; any OpenAI-compatible server — local Ollama, vLLM — works) and asks for a ranked JSON array. No tool calls, no multi-turn loop, no agent harness. That's the exact workload a small model handles well.

It still needs guardrails. On the first live test the model answered with a Python code block instead of JSON, so the ranker strips code fences, extracts the array even when it's wrapped in prose, and issues one strict "JSON only" retry before giving up. There's a test for each of those failure modes — because I watched them happen.

19 stdlib unittest tests cover the triage filter, the messy-JSON parsing, and prompt construction.

Why Does Open Innovation Matter?

This is the part that decides whether the "side hustle" actually works, and it comes down to cost.

ClaimScout is useful per scan and used often — you run it every time you sit down to find work. A version built on a hosted API would call a paid model on every fetch, and that per-run cost is more than a contributor chasing a $100 bounty would ever pay. The economics only close because the model is open-weight and cheap to run. The open model isn't a nice-to-have here; it's the reason the product can exist at a price anyone would pay.

Second, it keeps your data yours. ClaimScout reads your repos and your skill profile. Running inference on an open model you control means that never has to leave for a third party to log.

Third, openness is what let me build around the model's real limits instead of an idealized demo. Because the model is open and I could test it directly, I designed the deterministic/model split around how it actually behaves — the same lesson that makes the tool reliable is the lesson that closed, black-box APIs hide from you until production.

Where the open approach beat a closed one: a hosted model would have cost more per scan than the tool is worth, and would have forced my fetch logic behind an API I couldn't inspect. The open-weight model made a cheap, private, inspectable tool possible — which is the only version of this that works as a hustle.

My Agent Session

ClaimScout was built inside an agent session — an AI coding agent driving the terminal, running the real toolchain, and iterating against live output. That's fitting, because the tool is itself about making agent-assisted open-source work reliable.

The session is where several of the design decisions were forced into the open rather than guessed at:

The model returned Python code instead of JSON on the first live ranker test. I caught it, added code-fence stripping, prose-array extraction, and a strict retry — then wrote a test for each failure mode. A closed API would have hidden that until production.
The amix of 16 delayed narration clips collapsed to ~0s because amix truncates to the shortest stream. Fixed by padding each clip with apad to the full timeline.
edge-tts silently dropped a line (0-byte file) twice — fixed with retries, which is now why the voiceover generator re-attempts.

The honest thread through all of it: build around what the open model actually does, verified by running it, not what the demo says it should do. That's the same principle ClaimScout encodes in its architecture.

My First User

Me — and it paid off concretely.

I built ClaimScout to solve my own Hacktoberfest problem, then used it the same week. It surfaced marginfi-v2 #682 (a stuck integration-balance bug) and #705 (a same-asset e-mode weight inversion). I opened PRs for both. Earlier in the session, the same fetch-and-filter approach caught a cosmos-sdk PR getting closed by a maintainer — the kind of signal you only get if something is watching your PRs, not just the issue board.

The first "user" is a developer who'd been burned by claimed-and-gone issues, and what they asked for next was exactly what I built: just tell me which ones are actually mine.

Giving AI Agents a Memory of Your Crisp Inbox

Mabera — Sat, 10 Oct 2026 05:16:59 +0000

Giving AI Agents a Memory of Your Crisp Inbox

AI agents forget everything. Every LLM call starts from zero — no idea what your customer asked yesterday, what your team answered, or how a bug was actually diagnosed. Cognee is an open-source memory layer that fixes this: you feed it your data, it builds a knowledge graph, and agents can then recall that knowledge across sessions.

The hard part is getting the data in. Cognee has a handful of connectors, but the world runs on dozens of tools. As part of Mergetober (open-source month with Cognee), I built a Crisp connector — wiring the shared-inbox support tool into Cognee so agents can answer questions about what customers actually asked.

This is the story of how it works, and a few design decisions that were less obvious than they looked.

The problem: chat inboxes don't fit neatly

Crisp is a shared inbox — visitors chat with your team, conversations accumulate. At first glance it's simple: read conversations, feed them to Cognee. But chat data has a shape that fights you:

Sessions are short and numerous. One conversation might be three messages ("how do I reset?" → "click here" → "thanks"). Ingest each message as its own node and your graph explodes into thousands of near-identical fragments.
There's no delete feed. When a conversation is closed or aged out, Crisp just... stops listing it. There's no webhook saying "this was deleted."

Both of these drove the design.

Decision 1: one node per conversation, not per message

The connector aggregates an entire conversation into a single markdown document — visitor context plus the full transcript:

Visitor: Ada · chat

Visitor: I can't find my invoice
Agent: I've resent it to your email — check spam?
Visitor: Got it, thanks!
This keeps the graph readable and matches how humans think about a support thread as one unit of meaning. It's the same call the existing Slack connector makes, and it's what the Cognee maintainers flagged in the issue itself.

Decision 2: full-snapshot sync, because there's no delete feed

Cognee already has a "forget-on-delete" mechanism: if a record drops out of the snapshot between two syncs, its orphan-cleanup removes it from the graph. But that only works if the connector loads a complete snapshot each run — the exact set of conversations currently visible — rather than merging in new ones.

So the connector uses write_disposition="replace": every sync rewrites staging with all current conversations. A conversation deleted upstream simply isn't in the new snapshot, and Cognee forgets it. Unchanged conversations keep a stable content-hash ID, so they're not re-processed and re-cognified.

The subtle trap: a partial snapshot must never land

Here's the part that took the most care. Because "absent from snapshot" is interpreted as "deleted," a partial snapshot — say the API returned an error halfway through — would make Cognee forget a batch of perfectly live conversations. A flaky network would silently erase memory.

So the connector treats a render or API failure as fatal: it aborts the run and leaves the previous memory intact, rather than committing a truncated snapshot. Transient errors (rate-limits, 5xx, timeouts) are retried with backoff first; only a persistent failure aborts. Getting this wrong would be the kind of bug that quietly corrupts memory for weeks before anyone notices.

Incremental sync
https://github.com/topoteretes/cognee

Re-cognifying the entire inbox on every run is wasteful. Crisp exposes updated_at on each conversation, so the connector takes an optional since= watermark and only renders conversations updated after it. Combined with the stable content-hash IDs, a daily sync only touches what actually changed.

Auth: Crisp's two-part token

Crisp authenticates with a two-part keypair (identifier + key) sent as HTTP Basic, plus an X-Crisp-Tier: plugin header, plus a website_id selecting the workspace. Not OAuth — a plugin token you generate from the Marketplace. Straightforward once you know the trio.

Using it

pip install cognee-community-connector-crisp

export CRISP_IDENTIFIER="..."
export CRISP_KEY="..."
export CRISP_WEBSITE_ID="..."

import cognee
from cognee_community_connector_crisp import crisp_source

await cognee.remember(
crisp_source(), # or since= for incremental
dataset_name="crisp",
max_rows_per_table=0, # ingest the whole inbox
)

answer = await cognee.search(
query_text="What did customers complain about this month?",
query_type=cognee.SearchType.GRAPH_COMPLETION,
datasets=["crisp"],
)

Then you can ask your agent "summarize the billing complaints from last week" and it actually knows — because the inbox is in its memory.

Testing without a live account

The test suite mocks the Crisp API (no token needed) and covers the parts most likely to break: message/conversation rendering, Crisp's page-number pagination, the document-source tagging that routes conversations through normal cognify, and the full-snapshot forget-on-delete behavior — including the case where a conversation vanishes from the listing between syncs and must be forgotten. 13 tests, all passing, plus ruff clean.

What's next

The connector is open as a PR against cognee-community. Once merged, "ask my Crisp inbox" becomes one crisp_source() away — and it's a template for the next chat-tool connector, because the same full-snapshot + aggregate-per-thread pattern applies to Intercom, Front, Zendesk, and the rest.

If you're doing Mergetober too, the Crisp connector is a decent reference for the shape a Cognee data-source connector should take. And if you try it against your own inbox, I'd genuinely like to hear what breaks — chat APIs always have one more pagination quirk than the docs admit.