Desyan: Unified Value-Flow and Symbolic Analysis

• Desyan is a program-analysis platform that unifies value-flow and symbolic analysis within a Datalog fixpoint engine, integrating both SMT and native symbolic reasoning.
• It leverages Soufflé’s optimized evaluation by embedding symbolic operations as functors, enabling seamless mixing of heavyweight and lightweight analyses.
• The platform supports advanced use cases including points-to analysis, symbolic execution, and smart contract analysis, balancing precision with scalability.

Searching arXiv for the specified paper and closely related context. arxiv_search(query="(Diamantakis et al., 1 Aug 2025) Desyan", max_results=5) arxiv_search: query: "(Diamantakis et al., 1 Aug 2025) Desyan" max_results: 5 Desyan is a program-analysis platform that unifies two lines of work that have historically evolved mostly separately: value-flow analysis and symbolic analysis. It is presented as an extension of a Datalog fixpoint engine, specifically Soufflé, rather than a new language with different semantics. The stated aim is to preserve Soufflé’s industrial-strength Datalog performance and semantics while making symbolic reasoning available inside ordinary declarative rules, supporting both heavyweight SMT solving and lightweight native symbolic reasoning, and providing conveniences for common program-analysis idioms such as path conditions, bound variables, equality bindings, and model extraction (Diamantakis et al., 1 Aug 2025).

1. Separation of value-flow and symbolic analysis

The motivating problem is the historical separation between two dominant static-analysis paradigms. Value-flow analyses—such as points-to, taint, and data-flow analysis—have become strongly associated with declarative Datalog implementations, because Datalog expresses recursive propagation compactly and engines such as Soufflé compile these specifications into highly optimized fixpoint evaluators. Symbolic techniques—especially symbolic execution—have instead centered on constraint solving and SMT solvers, with different implementation styles and execution models (Diamantakis et al., 1 Aug 2025).

Desyan’s core claim is that this separation is artificial and costly. Many modern analyses require both high-performance relational or value-flow reasoning and symbolic reasoning over expressions and path conditions, yet there has been no widely adopted platform that combines them naturally and efficiently. Desyan is proposed to fill that gap by making value-flow facts, symbolic expressions, and solver outcomes first-class inputs to the same fixpoint. In this sense, “seamless integration” denotes more than library interoperability: it means no separate orchestration layer, no translation of the whole analysis into a solver-aided language, and no loss of Soufflé’s semi-naive bottom-up evaluation model (Diamantakis et al., 1 Aug 2025).

A plausible implication is that the platform is intended not merely as a convenience layer over existing solvers, but as a unifying execution substrate for analyses whose precision and scalability depend on mixing recursive relational inference with symbolic filtering or enrichment.

2. Execution model and architectural design

The execution model remains Datalog fixpoint evaluation. Relations are computed bottom-up, often in parallel, and recursive dependencies determine when rules can fire. Symbolic reasoning enters as localized operations inside this fixpoint. Ordinary Soufflé analyses run unchanged, because Desyan adds symbolic capabilities via Soufflé’s standard functor mechanism and via a reusable Datalog component (Diamantakis et al., 1 Aug 2025).

The symbolic execution case study makes this interaction concrete. It defines three mutually recursive relations: Reachable(s,p,b) for blocks reachable in symbolic state $s$ under path condition $p$, Lookup(s,v,e) for the symbolic value $e$ of variable $v$ in state $s$, and BlockSetsVar(s,b,v,e) for the transfer effect of block $b$ on variable $v$. States are represented declaratively as identifiers—lists of blocks—rather than as eagerly materialized stores. Variable bindings are populated lazily by recursive Lookup rules. Symbolic execution is therefore expressed not as imperative step-by-step execution but as a graph of recursive deductions (Diamantakis et al., 1 Aug 2025).

At branch points, the analysis forms a condition and asks whether the conjunction of the current path condition with the branch guard is satisfiable. The paper gives the true-branch rule as

$\pred{Reachable}{[block, stateBefore], [condExpr, pathCond], nextBlock} \leftarrow \pred{Reachable}{stateBefore, pathCond, jmpBlock},\; \pred{TrueEdge}{jmpBlock, nextBlock, condVar},\; \pred{Lookup}{[block, stateBefore], condVar, condExpr},\; \smtResponse(\mathrm{flatten}("AND",[condExpr,pathCond])) = ['sat'],\; |pathCond| < BOUND.$

The false branch is analogous, adding $\mathrm{NOT}(condExpr)$ to the path condition. This illustrates the paper’s central interaction pattern: value-flow recursion computes states and expressions; symbolic reasoning filters or enriches these derivations; the resulting facts feed back into the fixpoint (Diamantakis et al., 1 Aug 2025).

3. Symbolic backends and user-visible constructs

Desyan has two symbolic reasoning backends. The first is a full SMT backend that uses external SMT solvers—Z3 by default in the implementation—through Datalog functors. The main functor is @smtResponse, which takes a query in SMTLIB form and returns a Datalog tuple containing the satisfiability result and, for satisfiable queries, a model. A second functor, @printToSmt, translates Desyan’s internal tree representation of expressions into SMTLIB and performs query rewrites. This backend supports all Z3-supported logics; the experiments mainly use bitvector logics such as BV and QF_BV (Diamantakis et al., 1 Aug 2025).

The second backend is a Datalog-native symbolic or algebraic reasoner: a bottom-up symbolic simplifier and limited solver implemented entirely in Datalog. It is intended for simple, bounded-size expressions and offers more predictable performance than invoking an SMT solver on every query. The paper’s guidance is explicit: full SMT is necessary for arbitrarily complex conditions, especially whole-path constraints in symbolic execution or concolic evaluation, whereas native Datalog symbolic reasoning is preferable for lightweight reasoning such as simplifying small expressions, folding constants, checking simple branch conditions independently, or supporting path-sensitive analyses with limited symbolic complexity (Diamantakis et al., 1 Aug 2025).

The user-visible representation of expressions is native to Datalog records:

$v$1

Primitive expressions are constants or symbolic variables; compound expressions are binary trees. The platform also uses tuple or list construction syntax such as [x, y], fresh symbolic values via fresh(), list flattening into conjunctions via helper syntax such as flatten("AND", list), list-length guards like |pathCond| < BOUND, don’t-care _, and negation !. Facts such as Assign, PHI, BinOperation, TrueEdge, and FalseEdge encode the program’s IR. Symbolic values and path conditions are therefore ordinary relational data, while solver interactions appear as ordinary rule-body atoms through functors (Diamantakis et al., 1 Aug 2025).

Backend	Mechanism	Intended use
Full SMT	External SMT solvers via @smtResponse and @printToSmt	Arbitrarily complex conditions, full symbolic execution, concolic evaluation
Datalog-native symbolic reasoning	Bottom-up symbolic simplifier and limited solver in Datalog	Small expressions, constant folding, simple branch checks, lightweight path sensitivity

A practical feature is that one analysis can combine both backends and tune where to switch, for example by using a symbolic-expression-size threshold in the symvalic case study. This suggests that Desyan is designed around backend heterogeneity rather than around a single symbolic semantics (Diamantakis et al., 1 Aug 2025).

4. Query transformations, pseudo-quantification, and bounded algebraic solving

Desyan adds several domain-specific conveniences on top of raw SMT calls. One is query caching: because Datalog functors must behave as pure functions, repeated identical queries return the same cached result, which also improves speed. Another is automatic let-bindings. When a symbolic executor generates equalities such as

$$x_1 = fresh \land x_2 = x_1 + 42 \land x_1 + x_2 = 16,$$

Desyan can rewrite this into nested SMT let terms,

$p$0

thereby shrinking the solver’s search space by turning intermediate equalities into bindings (Diamantakis et al., 1 Aug 2025).

A third convenience is support for custom operators, including the pseudo-quantifier $p$1. This addresses analyses with bound variables: values that are unknown but should not be treated as solver-controllable free inputs. The motivating example is a security check on a program variable userid; a vulnerability query should not be satisfied merely by allowing the solver to set userid = ADMIN. Rather than relying on full universal quantification, which SMT solvers often handle poorly, $p$2 binds designated variables to randomly chosen “magic constants” from a predefined pool of unusual 256-bit values. Its semantics are intentionally asymmetric: if the resulting query is unsatisfiable, then the truly universally quantified version would also be unsatisfiable; if it is satisfiable, the result is heuristic rather than a proof for all values. The paper reports a contrast example in which a quantified SMTLIB query took about 3 seconds with forall, while the $p$3-style encoding took about 0.03 seconds (Diamantakis et al., 1 Aug 2025).

The Datalog-native solver is formalized as a bounded bottom-up algebraic rewriting system. Starting from an initial set of constants, symbolic expressions, and a partition of variables into free and bound, it constructs a finite universe of expressions by closure under four principles: inclusion of subexpressions; inclusion of algebraic simplifications that produce smaller expressions; inclusion of complements and equalities over constants; and constant folding that creates new constants only for already-in-universe expressions. Because this universe is bounded, the native solver is guaranteed to terminate (Diamantakis et al., 1 Aug 2025).

The rewriting engine itself is expressed with Datalog rules. For associativity, the paper gives

$p$4

BaseEquals is then transitively closed into the final equivalence relation. The solver also contains classifications of operators—associative, commutative, distributive, idempotent, canceling, mutually exclusive, inverse pairs, identities, zeros—and specialized rules for linear equalities and inequalities (Diamantakis et al., 1 Aug 2025).

For linear constraints, the paper defines solution operators such as

$p$5

It then gives the core rule

$p$6

This is explicitly not a general SMT solver; it is a bottom-up normalizer and limited equation solver (Diamantakis et al., 1 Aug 2025).

5. Semantics, recursion, and analysis case studies

A notable semantic issue arises from the interaction between the native solver and recursive analyses. Because the native solver performs normalization to the smallest equivalent expression, its behavior is non-monotonic. Datalog therefore cannot allow unrestricted recursion from solver outputs back into solver inputs. Desyan addresses this by packaging the native solver as a Soufflé component that can be instantiated a bounded number of times, giving the user a staged way to apply lightweight symbolic reasoning repeatedly without violating stratification constraints (Diamantakis et al., 1 Aug 2025).

The main programming model is elaborated through the symbolic execution case study over SSA basic blocks. The analysis domain includes sets of basic blocks $p$7, expressions $p$8, path conditions $p$9, states $e$0, variables $e$1, functions $e$2, and operators $e$3. The computed relations are Lookup(s,v,e), BlockSetsVar(s,b,v,e), and Reachable(s,p,b). The rules for BlockSetsVar encode instruction transfer semantics for constants, SSA $e$4 merges, and binary operations. The rules for Lookup initialize formal parameters with fresh symbols, install block-local assignments into successor states, and otherwise inherit previous bindings. The rules for Reachable initialize entry blocks and propagate across true and false edges using satisfiability checks. The paper characterizes this as an executable declarative small-step semantics over SSA basic blocks, evaluated bottom-up, with evaluation order determined by recursive data dependencies rather than source execution order (Diamantakis et al., 1 Aug 2025).

Three use cases structure the evaluation. The first is an Andersen-style points-to analysis with on-the-fly call-graph construction, using familiar Datalog rules to derive VarPointsTo, FldPointsTo, Reachable, CallGraph, and InterProcAssign. The second is symbolic value-flow analysis, or symvalic, a lightweight path-sensitive analysis for Ethereum smart contracts that reasons about individual branch conditions separately rather than maintaining full path predicates. The third is a full symbolic execution engine for the Gigahorse three-address-code IR for EVM smart contracts, covering many instruction kinds and memory features in about 60 Desyan rules and approximately 500 lines (Diamantakis et al., 1 Aug 2025).

The symvalic case study is used to expose a precision–performance tradeoff. Because it reasons about each condition separately and groups value bindings into small dependency-based sets, it can miss correlations. The paper’s deposit example shows that if actualFees = min(fees, allowed[recipient]), then the conditions actualFees > 200 and fees < 100 cannot both hold, but the lightweight dependency abstraction may fail to preserve that correlation and can therefore produce a false feasible path. This tradeoff buys scalability and completeness across many statements, and it is precisely the kind of workload for which the native Datalog solver is intended (Diamantakis et al., 1 Aug 2025).

6. Empirical results, strengths, and limitations

The evaluation compares Desyan to prior alternatives and compares its symbolic backends. For value-flow performance, the authors implement a compact points-to analysis in Desyan or Soufflé and in Formulog, on a machine with two Intel Xeon Gold 6136 CPUs and 640GB RAM, over the DaCapo benchmarks, under interpreted or compiled and single- or multi-threaded configurations. The key result is average speedups from $e$5 to $e$6 over Formulog depending on configuration. The paper stresses that this is not a new algorithmic contribution of Desyan per se; rather, it supports the claim that Desyan combines mature Datalog performance with symbolic reasoning (Diamantakis et al., 1 Aug 2025).

For lightweight symbolic reasoning, the symvalic analysis is evaluated on 189 substantial Ethereum contracts from the Gigahorse benchmark set. The native solver analyzes all contracts with 0 failures and an average analysis time of 129.6 s, while the full SMT solver has 7 failures or timeouts and 218.1 s average time. The native solver is therefore about $e$7 faster on this workload, consistent with the paper’s summary claim of about $e$8 speedup over a large input collection. The average contract issued about 1,115 solver queries, with a maximum of 13,487. The paper also gives an example query involving bitvector division that takes about 5 s in Z3, illustrating why bounded symbolic reasoning can outperform eager SMT invocation on such workloads (Diamantakis et al., 1 Aug 2025).

For symbolic execution, the paper does not present a direct baseline comparison, but it argues feasibility and necessity. Generated path conditions can easily exceed 100 syntax-tree nodes and involve rich 256-bit arithmetic, which lies beyond the intended scope of the native Datalog solver and requires the full SMT backend (Diamantakis et al., 1 Aug 2025).

The reported improvements are attributed to three design choices: inheritance of Soufflé’s optimized semi-naive fixpoint evaluation, compilation, locality-friendly joins, and parallel execution for value-flow-heavy parts; avoidance of overusing SMT by providing a native algebraic solver for bounded symbolic tasks; and reduction of SMT overhead through query caching, automatic let-bindings, and custom encodings such as $e$9 (Diamantakis et al., 1 Aug 2025).

The platform’s strengths are explicit. It provides one platform for joint value-flow and symbolic reasoning, preserves existing Soufflé analyses unchanged, supports mix-and-match reasoning backends, offers practical analysis-oriented query transformations, and demonstrates a declarative programming model for analyses that are often implemented imperatively. Its limitations are equally explicit. The native Datalog solver is not a replacement for SMT: it only handles bounded-size expressions and limited classes of algebraic rewrites and linear solutions. Because of normalization and stratification, it cannot participate in unrestricted recursive feedback loops and must be staged via component instantiation. The $v$0 quantifier is heuristic rather than a sound substitute for full universal quantification in the satisfiable case. Whenever analyses must solve large path predicates or complex bitvector arithmetic exactly, external SMT remains necessary (Diamantakis et al., 1 Aug 2025).

Taken together, these results support the paper’s broader thesis that value-flow reasoning and symbolic reasoning should not live in separate worlds. Desyan’s significance lies in showing that a production Datalog engine can be extended so that recursive relational analysis, symbolic evaluation, path-sensitive reasoning, and SMT-backed solving coexist in one declarative fixpoint framework.