💻 computer science

Chiral Analysis of Smart Contracts: Detecting Vulnerabilities from Relational Inconsistencies Across Business Paths

This paper introduces "chiral analysis," a relational static analysis model implemented in the ChiralDetector tool that detects smart contract vulnerabilities by identifying inconsistencies between semantically paired business paths, effectively uncovering complex logic bugs that traditional single-function analyzers miss.

Original authors: Yue Xue

Published 2026-07-21

📖 6 min read🧠 Deep dive

CC BY 4.0

Original authors: Yue Xue

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

The Detective's Dilemma: When Code Lies by Omission

Imagine you are a detective trying to solve a mystery in a bustling city. Usually, you look for a smoking gun: a broken window, a muddy footprint, or a suspicious note. In the world of computer code, specifically the "smart contracts" that run on blockchains, traditional security tools act like this detective. They scan the code line-by-line, looking for obvious mistakes like a missing lock on a door or a math error in a calculation. These tools are great at finding "local" bugs—the kind that happen in a single room.

But what if the crime isn't in the room at all? What if the mystery is that the front door is locked, but the back door is wide open, and the two doors were supposed to be part of the same security system? In computer science, this is called a "relational" problem. It's not about one broken piece; it's about two pieces that should match but don't. This paper explores a new way to catch these sneaky bugs by comparing pairs of code paths, treating them like mirror images that must reflect the same truth. If one path says "stop" and the other says "go," the system is broken, even if both "stop" and "go" look perfectly fine on their own.

The Paper: Chiral Analysis and the Mirror Test

This paper introduces a clever new method called Chiral Analysis. The word "chiral" comes from chemistry, describing objects that are mirror images of each other but cannot be perfectly stacked on top of one another (like your left and right hands). In the world of smart contracts, the authors propose that many business operations come in pairs: a "single" trade and a "batch" trade, a "buy" and a "sell," or a "preview" of a price and the "execution" of that price. These pairs are the chiral twins of the code.

The core idea is simple yet powerful: treat these pairs as if they are checking each other's homework. If a user buys an item, the code should charge them a fee. If that same user sells the item later, the code should handle the money in a way that makes sense with the original buy. If the "buy" path charges a fee in dollars but the "sell" path accidentally refunds in a different currency, or if the "batch" version forgets to refund money that the "single" version returns, a bug exists. The paper argues that these bugs are invisible to standard scanners because each individual line of code looks correct. The error only appears when you hold the two paths up to the mirror and see they don't match.

To find these invisible errors, the authors built a prototype tool called ChiralDetector. Think of this tool as a super-smart intern who has a specific job description. First, it reads the entire codebase and maps out every possible "business path" (like tracing every route a customer can take through a store). Then, it uses a "static ranker"—a set of simple rules—to guess which paths might be chiral twins. For example, it might look for a function named buy and another named sell that touch the same bank account.

Once it has a list of potential twins, it calls in the heavy hitter: a Large Language Model (LLM), which is a type of AI that understands human language and code. The AI doesn't just look for errors; it acts like a logician. It asks, "If these two paths are supposed to be mirrors, what rules should they follow?" It checks seven specific dimensions:

Guards: Did both paths check the same passwords or permissions?
Actors: Did the same person pay and receive money in both?
State: Did both paths update the database in the same way?
Value: Did they handle fees and refunds consistently?
Order: Did they do things in the same sequence?
Failure: If things go wrong, did both paths crash or recover the same way?
External: Did they trust the same outside sources?

If the AI finds a mismatch, it doesn't just scream "Bug!" immediately. It passes the finding to a "strict validator." This validator is a skeptical editor who tries to prove the AI wrong. It asks, "Is this really a bug, or is it just a design choice?" Finally, the tool groups similar findings together so that instead of reporting 100 tiny errors, it reports the one big root cause.

The Results: Finding the Hidden Glitches

The authors tested this system on a real-world project called the Phi protocol. The results suggest that this approach works, though it's still a work in progress.

Here is what happened in their experiment:

The tool started by looking at 3,217 pairs of code paths.
After filtering out the ones that clearly weren't related, it kept 1,643 pairs to investigate deeply.
The AI detector found 201 potential issues (a mix of "suspicious" and "confirmed" candidates).
After grouping similar reports and removing duplicates, this shrank to 101 groups.
A strict validator cut this down further to 44 confirmed positives.
Finally, after a human expert reviewed the root causes, the team identified 13 unique, effective issues.

These 13 issues were the kind of things standard tools missed. For example:

The "Proof" Mix-up: A system allowed a proof of ownership to be reused for a different item because the "buy" and "claim" paths didn't bind the proof to the specific item correctly.
The Fee Confusion: One part of the system calculated fees in "basis points" (a unit of percentage) while another part treated the same number as "wei" (a tiny unit of currency), leading to massive financial errors.
The Refund Trap: When a user overpaid, the "single" trade path refunded the money to the user, but the "batch" trade path accidentally sent the refund to an intermediate contract, leaving the user empty-handed.

The authors suggest that this method is particularly good at catching "business logic" bugs—errors in how the system thinks about money and rules—rather than simple typos. They note that the process isn't perfect; it generated a lot of "noise" (false alarms) that had to be cleaned up, and it relies on the AI to be smart enough to spot the relationship. However, the fact that it found 13 distinct, high-impact issues that other tools missed suggests that looking at code through the lens of "chiral pairs" is a promising new direction.

The paper concludes that while this isn't a magic wand that solves every security problem, it offers a structured way to find the bugs that hide in the spaces between lines of code. By treating code paths as mirror images, we can finally see the cracks that appear when the reflection doesn't match the object.

Technical Summary: Chiral Analysis of Smart Contracts

1. Problem Statement

Smart contract vulnerabilities frequently stem not from isolated unsafe statements, but from relational inconsistencies between business paths that are semantically paired but syntactically distinct. Common examples include discrepancies between:

Single vs. batch entry points.
Direct vs. adapter-based flows.
Quote (preview) vs. execution paths.
Inverse operations (e.g., buy vs. sell, mint vs. burn).

Existing static analyzers excel at detecting local syntactic patterns, taint-style dependencies, and single-function vulnerabilities (e.g., reentrancy, unchecked calls). However, they lack an "oracle" for relational bugs: they cannot determine if two corresponding paths preserve the same guards, state transitions, value flows, or failure behaviors. These bugs often require comparing the logic of a wrapper against a core function, or a batch dispatcher against a single-operation path, to be detected.

2. Methodology: Chiral Analysis

The paper introduces chiral analysis, a relational model treating semantically paired business paths as implicit specifications for one another. The term "chiral" captures operations that are mirror-like, alternative, or lifecycle-related (e.g., single/batch, wrapper/core) without requiring syntactic identity.

2.1 The Chiral Vulnerability Model

The authors formalize a chiral relation ( $R_\chi$ ) as a static analogue of a metamorphic relation. It consists of two paths ( $p, q$ ), a relation type ( $\tau$ ), and a set of relation-induced obligations. These obligations are approximations of expected behaviors across seven semantic dimensions:

Guard: Modifiers, preconditions, and eligibility checks.
Actor: Identities of callers, signers, payers, and refund recipients.
State: Read/write sets, flags, counters, and state deltas.
Value: Units, fees, rewards, transfers, and refund handling.
Order: Check-effect-interaction sequences and settlement timing.
Failure: Revert behavior, partial success semantics, and event emission.
External: Oracle usage, callbacks, and cross-contract dependencies.

A chiral vulnerability is defined as a violation of such an obligation that results in a feasible security or protocol impact (e.g., loss of funds, unauthorized state change, or accounting errors).

2.2 The ChiralDetector Pipeline

The authors implement this model in ChiralDetector, a four-stage pipeline designed to balance recall with precision while managing Large Language Model (LLM) costs:

Path Extraction & Summarization:
- Constructs a project-level call graph from Solidity source code.
- Extracts "business paths" (single functions, entry-to-leaf chains, and fork segments).
- Generates a semantic fact summary ( $\Phi(p)$ ) for each path, capturing storage reads/writes, value transfers, modifiers, and external calls. This abstraction is intentionally lossy but relation-oriented.
Candidate Pair Reduction:
- Avoids exhaustive $O(n^2)$ comparisons by using a static ranker.
- Scores path pairs based on shared storage footprints, overlapping external calls, naming hints (e.g., "claim" vs. "batchClaim"), and actor/value-flow similarities.
- Prioritizes pairs likely to form a chiral relation without deleting uncertain high-recall signals.
Semantic Filtering & Detection (LLM-based):
- Semantic Filter: Determines if a pair plausibly forms a chiral relation and assigns a relation type (e.g., inverse, wrapper/core). It is instructed to accept pairs with different path lengths or opposite economic directions.
- Relation-Aware Detector: Given a confirmed relation, the LLM identifies specific violated obligations, provides source evidence, and formulates an impact thesis. Prompts are structured as "contracts" to force explicit reasoning rather than vague conclusions.
Strict Validation & Deduplication:
- A strict validator attempts to falsify findings by checking if the relation is justified, if evidence exists, and if alternate code paths invalidate the impact.
- Root-cause deduplication merges multiple reports that share the same underlying defect and likely fix, distinguishing between pair-level noise and root-level issues.

3. Key Contributions

Chiral Analysis Model: A relational vulnerability framework that treats corresponding business paths as implicit specifications, moving beyond single-function analysis.
Formalization: Definition of chiral relations as static metamorphic analogues and the derivation of seven specific obligation dimensions.
ChiralDetector Implementation: A prototype pipeline integrating static analysis, static pair ranking, LLM-based semantic detection, strict falsification validation, and root-cause deduplication.
Empirical Evidence: A preliminary evaluation on the Phi protocol demonstrating the detection of business-logic inconsistencies that are difficult to express as single-function rules.

4. Evaluation Results

The authors evaluated ChiralDetector on the Phi protocol, a Solidity project containing diverse relation shapes (claim/batch, adapter/factory, quote/execution).

Funnel Metrics:
- Started with 3,217 statically ranked candidate pairs.
- Reduced to 1,643 pairs for semantic detection.
- Produced 201 cleaned finding/suspicious candidates.
- Collapsed to 101 local deduplicated groups.
- 44 groups survived strict validation.
- Final manual root-cause deduplication yielded 13 effective unique issues.
Representative Findings:
- M10: Cross-art Merkle proof reuse (Similar flow/guard violation).
- M13: Fee unit mismatch (basis points vs. wei) (Value/unit violation).
- M12: Public tracking helpers corrupting curator state (State/access violation).
- M05/M02/M04: Refund propagation gaps and guard asymmetries between single and batch paths (Wrapper/core and single/batch value-flow violations).
Cost Analysis:
- The full run cost approximately 212.70 CNY (excluding human time).
- The dominant cost was LLM inference (semantic filtering, detection, and validation), not static analysis.
- The strict validator significantly reduced noise, rejecting 57 of the 101 locally deduplicated groups.

5. Significance and Claims

The paper claims that chiral analysis exposes a class of bugs—relational inconsistencies—that are naturally difficult to express as single-function rules but are critical for protocol security.

Insight: Many business-logic bugs exist because two related paths disagree on how they handle a shared business object (e.g., a refund recipient or a fee calculation), rather than because a single function is locally unsafe.
Structured LLM Usage: The paper argues that using LLMs within a structured pipeline (static reduction $\to$ semantic filtering $\to$ strict validation) is more effective and cost-efficient than "direct agent auditing" (unrestricted reading of code). The pipeline externalizes intermediate decisions (pairs, relations, obligations), making the analysis inspectable and debuggable.
Modesty: The authors explicitly state that the current evaluation is a preliminary case study on a single protocol. They do not claim to have established general recall or precision metrics yet. They acknowledge limitations, including the approximation of Solidity semantics in path extraction, the potential for LLM hallucinations, and the lack of automated witness generation (executable proof-of-concept transactions).

The work positions itself as a step toward making business-logic reasoning explicit and repeatable in smart contract auditing, offering a vocabulary for describing why specific inconsistencies matter.