💻 computer science

SPEAR: An Engineering Case Study of Multi-Agent Coordination for Smart Contract Auditing

This paper presents SPEAR, a multi-agent coordination framework for smart contract auditing that leverages specialized agents, negotiation protocols, and belief revision to enhance planning, task allocation, and autonomous recovery compared to centralized or pipeline-based alternatives.

Original authors: Arnab Mallick, Indraveni Chebolu, Harmesh Rana, Seema Pangal

Published 2026-04-10

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Arnab Mallick, Indraveni Chebolu, Harmesh Rana, Seema Pangal

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are the manager of a massive, high-stakes construction project. Your goal is to build a digital vault (a Smart Contract) that holds billions of dollars in cryptocurrency. If there is even one tiny crack in the wall, thieves can steal everything.

Traditionally, hiring a team of human experts to inspect this vault takes weeks and costs a fortune. They look at the blueprints, test the locks, and check the foundations. But with thousands of new vaults being built every day, human experts can't keep up.

Enter SPEAR. Think of SPEAR not as a single super-intelligent robot, but as a highly organized, self-managing construction crew made up of specialized digital workers (agents). Instead of one boss micromanaging every screw, these workers talk to each other, make their own decisions, and fix their own mistakes.

Here is how the SPEAR crew works, broken down into simple roles:

1. The Crew Members (The Agents)

The Planner (Planning Agent):
- Role: The Site Foreman.
- Job: They look at the whole project and decide which part of the vault to check first. If they hear a rumor that a specific door is weak, they immediately tell everyone to stop checking the roof and focus on that door. They constantly update the "to-do" list based on new information.
The Doers (Execution Agents):
- Role: The Inspectors.
- Job: They actually run the tests. They use different tools (like flashlights, stress-testers, and code scanners) to find cracks. If they find a problem, they don't just shout "Help!"; they send a message to the Planner to update the plan.
The Fixer (Repair Agent):
- Role: The Handyman.
- Job: Sometimes, the tools the crew uses generate a report that is broken (like a test script that won't run). Instead of giving up and calling a human, the Handyman tries to fix it themselves. They try simple, mechanical fixes first (like tightening a loose screw). Only if that fails do they call in the expensive "AI expert" to rewrite the code.
The Referee (Coordinator Agent):
- Role: The Resource Manager.
- Job: Everyone needs money (computing power) and time. If the Fixer needs 500 tokens to fix a bug and the Inspector needs 200 to run a test, they can't both have it. They hold a quick auction. The one who needs it most urgently and offers the best value wins the resources.

2. How They Talk (The Coordination)

In old systems, if one tool crashed, the whole project stopped, and a human had to restart it. In SPEAR, the crew is decentralized.

The "Contract Net" (Job Bidding): When a task comes up, the Doers don't wait for orders. They bid on it. "I can do that!" says one. "I'm faster!" says another. The best one gets the job.
The "Belief System" (Adapting to Change): Imagine the Planner thinks the roof is the most dangerous part. Suddenly, the Inspector finds a huge crack in the foundation. In a rigid system, the Planner would ignore this until the end of the day. In SPEAR, the Inspector sends a message, and the Planner instantly updates their "beliefs" and changes the plan right now.
Self-Healing: If a network cable gets cut (a "network partition"), the Fixer doesn't panic. They keep working on what they can see locally. As soon as the connection is restored, they just send a quick update: "I finished the job while you were gone." No time is wasted.

3. Why is this better than a "Central Boss"?

Imagine a traditional audit as a single conductor trying to lead an orchestra. If the conductor trips, the music stops. If the conductor gets confused, the whole band stops.

SPEAR is like a jazz band.

If the drummer (Execution Agent) misses a beat, the bassist (Repair Agent) covers for them.
If the saxophone player (Planner) hears a new melody, they signal the others, and the whole band improvises a new song together without stopping.
They don't need a single person to tell them what to do next; they listen to each other and adapt instantly.

4. The Results

The paper tested this "Jazz Band" approach against a "Conductor" approach (a traditional, centralized computer program).

Speed: SPEAR found the most dangerous holes in the vault much faster because it prioritized the risky parts first.
Resilience: When the researchers intentionally broke tools or cut the internet, SPEAR kept working. The centralized system crashed and had to restart. SPEAR just kept playing jazz.
Cost: Because the Fixer tried simple solutions before calling the expensive AI, SPEAR saved a lot of money.

The Bottom Line

SPEAR is a smart, self-healing team of digital workers that audits blockchain code. Instead of waiting for a human boss to fix every mistake, they talk to each other, bid for resources, and fix their own broken tools. This makes the process faster, cheaper, and much harder to break, ensuring that the billions of dollars in the digital vault stay safe.

1. Problem Statement

The rapid growth of Decentralized Finance (DeFi) has led to smart contracts securing billions of dollars, yet they remain highly vulnerable to catastrophic exploits (e.g., the DAO hack). Current auditing practices face three critical bottlenecks:

Scalability: Manual audits are slow (2–4 weeks) and expensive ( $5k–$ 15k), failing to keep pace with Web3 development.
Limitations of Automated Tools: Existing automated tools (static analysis, symbolic execution, fuzzing) are largely reactive (scanning isolated files without holistic context), brittle (generated test artifacts often fail to compile/run without autonomous recovery), and uncoordinated (operating as standalone programs without a framework to synthesize diverse outputs).
Dynamic Complexity: Auditing is a dynamic mission where findings in one module alter the risk assessment of others, requiring adaptive planning and resource management under budget constraints.

2. Methodology: The SPEAR Framework

The authors propose SPEAR (Strategic Planning, Execution, and Automated Repair), a multi-agent system (MAS) that models smart contract auditing as a coordinated mission rather than a linear pipeline.

Core Architecture

SPEAR consists of five specialized agent classes that maintain local beliefs, communicate via structured messages, and coordinate through explicit protocols:

Planning Agent ( $A_P$ ): Maintains a risk-aware audit policy. It prioritizes contracts based on dynamic risk scores (complexity, dependencies, test coverage) and revises plans when new findings emerge.
Execution Agent ( $A_E$ ): Allocates and schedules analysis tasks (static analysis, fuzzing, symbolic execution) using the Contract Net Protocol.
Repair Agent ( $A_R$ ): Autonomously recovers from "brittle" generated artifacts (e.g., test code that fails to compile) using a Programmatic-First Repair (PFIR) policy.
Command Execution Agent ( $A_C$ ): Safely executes tools within sandboxed environments (e.g., Docker containers) and enforces resource limits.
Coordinator Agent ( $A_{Coord}$ ): Mediates conflicts and allocates shared resources (e.g., LLM tokens) via Resource Auctions.

Key Coordination Mechanisms

AGM-Compliant Belief Revision: Agents update their local knowledge bases using the AGM theory (Alchourrón, Gärdenfors, Makinson). When new evidence (e.g., a vulnerability found) conflicts with prior assumptions, agents perform minimal changes to restore consistency without restarting the mission.
Plan Negotiation: When a new vulnerability is detected, the Execution Agent informs the Planning Agent. If the risk change exceeds a threshold ( $\theta=0.15$ ), they negotiate a revised priority plan via INFORM and PROPOSE messages.
Resource Auctions: To allocate scarce resources (like LLM tokens), agents bid based on urgency, benefit, and cost. The Coordinator awards resources to the agent with the highest efficiency ratio ( $\frac{urgency \times benefit}{cost}$ ), ensuring allocative efficiency without requiring a central truth-telling mechanism.
PFIR (Programmatic-First Repair): The Repair Agent prioritizes deterministic fixes (e.g., adding missing imports, fixing syntax) over costly generative (LLM-based) repairs. It only escalates to generative repair if the artifact remains mission-critical after local fixes fail.

3. Key Contributions

Engineering Case Study: Demonstrates how established MAS patterns (Contract Net, auctions, belief revision) can be applied to autonomous smart contract auditing.
Risk-Aware Planning: A Planning Agent that dynamically prioritizes audit tasks based on evolving risk assessments rather than static ordering.
Autonomous Self-Healing: A Repair Agent implementing a PFIR policy that significantly reduces reliance on expensive generative AI calls by fixing mechanical errors programmatically.
Coordination Framework: A system supporting autonomous recovery and resource arbitration under failure scenarios, contrasting with centralized schedulers.
Empirical Evaluation: A rigorous comparison of the multi-agent design against centralized and pipeline-based alternatives, focusing on coordination, recovery behavior, and resource efficiency.

4. Experimental Results

The framework was evaluated on the Damn Vulnerable DeFi (DVD) benchmark (15 challenges) and a real DeFi protocol (47 contracts).

Effectiveness (RQ1): SPEAR achieved the highest F1-score (0.87) compared to baselines like Sequential Pipelines (0.82) and a Centralized Scheduler (0.83). While the centralized scheduler performed similarly under normal conditions, SPEAR showed lower variance and more stable progress under injected failures.
Self-Healing Efficiency (RQ2): The PFIR algorithm achieved a 94% repair success rate. Crucially, 64% of repairs were handled deterministically, significantly reducing LLM invocation costs compared to "LLM-only" or "Retry-only" baselines.
Audit Efficiency (RQ3): The Strategic Planning Agent reduced the Time to First Critical Vulnerability (TFCV) significantly. The planning-driven mode identified critical issues much faster than an ablated version analyzing contracts in alphabetical order.
Robustness & Ablation (RQ4): Systematic ablation studies revealed the specific contributions of MAS components under failure scenarios:
- Protocols: Enabled 1.8x faster recovery (2.3 min vs. 4.1 min) and reduced LLM invocations by 15%.
- Autonomy: Enabled 2.1x faster recovery by allowing agents to adapt locally without waiting for a central controller.
- Self-Healing: Enabled 3.2x faster recovery (2.3 min vs. 7.4 min) and reduced LLM invocations by 31%, preventing cascading failures.
- Overhead: The coordination overhead was minimal (4.2%), scaling linearly with the number of agents.

5. Significance and Conclusion

SPEAR represents a shift from reactive, linear auditing tools to adaptive, self-healing multi-agent systems.

Resilience: By decentralizing decision-making and implementing local belief revision, SPEAR handles partial observability and independent agent failures (e.g., network partitions, tool crashes) more gracefully than centralized systems.
Cost Efficiency: The PFIR policy drastically reduces the cost of automated auditing by minimizing expensive LLM calls for simple mechanical fixes.
Scalability: The framework demonstrates that established MAS coordination patterns can effectively orchestrate heterogeneous tools (static analyzers, fuzzers, formal verifiers) to solve complex, dynamic security problems.

Limitations & Future Work: The study assumes tool completeness (which is not always true in reality) and relies on a central Coordinator Agent (a potential single point of failure). Future work aims to integrate reinforcement learning for policy optimization, expand tool integration, and explore fully distributed coordination without a central arbiter.