What it is

ExploitArena is a bug bounty protocol that replaces human triage with AI agents and a smart contract. A developer locks ETH in an escrow contract for a target repository. Attacker agents try to exploit the code inside isolated cloud sandboxes. Verifier agents then reproduce the exploit independently, score its severity, and vote on-chain. The contract pays the attacker according to the score.

The problem

Bug bounty programs depend on security experts to review each submission. That review is slow and costly, and it grows with the number of deployed contracts. Smart contracts make the delay worse: they are immutable and hold real assets. Bounty platforms also lack a shared, machine-readable severity scale on-chain, even though traditional security uses CVSS (Common Vulnerability Scoring System). ExploitArena automates the pipeline from submission to payout and ties payouts to a CVSS-style score.

How it works

The repository is a pnpm and Turborepo monorepo. Each package covers one stage of the pipeline.

The orchestrator (packages/agents/src/orchestrator/index.ts) runs this sequence:

1. A developer creates a bounty with a GitHub URL, an ETH deposit, and a deadline.
2. The orchestrator starts three attacker agents by default. Each gets its own E2B cloud sandbox with the target repository cloned.
3. Each attacker explores the code, writes a proof-of-concept (PoC) exploit, runs it, and submits the result with the test output.
4. The orchestrator picks the highest-severity exploit and submits it to the contract. The exploit code and steps go on-chain as an artifact event when they fit the size limit.
5. Five verifier agents start by default, each in a fresh sandbox with the same repository and the exploit files. Each verifier tries to reproduce the exploit and reports CVSS metrics.
6. Code in packages/shared/src/cvss.ts turns the metrics into a score and a vector string. Each verifier casts its vote from its own wallet.
7. The contract resolves the exploit on the third vote. It confirms the exploit only if all three votes confirm.
8. On confirmation, the contract credits the attacker with a share of the bounty set by the average score. It credits the rest to the developer. Both collect with withdraw().
9. If no exploit resolves before the deadline, the developer can call claimRefund().

The payout tiers in _calculatePayout are:

What I built

I built the agent loops for the attacker agents (the red team) and the verifier agents (the blue team) on the Vercel AI SDK, and the MCP servers they use. I also built the scoring system and the dashboard.

Design decisions

Proof by execution. The attacker prompt and the submit_exploit tool description both require a PoC that ran successfully. The alternative is to accept a written report. Execution removes plausible but wrong findings. The trade-off is that this rule lives in the prompt, not in code: the tool accepts any payload. The independent verifiers are the real check.

One sandbox per agent. Every attacker and verifier gets its own E2B sandbox, with a 10-minute default timeout, and the orchestrator destroys it in a finally block. Sharing one sandbox would be cheaper. Isolation stops one agent from reading or changing another agent's work, at the cost of one sandbox start and repository clone per agent.

The model picks metrics, code computes the score. The verifier's output schema asks for CVSS base metrics (attack vector, complexity, impact, and so on), not a number. The function calculateCvssScore then computes the score. Its source comment says it is a simplified approximation of the CVSS v4.0 algorithm, which uses a lookup table of macro-vectors. This makes scoring repeatable, but the scores do not match the official calculator. The contract stores the score as an integer times ten (93 means 9.3) and stores a hash of the vector, so it needs no floating-point math.

A small, owner-managed verifier set. Only addresses that the contract owner enrolls can vote, and a vote cannot be cast twice by the same address. The contract allows at most five votes per exploit and resolves at three. This keeps on-chain loops short and cheap. It also means the owner is a trust anchor for enrollment, although the owner has no say over individual outcomes. Votes after the third are rejected because the exploit is no longer in the verification phase.

Pull payments and event artifacts. The contract credits balances and lets users withdraw, instead of sending ETH during resolution. A failing recipient cannot block a resolution. Large payloads such as exploit code and verifier reasoning are emitted as events, capped at 24 KB each, rather than stored. Events keep the evidence on-chain and auditable at lower cost than contract storage (an inference from the design). The contract also accepts EIP-712 signed submissions and votes with per-signer nonces, so a relayer can submit on an agent's behalf.

Run it locally

You need Node.js 18 or later, pnpm 9 or later, an E2B API key, and an OpenAI API key or any OpenAI-compatible endpoint.

1. Clone the repository, install dependencies, and create the environment file:

   git clone https://github.com/WhyAsh5114/exploit-arena && cd exploit-arena
   pnpm install
   cp .env.example .env
   

2. Set E2B_API_KEY and OPENAI_API_KEY in .env. OPENAI_BASE_URL and OPENAI_MODEL are optional. The .env.example file lists which package reads each variable.

3. Build the workspace:

   pnpm build
   

4. In one terminal, start a local Hardhat node:

   cd packages/contracts && pnpm node
   

5. In a second terminal, run the end-to-end demo:

   pnpm --filter @exploit-arena/cli exec arena demo
   

6. Optionally, start the web dashboard at http://localhost:3000:

   pnpm --filter @exploit-arena/web dev
   

Reference

Defaults in the orchestrator and contract:

Stack:

Outcome

ExploitArena placed second at GajShield Hack X, a 36-hour hackathon at KJSSE in Mumbai on 12 April 2026. A team of three entered. The repository was created on 11 April 2026 and has 36 commits through 12 April 2026. It uses the MIT license.