Skip to content
0xSemantic

Security

Hawk-i

Security intelligence for Web3 smart contracts

Role
Creator and lead developer
Built with
  • Python
  • Solidity
  • tree-sitter
  • LiteLLM
  • Docker
  • Foundry
  • Hardhat
  • SQLite
  • web3.py

A security intelligence platform for Solidity smart contracts. It reads a contract, reasons about it, then tries to break it in a sandbox, and reports what it found with the evidence attached. It ships as a command line tool, a CI step, and a hosted product.

01

Why it exists

A smart contract audit is expensive, slow, and finite: it is a snapshot of one version of the code, taken once. Contracts, meanwhile, are upgraded, deployed to chains they were never reviewed on, and inherit dependencies that change underneath them.

Static analysers were the usual answer, and they produce long lists of theoretical findings that a team learns to ignore. The gap worth closing was not detection, it was proof. A finding that arrives with a working exploit is not a suggestion.

02

What was built

An autonomous agent that plans its own attacks. It runs a loop of plan, execute, record, and account for the budget, with three planners behind one interface: one drains known attack scripts, one blends the two, and one invents novel attacks. When it invents one, a code generator synthesises a working proof of concept and runs it inside a sandbox, so a novel finding still arrives with a reproduction.

Bytecode verification, which compares what is deployed against what was written, dependency intelligence, and upgrade safety analysis, so a contract is judged as deployed rather than as published.

Formal verification, continuous monitoring, a registry, telemetry, and a pre-flight health check, each reachable as its own subcommand.

Reporting in two styles, an audit report and a bounty submission, rendered from templates to HTML, PDF, or JSON, over a scoring engine that weights findings by severity and maps the result to a risk band.

03

Architecture

The scan is a pipeline, and each stage may be skipped without invalidating the ones around it: index, static rules, optional AI reasoning, optional sandbox, dependency analysis, then scoring and reporting.

Indexing parses through tree-sitter, so the analysis works on a syntax tree rather than on regular expressions, and the same indexer handles a local path, a remote repository, or a deployed address recovered from an explorer or from bytecode alone.

The rule engine discovers its own rules, so adding a class of vulnerability is adding a file rather than editing a dispatcher. Findings are enriched by a remediation engine that attaches the explanation, the impact, and the fix alongside the vulnerable snippet, because a finding without a fix is homework.

04

My contribution

Creator and lead developer. The pipeline, the rule and remediation engines, the autonomous agent, the sandbox, the scoring model, the reports, the packaging, and the product site.

05

Engineering challenges

Bounding an agent that writes and runs its own code. The budget is a dual limit, on attempts and on tokens, and the loop asks permission to continue before every step rather than checking afterwards. Generated exploits execute in a Docker sandbox, never on the host.

Reaching a contract that exists only as bytecode at an address, where there is no source to parse and the explorer may not have it either.

Keeping the analysis honest about the difference between a rule firing and a vulnerability existing, which is what the sandbox stage is for.

06

Result and impact

Published on PyPI and installable with pip install hawki, with optional extras for HTML and PDF reporting. It also ships as a container image and runs as a step in a pipeline, emitting annotations the host understands rather than a report someone has to go and read.