Pith. sign in

REVIEW 4 major objections 4 minor 44 references

DTVM: Revolutionizing Smart Contract Execution with Determinism and Compatibility

T0 review · 4 major / 4 minor · reviewed 2026-08-16 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read DTVM claims 2x-faster EVM contracts on a deterministic Wasm VM

desk verdict A serious systems paper whose headline EVM speedup is likely overstated by compiler-level optimizations; worth refereeing, but performance and determinism claims need isolation tests. read the letter →

arxiv 2504.16552 v2 pith:QLJCVZ54 submitted 2025-04-23 cs.DC

Wei Zhou , Xiong Xu , Changzheng Wei , Ying Yan , Wei Tang , Zhihao Chen , Xuebing Huang , Wengang Chen
show 17 more authors
Jie Zhang Yang Chen Xiaofu Zheng Hanghang Wu Shenglong Chen Ermei Wang Xiangfei Chen Yang Yu Meng Wu Tao Zhu Liwei Yuan Feng Yu Alex Zhang Wei Wang Ji Luo Zhengyu He Wenbiao Zhao
This is my paper · ORCID
classification cs.DC
keywords smartcontractvirtualmachineWebAssemblydeterministicexecutionjust-in-timecompilationEVMABIcompatibilitylazygasmeteringtrampolinehot-switch
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper introduces DTVM, a smart-contract execution stack that runs Ethereum-style contracts on a WebAssembly core while keeping the Ethereum ABI. Its central claim is that a deterministic middle intermediate representation (dMIR), plus a function-level lazy just-in-time compiler with a trampoline hot-switch, makes execution both deterministic across CPU architectures and faster than the standard EVM interpreter on dominant token contracts. The paper reports up to 2× acceleration over evmone on ERC-20/721/1155 workloads, 3.61× on Fibonacci, and sub-millisecond first invocation latency versus mainstream Wasm runtimes. If these measurements hold, blockchain nodes could adopt a JIT execution path without sacrificing cross-node consensus determinism or breaking the existing Solidity toolchain.

What carries the argument

The central object is the dMIR (Deterministic Middle Intermediate Representation), a blockchain-specific IR that only admits modules conforming to the dWasm deterministic extension and carries five determinism enforcement mechanisms: deterministic halt, numerical computation determinism, deterministic error handling, deterministic format validation, and stack determinism. Its companions are the Zeta Engine's function-level lazy JIT with a trampoline hot-switch (stubs redirect first calls to a resolver that compiles on demand and atomically patches the call target), an 8GB virtual-memory guard-page layout that turns out-of-bounds access into hardware faults, and hook-function-based checked arithmetic that uses CPU status flags.

What would settle it

Compile the same Solidity contract with solc's EVM output for evmone and with solc's Yul output to Wasm using a third-party Yul-to-Wasm tool, then run the identical Wasm on DTVM and on Wasmtime; if DTVM is not faster than Wasmtime on that identical Wasm, the reported speedup over evmone is a compiler effect, not a VM effect.

Watch

Extended reading notes

Core claim

The load-bearing discovery is that determinism and JIT speed need not trade off: DTVM defines a restricted deterministic Wasm variant (dWasm) and enforces it at a middle IR (dMIR) layer before code generation, eliminating static, runtime, and trap-level nondeterminism while still compiling hot functions to native code. The paper argues that by reserving an 8GB guard-page address space and using hardware page faults instead of explicit bounds checks, and by using CPU overflow flags for checked arithmetic, the VM removes per-instruction software checks that dominate interpreted EVM cost. Combined with a stub/trampoline mechanism that compiles functions lazily in the background and atomically patches call sites, this yields measured speedups of 1.06–3.61× over the evmone interpreter on Ethereum workloads and 11.8–40.5% lower processing time than mainstream Wasm runtimes on Fibonacci while producing identical stack-overflow behavior on x86 and ARM.

Load-bearing premise

The comparisons to evmone assume that converting EVM bytecode to Wasm through DTVM's own Solidity-to-Wasm generator does not change the cost structure of the computation, so the measured latency gap reflects VM execution efficiency rather than compiler-level optimizations like 256-bit to 64-bit type narrowing.

Editorial extensions

If this is right

  • EVM-based chains can adopt a JIT execution path while keeping consensus determinism across heterogeneous hardware.
  • Contract developers can write in C++, Rust, Java, Go, or AssemblyScript and still call or be called by EVM ABI contracts, potentially broadening the Solidity-centric ecosystem.
  • The small codebase (69.5 KLoC versus 143.6 KLoC for Wasmtime) and 31.8MB CLI shrink the trusted computing base for TEE deployments.
  • The sub-millisecond invocation latency reduces the DDoS window opened by slow compilation on a contract's first call.
  • The architecture extends to EVM and RISC-V bytecode via frontend adaptation layers, pointing toward ZK-VM integration.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The 1.06–3.61× speedups combine VM-engine gains with Solidity-to-Yul-to-Wasm type narrowing; a fair VM-level comparison would run identical Wasm produced from the same frontend against both DTVM and a baseline Wasm VM.
  • If dWasm's restrictions (fixed stack depth, no host nondeterminism, deterministic traps) become consensus-critical, the paper's model suggests these restrictions could be standardized across all Wasm-based blockchains.
  • The hardware guard-page memory scheme is portable to other sandboxed runtimes, but its correctness on architectures without 8GB address space or with different page-fault semantics needs per-architecture validation.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 4 minor

Summary. The paper introduces the DTVM Stack, a smart-contract execution framework that compiles EVM/Solidity and other languages to WebAssembly, executes via a lazy function-level JIT engine (Zeta Engine) over a proposed deterministic intermediate representation (dMIR/dWasm), and claims deterministic execution across CPU architectures, EVM ABI compatibility, large speedups over evmone and Wasm VMs, and integrated AI tooling (SmartCogent). The main performance claims are a 1.06x-3.61x latency reduction over evmone on Ethereum workloads, 11.8%-40.5% processing time reduction for Fibonacci relative to Wasm VMs, sub-millisecond first invocation via a trampoline hot-switch mechanism, and reduced code size and TCB. The paper reports detailed benchmarks on ERC20/721/1155, Counter, Fibonacci, Integer Overflow, PolyBench, and WAPM, and it openly reports 10/30 PolyBench cases where DTVM is slower than Wasmtime.

Significance. If the load-bearing claims were established, DTVM would be a valuable contribution to blockchain VM engineering, as a deterministic, EVM-compatible Wasm JIT with sub-millisecond startup is directly relevant to layer-1 and layer-2 execution. The paper deserves credit for open-sourcing the implementation, for honestly reporting the 10/30 PolyBench cases where Wasmtime is faster, and for describing an original trampoline hot-switch mechanism. However, the two central evidence pillars—the evmone speedup and the determinism guarantee—are currently not validated in a way that supports the paper's headline claims. The evmone comparison is confounded with compiler-level transformations, and the determinism evidence consists of a single stack-overflow scenario under an author-defined specification. Because these issues affect the main conclusions, the paper needs substantial rework before the claims can be accepted.

major comments (4)
  1. [Section 5.2.1 / Fig. 5 together with Section 4.7.1] The claimed 1.06x-3.61x speedup over evmone is confounded with the Solidity-to-Wasm compilation pipeline. The testbed states 'we use DTVM's built-in Solidity-to-Wasm generator to convert the EVM bytecode into Wasm bytecode for execution on DTVM,' while Section 4.7.1 documents that this pipeline performs 256-bit to i32/i64 type refinement, memory-access redundancy elimination, function inlining, constant folding, and dead code elimination. Each of these transformations can reduce the number of executed instructions, so the latency difference relative to evmone reflects a combined compiler-plus-VM effect, not the execution engine alone. To support the claim of VM-level acceleration, the authors should provide an isolation experiment: run the same generated Wasm on DTVM and on a well-optimized Wasm VM (e.g., Wasmtime) with identical compilation settings, or otherwise control for the compiler transformations, and separately report the compiler contribution.
  2. [Section 5.1 / Table 5 and Section 4.6] The determinism evidence is limited to one self-constructed scenario: an infinite recursive call that triggers stack overflow. The dWasm specification is defined by the authors (T/TBI57-2024), and the fixed resource limits (e.g., maximum call depth 1024) make the observed matching behavior across Intel and ARM essentially true by construction. This tests enforcement of a resource limit, not semantic determinism of computation, traps, floating-point handling, host functions, memory.grow, or NaN canonicalization. For the determinism claim to be load-bearing, the authors should present differential testing across the DTVM interpreter and JIT over many programs, targeted tests for IEEE-754 edge cases and traps, and an independent or formal conformance check of the dWasm rules.
  3. [Section 4.7.1 and Section 4.5] The paper does not demonstrate that the Solidity-to-Yul-to-Wasm conversion preserves EVM semantics, which underlies both the evmone comparison and the claimed full EVM ABI compatibility. The 256-bit to 64-bit type refinement in Section 4.7.1 is unsafe for arbitrary uint256 arithmetic unless overflow and wraparound behavior are preserved, and Section 4.5's hook-function mechanism covers only specified operations. No equivalence proof, conformance suite, or differential test against an EVM reference implementation is provided. The manuscript should clarify which Solidity/EVM constructs are in scope, add a semantic-preservation argument or test, and state any restrictions.
  4. [Sections 4.4 and 5] The evaluation does not state whether gas metering was enabled in the reported latency measurements, for either evmone or DTVM. Section 4.4 describes gas checks inserted at basic-block entries in FLAT/FLAS modes, and these checks add runtime cost; if evmone ran without gas metering or DTVM ran with it, the comparisons in Fig. 5 and Fig. 7 are not apples-to-apples. The paper should explicitly report the gas-metering configuration of each VM and, if relevant, provide separate measurements with and without gas accounting.
minor comments (4)
  1. [Section 5.2.1] The text says 'comparing the performance of DTVM with e and Revmc'; 'e' should read 'evmone'.
  2. [Table 6] The entry for Wasmer (LLVM) obj/Code sizes is formatted without separators, e.g., '65.634.766.0', making the values difficult to parse.
  3. [Section 3.1 / Abstract] The dWasm standard T/TBI57-2024 is cited as approved in 2024, but the manuscript gives no accessible reference or specification URL; this should be added so readers can check conformance.
  4. [Throughout] Several typos and spacing issues appear: 'Remvc' instead of 'Revmc' in Section 5.2.1, 'cores at depth' in Table 5 note, and the running header 'REVOLUTIONIZINGSMARTCONTRACTEXECUTION' missing spaces.

Circularity Check

1 steps flagged · score 3.0 of 10

Determinism guarantee is self-referential; performance claims remain externally benchmarked.

  1. self definitional [Section 4.6 (Constraints and Implementation for Deterministic Execution) and Section 5.1 / Table 5 (Determinism Guarantee)]
    "Depth Limits: Maximum call depth (e.g., 1,024 layers) and stack overflow checks are enforced before each function call. Exceeding limits triggers a deterministic trap." ... "DTVM maintains consistent stack overflow behaviors across both architectures."

    The deterministic stack-overflow behavior presented as validation in Section 5.1 is the direct, specified output of the dWasm constraints defined in Section 4.6: a fixed virtual stack and a hard depth limit that 'triggers a deterministic trap.' The same section states that non-compliant modules are rejected before dMIR generation, so the x86/ARM consistency in Table 5 is guaranteed by that self-written rule. This is not a prediction from an independent model; it is a conformance check of an implementation against the authors' own definition of determinism. The guarantee is therefore true by construction rather than empirically established.

full rationale

The headline performance claims are based on external measurements against evmone, Wasmtime, Wasmer, PolyBench, and WAPM with concrete reported numbers; they are not derived from fitted parameters or from the paper's own definitions, so they are not circular. The evmone comparison does have an input asymmetry: DTVM executes Wasm produced by its own generator described in Section 4.7.1 (256-bit to i32/i64 refinement, inlining, constant folding, dead code elimination) while evmone executes solc-generated EVM bytecode, so the reported speedup may include compiler-level transformation gains rather than pure VM execution gains; however, this is a benchmark-validity and attribution threat, not a circular derivation. The one genuinely self-referential component is the determinism validation, which reduces to DTVM's own dWasm specification: the fixed stack and trap rules make consistent behavior tautological. That self-referential element does not contaminate the external performance data, so the overall circularity is partial rather than total.

Assumptions & free parameters 2 free parameters · 4 assumptions · 1 invented entities

The central performance claims rest on external benchmarks, so no fitted constants dominate. However, the determinism guarantee is grounded in the authors' own dWasm/dMIR spec, and the AI results rely on an undisclosed dataset. The hand-chosen dWasm resource limits appear arbitrary.

free parameters (2)
  • dWasm resource limits (max params 1024, locals 10240, frame size 40960, instructions 10240, nesting depth 1024, 8MB…
    Hand-chosen limits define the deterministic execution model; the paper provides no independent justification or evidence that these values are optimal or necessary.
  • Virtual stack depth (max call depth 1024) = 1024
    Chosen to ensure deterministic stack overflow behavior across architectures; arbitrary and uncalibrated.
assumptions (4)
  • ad hoc to paper The dWasm specification (T/TBI57-2024) as defined by the authors correctly identifies and eliminates all sources of nondeterminism in WebAssembly execution across heterogeneous CPU architectures.
    Section 4.6 defines determinism constraints and then uses them to claim deterministic execution; no independent standard body or third-party implementation is cited.
  • domain assumption The SIGSEGV-based hardware memory protection reliably converts every out-of-bounds linear memory access into a deterministic Wasm trap with identical semantics on all supported platforms.
    Section 4.3 relies on OS signal handling and page protection behavior; cross-OS and cross-architecture consistency is not demonstrated beyond the architecture comparison in Table 5.
  • domain assumption The Solidity-to-Yul-to-Wasm compiler pipeline produces Wasm modules semantically equivalent to the EVM bytecode for the tested contracts, so performance differences can be attributed to the VM.
    Section 5 testbed converts EVM bytecode to Wasm via DTVM's built-in generator; no formal equivalence proof or conformance test is provided.
  • domain assumption The AI evaluation dataset and repair tasks are representative of real-world smart contract vulnerabilities and fixes, and the baseline tools were evaluated under comparable conditions.
    Section 4.9 and Tables 1-2 report accuracy without dataset description, sample size, or protocol; baseline Qwen-Max is used without specialized workflow.
invented entities (1)
  • dMIR and dWasm specification (standard T/TBI57-2024)
    purpose: Enforce deterministic execution semantics across Wasm modules and CPU architectures.
    The specification is authored by the paper's own team, no external standard or implementation is provided; the paper claims approval in 2024 without citing a standards body.

how reviews work

0 comments
Cite this review

Pith. "Pith review of DTVM: Revolutionizing Smart Contract Execution with Determinism and Compatibility." pith.science (2026). https://pith.science/paper/QLJCVZ54

@misc{pith2026250416552,
  author       = {Pith},
  title        = {Pith review of: DTVM: Revolutionizing Smart Contract Execution with Determinism and Compatibility},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/QLJCVZ54}},
  note         = {Machine review of arXiv:2504.16552}
}
abstract

We introduce the DeTerministic Virtual Machine (DTVM) Stack, a next-generation smart contract execution framework designed to address critical performance, determinism, and ecosystem compatibility challenges in blockchain networks. Building upon WebAssembly (Wasm) while maintaining full Ethereum Virtual Machine (EVM) ABI compatibility, DTVM introduces a Deterministic Middle Intermediate Representation (dMIR) and a hybrid lazy-JIT compilation engine to balance compilation speed and execution efficiency. DTVM further accommodates diverse instruction set architectures (e.g., EVM, RISC-V) through modular adaptation layers. This enables seamless integration with DTVM's hybrid lazy-JIT compilation engine, which dynamically optimizes performance while preserving deterministic execution guarantees across heterogeneous environments. The key contributions including: 1). The framework achieves up to 2$\times$ acceleration over evmone in dominant Ethereum contract (e.g. ERC20/721/1155) execution and reduces fibonacci computation latency by 11.8$\sim$40.5% compared to Wasm based VMs. 2). A novel trampoline hot-switch mechanism enables sub-millisecond (0.95ms) post-deployment invocation times, outperforming up to about 23$\times$ in compilation and invocation efficiency. 3). It supports multi-language development (Solidity, C++, Rust, Java, Go, and AssemblyScript) through unified bytecode conversion while maintaining EVM ABI compatibility for seamless invocation. It reduces machine code object sizes by 30.0$\sim$72.6%, coupled with a minimized Trusted Computing Base. 4). It offers SmartCogent, an AI-driven full-stack development experience, leveraging fine-tuned LLMs and retrieval-augmented generation to automate tasks across the smart contract lifecycle: development, debugging, security auditing, and deployment. DTVM Stack has been open-sourced (https://github.com/DTVMStack).

Figures

Figures reproduced from arXiv: 2504.16552 by the authors.

Figure 1
Figure 1. DTVM Stack Overview The DTVM Stack’s technical architecture is composed of three primary components: the DTVM Engine, DTVM SDK, and DTVM Tools. Logically, it is organized into four layers: the core layer, execution layer, adaptation layer, and toolchain layer. The core and execution layers are encapsulated within the DTVM Engine. 3.1 DTVM Engine The DTVM Engine introduces a Lazy-JIT compilation architecture and runt… view at source ↗
Figure 2
Figure 2. SmartCogent for smart contract development, auditting and deployment [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗
Figure 3
Figure 3. DTVM Lazy-JIT Framework DTVM employs a multi-pass JIT compilation architecture with lazy compilation support to balance the immediate usability of deployed smart contracts with high-performance execution requirements. Its core compilation pipeline, illustrated in [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: Layout of virtual memeory Virtual Memory Layout Strategy: The core of DTVM’s memory protection relies on a carefully designed virtual memory mapping structure: 1 void * base = mmap ( 2 0, 3 8 * 1024 * 1024 * 1024 , // 8 GB 4 PROT_NONE , // Initially inaccessible 5 MAP_…
Figure 5
Figure 5. Figure 5: Comparison in the Ethereum Ecosystem 5.2 Performance Evaluation 5.2.1 Comparison in the Ethereum ecosystem We utilize cases from Workload A and Workload B to measure execution latency, comparing the performance of DTVM with e and Revmc to realize a comparison within th…
Figure 6
Figure 6. Figure 6: DTVM (JIT) improvement over DTVM (Interp) [PITH_FULL_IMAGE:figures/full_fig_p025_6.png]
Figure 7
Figure 7. Figure 7: Comparison with general-purpose Wasm Vms [PITH_FULL_IMAGE:figures/full_fig_p025_7.png]
Figure 8
Figure 8. Figure 8: Results of PolyBench benchmark [PITH_FULL_IMAGE:figures/full_fig_p026_8.png]
Figure 9
Figure 9. Figure 9: Comparsion of latency to first invocation [PITH_FULL_IMAGE:figures/full_fig_p027_9.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

44 extracted references · 39 canonical work pages

  1. [1]

    Ethereum: A secure decentralised generalised transaction ledger.Ethereum project yellow paper, 151(2014):1–32, 2014

    Gavin Wood et al. Ethereum: A secure decentralised generalised transaction ledger.Ethereum project yellow paper, 151(2014):1–32, 2014

    2014

  2. [2]

    The Sui Smart Contracts Platform.https://docs.sui.io/paper/sui.pdf, 2022

    work page 2022

  3. [3]

    https://aptosfoundation

    The Aptos Blockchain: Safe, Scalable, and Upgradeable Web3 Infrastructure. https://aptosfoundation. org/whitepaper/aptos-whitepaper_en.pdf, 2022

    work page 2022

  4. [4]

    An introduction to solana.no

    Grayscale Building Blocks. An introduction to solana.no. December, 2021

    work page 2021

  5. [5]

    Letus: A log-structured efficient trusted universal blockchain storage

    Shikun Tian, Zhonghao Lu, Haizhen Zhuo, Xiaojing Tang, Peiyi Hong, Shenglong Chen, Dayi Yang, Ying Yan, Zhiyong Jiang, Hui Zhang, et al. Letus: A log-structured efficient trusted universal blockchain storage. In Companion of the 2024 International Conference on Management of Data, pages 161–174, 2024

    work page 2024

  6. [6]

    Pharos Network.https://pharosnetwork.xyz/, 2024

    work page 2024

  7. [7]

    Monad Pad.https://www.monadpad.xyz/files/whitepaper.pdf, 2024

    work page 2024

  8. [8]

    MegaETH Testnet Documentationm.https://docs.megaeth.com/, 2024

    work page 2024

Show all 44 references
  1. [9]

    risc0.https://github.com/risc0/risc0, 2022

    2022

  2. [10]

    sp1.https://docs.succinct.xyz/docs/sp1/introduction, 2022

    2022

  3. [11]

    valida.https://github.com/valida-xyz/valida, 2022

    2022

  4. [12]

    Jolt: Snarks for virtual machines via lookups

    Arasu Arun, Srinath Setty, and Justin Thaler. Jolt: Snarks for virtual machines via lookups. InAnnual International Conference on the Theory and Applications of Cryptographic Techniques, pages 3–33. Springer, 2024

    2024

  5. [13]

    https://ethereum-magicians.org/ t/long-term-l1-execution-layer-proposal-replace-the-evm-with-risc-v/23617, 2025

    Long-term L1 execution layer proposal: replace the EVM with RISC-V. https://ethereum-magicians.org/ t/long-term-l1-execution-layer-proposal-replace-the-evm-with-risc-v/23617, 2025

    2025

  6. [14]

    Intel sgx explained.Cryptology ePrint Archive, 2016

    Victor Costan and Srinivas Devadas. Intel sgx explained.Cryptology ePrint Archive, 2016

    2016

  7. [15]

    Confidentiality support over financial grade consortium blockchain

    Ying Yan, Changzheng Wei, Xuepeng Guo, Xuming Lu, Xiaofu Zheng, Qi Liu, Chenhui Zhou, Xuyang Song, Boran Zhao, Hui Zhang, et al. Confidentiality support over financial grade consortium blockchain. InProceedings of the 2020 ACM SIGMOD international conference on management of d...

    2020

  8. [16]

    WebAssembly.https://webassembly.org/

  9. [17]

    Near Protocol.https://madewithwebassembly.com/showcase/near-protocol/, 2019

    2019

  10. [18]

    Polkadot Wiki.https://wiki.polkadot.network/learn/learn-wasm/

  11. [19]

    CosmWasm book.https://book.cosmwasm.com/

  12. [20]

    A gentle introduction: Stylus.https://book.cosmwasm.com/

  13. [21]

    Wasmtime.https://github.com/bytecodealliance/wasmtime

  14. [22]

    Wasmer.https://github.com/wasmerio/wasmer

  15. [23]

    Just-In-Time.https://en.wikipedia.org/wiki/Just_in_Time

  16. [24]

    Ahead-of-Time.https://en.wikipedia.org/wiki/Ahead-of-time_compilation

  17. [25]

    Case study of webassembly runtimes for ai applications on the edge

    Saif eddine Khelifa, Miloud Bagaa, Ahmed Ouameur Messaoud, and Adlen Ksentini. Case study of webassembly runtimes for ai applications on the edge. In2024 Global Information Infrastructure and Networking Symposium (GIIS), pages 1–6. IEEE, 2024

    2024

  18. [26]

    revmc.https://github.com/paradigmxyz/revmc

  19. [27]

    evmone.https://github.com/ethereum/evmone

  20. [28]

    Zan.https://zan.top/, 2024

    2024

  21. [29]

    AntChain Open Labs.https://openlabs-intl.antdigital.com/home, 2024

    2024

  22. [30]

    Artificial intelligence for web 3.0: A comprehensive survey.ACM Comput

    Meng Shen, Zhehui Tan, Dusit Niyato, Yuzhi Liu, Jiawen Kang, Zehui Xiong, Liehuang Zhu, Wei Wang, and Xuemin (Sherman) Shen. Artificial intelligence for web 3.0: A comprehensive survey.ACM Comput. Surv., 56(10), May 2024

    2024

  23. [31]

    Synchromesh: Reliable code generation from pre-trained language models

    Gabriel Poesia, Alex Polozov, Vu Le, Ashish Tiwari, Gustavo Soares, Christopher Meek, and Sumit Gulwani. Synchromesh: Reliable code generation from pre-trained language models. InThe Tenth International Conference on Learning Representations, ICLR 2022, Virtual Event, April 25...

    2022

  24. [32]

    A survey on large language models for code generation.CoRR, abs/2406.00515, 2024

    Juyong Jiang, Fan Wang, Jiasi Shen, Sungju Kim, and Sunghun Kim. A survey on large language models for code generation.CoRR, abs/2406.00515, 2024

    2024 arXiv

  25. [33]

    Efficacy of various large language models in generating smart contracts

    Siddhartha Chatterjee and Bina Ramamurthy. Efficacy of various large language models in generating smart contracts. In Kohei Arai, editor,Advances in Information and Communication - Proceedings of the 2025 Future of Information and Communication Conference (FICC), Volume 2, Be...

    2025

  26. [34]

    Automatic smart contract comment generation via large language models and in-context learning.Inf

    Junjie Zhao, Xiang Chen, Guang Yang, and Yiheng Shen. Automatic smart contract comment generation via large language models and in-context learning.Inf. Softw. Technol., 168:107405, 2024

    2024

  27. [35]

    Parizi, and James L

    Viraaji Mothukuri, Reza M. Parizi, and James L. Massa. Llmsmartsec: Smart contract security auditing with LLM and annotated control flow graph. InIEEE International Conference on Blockchain, Blockchain 2024, Copenhagen, Denmark, August 19-22, 2024, pages 434–441. IEEE, 2024

    2024

  28. [36]

    FELLMVP: an ensemble LLM framework for classifying smart contract vulnerabilities

    Yu Luo, Weifeng Xu, Karl Andersson, Mohammad Shahadat Hossain, and Dianxiang Xu. FELLMVP: an ensemble LLM framework for classifying smart contract vulnerabilities. InIEEE International Conference on Blockchain, Blockchain 2024, Copenhagen, Denmark, August 19-22, 2024, pages 89...

    2024

  29. [37]

    https://www.helius.dev/blog/ how-to-build-a-secure-ai-agent-on-solana

    How to Build a Secure AI Agent on Solana. https://www.helius.dev/blog/ how-to-build-a-secure-ai-agent-on-solana

  30. [38]

    https://near.org/blog/ shade-agents-the-first-truly-autonomous-ai-agents

    Shade Agents: The First Truly Autonomous AI Agents. https://near.org/blog/ shade-agents-the-first-truly-autonomous-ai-agents

  31. [39]

    Dune.https://dune.com/home, 2025

    2025

  32. [40]

    Patrick S. H. Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich Küttler, Mike Lewis, Wen-tau Yih, Tim Rocktäschel, Sebastian Riedel, and Douwe Kiela. Retrieval-augmented generation for knowledge-intensive NLP tasks. In Hugo Laroche...

    2020

  33. [41]

    Model Context Protocol.https://modelcontextprotocol.io/introduction

  34. [42]

    Yul.https://docs.soliditylang.org/en/latest/yul.html

  35. [43]

    Qwen technical report.arXiv preprint arXiv:2309.16609, 2023

    Jinze Bai, Shuai Bai, Yunfei Chu, Zeyu Cui, Kai Dang, Xiaodong Deng, Yang Fan, Wenbin Ge, Yu Han, Fei Huang, et al. Qwen technical report.arXiv preprint arXiv:2309.16609, 2023

    2023 arXiv

  36. [44]

    Large language model-powered smart contract vulnerability detection: New perspectives

    Sihao Hu, Tiansheng Huang, Fatih Ilhan, Selim Furkan Tekin, and Ling Liu. Large language model-powered smart contract vulnerability detection: New perspectives. In2023 5th IEEE International Conference on Trust, Privacy and Security in Intelligent Systems and Applications (TPS...

    2023

Pith tools

Reviewed August 16, 2026 · model on record in the stance chip above.