SmartWeave vs EVM 🌀

Warp Contracts
11 min readJun 12, 2023


Paralleling SmartWeave values and properties to EVM paradigm and L2s efficiency

This document outlines SmartWeave’s distinct qualities, value proposition, and its potential to enhance the creation of highly efficient smart contract applications (dApps) for specific use cases. SmartWeave can serve as a complementary framework to fill the gap where the Ethereum Virtual Machine falls short.

Solidity: The Language of EVM — JavaScript of the Web3 Era

Solidity has emerged as the de facto programming language for smart contracts on distributed networks, making it the go-to computer language for developers in the blockchain space. It has blurred into becoming the JavaScript of the web3 era, providing a reliable and efficient means of creating and executing decentralized applications on the network powered by Ethereum Virtual Machine. Solidity, although it possesses a unique structure and syntax that can prove challenging for those considering web3 development, continues to draw a large influx of new learners. Furthermore, the EVM boasts a vast ecosystem brimming with resources, tools, educational materials, and enthusiastic developers.

source: @dabit3

Is the EVM a one-size-fits-all solution?

While the Ethereum Virtual Machine (EVM) is the golden standard framework for building decentralized applications as with everything it isn’t a one-solution-fits-all kind of thing. The EVM framework has strict limitations, which newly-found developers must learn to work with. A senior Solidity developer’s ability to optimize code for rigorous computation limits (in the form of gas limits), an extremely expensive resource in Ethereum-based frameworks, distinguishes him from the fresh-out-of-academy-type-guy. The disadvantage of this model is that it leads to a huge emphasis on block space, which can become an extremely expensive facility.

Furthermore, the requirement for consensus-driven synchronization of computations at every block adds an additional layer of complexity and challenge to the EVM’s design, acting as a significant roadblock to scaling efforts, especially given the sequential evaluation of all smart contract interactions. With potential tens of thousands of interactions as the space moves towards mass adoption, this becomes exponentially more challenging.

A noteworthy consideration involves the unique storage model within the Ethereum Virtual Machine. In most programming languages, understanding low-level data representation is not crucial, but Solidity deviates from this norm. Given the significant cost associated with storage access on Ethereum-based networks, having a firm grasp on how data types are represented is essential. The shared global storage model across all contracts, regardless of their interaction, brings its own set of challenges. The design introduces inefficiencies, forcing contracts to wade through extraneous data, slowing down transaction times, and incurring unnecessary computational costs. These costs contribute to an increased financial burden for storing data on the platform, affecting both developers and users. Additionally, the shared nature of storage could inadvertently amplify coding errors or vulnerabilities, leading to unintended consequences for unrelated contracts and potentially escalating rectification costs.

The architecture of the EVM strictly enforces the use of safe clients, thereby ruling out any non-deterministic approaches by default. This helps to enhance network safety and reliability. Additionally, EVM is extremely prone to on-chain vulnerabilities because of its complexity, which can make it difficult to ensure the correctness of smart contract code and mitigate potential attack vectors.

To EVM or not to EVM | source: @Mudit__Gupta

On the other hand, non-EVM systems can have higher developer costs, entry barriers, and migration difficulties. Ultimately, the decision to use the EVM for a specific project will depend on several factors, including the needs of the project and the preferences of the developers.

What is SmartWeave?

SmartWeave is a paradigm for evaluating smart contract states on an immutable data layer like Arweave. Because a data layer does not perform arbitrary computing it places the responsibility for assessing the current contract state on the caller using a process called lazy evaluation.

To “lazy” evaluate the current state of a contract, the caller verifies and executes all contract interactions (Arweave transactions) from the contract’s inception to the present, reproducing the current state of the contract from scratch.

In essence, Arweave smart contracts consist of an ordered set of actions (C, I, Ts), with C being the portion containing the contract code, I being the fraction containing the initial state, and Ts being a sequence of transactions that interact with the contract. When the client evaluates the state, it utilizes the code from C, the initial state from I, and applies each transaction after it (provided it is valid) based on the contract code.

Here is a brief overview of the architecture.

Abhav Kedia @abhav_k, Arweave: State of the Ecosystem, August 2022

SmartWeave is an architecture aimed at creating a reliable, fast, and production-ready smart contracting engine on Arweave. Its most popular implementation, Warp Contracts, is focused on delivering this exact goal. Warp is often described as “SmartWeave contracts on steroids” due to its ability to overcome some of the most significant obstacles associated with the default implementation of the SmartWeave protocol. These obstacles include the lack of caching that leads to low performance, the absence of a reliable SmartWeave transaction gateway, and the inability to ensure contract security and determinism. In addition to its main function, the Warp SDK includes a finely-tuned caching layer that greatly enhances lazy evaluation efficiency. The stack also includes user-friendly deployment and maintenance methods, customizable plugins that allow users to extend the SDK in any direction they desire, a dedicated smart contract explorer, a set of nodes for outsourcing execution and several other essential features. The Warp core team has created a range of proprietary plugins, including portable EVM tooling, EVM wallet support, EtherJS native support in the SmartWeave environment, and others. As of now, Warp supports JavaScript/TypeScript languages and WASM with Rust support.

Distinguishing EVM from SmartWeave Architecture

The EVM’s security is intrinsically linked to the consensus technology of the underlying blockchain it operates on. Likewise, SmartWeave also depends on the security and end-finality of Arweave’s blockchain, which is achieved through the inclusion of blocks finalized using the SPoRa (Succinct Proofs of Random Access) protocol.

EVM, by design structure, implements the fee market into the core protocol. The market fee scheme uses a first-price auction mechanism to determine transaction fees, where the highest bidder has their transaction processed first. The challenges associated with scaling the network become particularly apparent during periods of high demand, as seen with the global fee market design of the Ethereum Virtual Machine. For instance, when an individual contract experiences considerable activity, such as a much-anticipated NFT mint, it inadvertently impacts all network users by escalating transaction costs, even for those who aren’t directly involved with the high-demand activity.

Arweave proposes an alternative approach to the traditional fee market by utilizing a single reward pool and merkle root for all data, called the endowment. Adding new data to the system updates the merkle tree and adds $AR tokens to the reward pool without causing an increase in computational overhead. To address the bottleneck of processing payments for data storage, Arweave uses a system of recursive bundles to settle multiple transactions in a single payment on the network. Eventually, this could lead to trees of infinite depth that allow for the ingestion of all web data within a single transaction, eliminating the need for fee markets. Arweave’s transaction system allows users to execute transactions without a block inclusion fee, resulting in storage costs being the only expense for executing transactions, no matter the demand side.

Essentially, SmartWeave is a sequenced array of Arweave transactions that benefits from the absence of a fee market for transaction block inclusion. This unique property allows for unlimited transaction data without additional fees beyond storage costs. Furthermore, the open-ended design of SmartWeave enables developers to write the logic in any programming language, offering a refreshing alternative to the often rigid Solidity codebase.

Fee Market | No Easy Way Out | source: iamDCinvestor

Lazy Execution: An Alternative Perspective of Looking at Things

The modular thesis has been one of the most prominent narratives in the blockchain space over the past years. Pretty much all of the leading L1s, Solana could be the only exception here, settled on scaling decentralized networks by modular approach instead of relying on a monolithic layer responsible for delivering all the blockchain’s properties.

SmartWeave is a unique approach to the modular thesis. Solely focused on scaling distributed ledger compute capabilities via separating the data storage from the execution layer.

SmartWeave utilizes a unique approach known as “lazy evaluation,” which transfers the responsibility of executing smart contract code from network nodes to the users of the smart contract. In essence, this means that the computation of transaction validation is deferred until it is required, reducing the workload on network nodes and allowing for more efficient processing of transactions. This approach enables users to execute as much computation as needed without incurring additional fees, offering functionalities that are not feasible with other smart contract systems. As a result, builders no longer have to worry about gas optimization, when evaluation is offloaded to users.

source: @DennisonBertam

SmartWeave Protocol: Challenges and Constraints

Financial primitives are one of the most significant applications of blockchain technology, and the EVM is particularly suited for this purpose due to its strict and deterministic execution of smart contract code on every network node. Additionally, the massive amounts of money that underlie EVM platforms, such as Ethereum Mainnet and consonantly L2s, provide a high level of security, making EVM-based smart-contract networks better positioned to capture the DeFi market.

Another crucial factor to consider is the need to scale SmartWeave applications that require heavy computation. This can only be achieved by delegating the execution layer to specialized entities, as relying on the user’s device alone would be impractical. Attempting to evaluate contracts with thousands of interactions on a user’s CPU would be a futile exercise. To overcome this challenge, an abstraction layer, such as Warp’s DRE, has been developed. It comprises a network of distributed validators that handle contract computations, leading to significant improvements in response-time and user experience. However, it’s important to ensure that this abstraction layer remains fully decentralized at the end stage, to avoid any third-party dependencies and censorship issues. Nonetheless, it’s worth noting that the overlying execution layer, which could be susceptible to hypothetical malicious activity, cannot compromise the decentralization and immutability of the SmartWeave data stored on Arweave. Any entity can retrieve the data directly from Arweave and execute the contract’s state on its own, thus preventing any fraudulent activities.

While there are already many applications providing added value for Permaweb users, the Arweave ecosystem is still in its early stages. Currently, the exploration and definition of standards are ongoing, similar to the early days of Ethereum with the creation of the prime ERC standards. Compared to EVM systems, developer activity, and available tooling remain niche. While this can be a disadvantage for newcomers due to the steep learning curve, it also presents an exciting opportunity for true innovation, which is the backbone of the crypto industry.

SmartWeave Market Fit

While it’s interesting to talk about architecture design advantages and constraints in theory, let’s focus on the practical side of things and explore specific use cases where EVM might not be the best fit. That’s where SmartWeave could potentially fill a niche.

DeSoc (Decentralized Social) has recently emerged as a major trend in the crypto space, generating excitement, community involvement, and developer engagement akin to the legendary DeFi summer. DeSoc aims to solve the challenges of traditional social media, such as disjointed creator monetization and disproportionate platform value, through an open architecture that unlocks social graph data. However, social graph protocols such as Lens Protocol, Farcaster, and CyberConnect are still in their early stages of development, with various standards and tradeoffs to consider.

source: @MessariCrypto

One of the setbacks for the social graph protocols to consider is the limitations of the EVM. This includes high gas fees and a long finality window. Nobody wants to wait for two minutes to process a “like” action. A possible solution is to store less critical data, such as likes and mirrors, off-chain, while posting more important actions on-chain. However, this approach may require sacrificing on-chain programmability and decentralization.

source: @lensprotocol

Warp, however, excels in both of these EVM’s restraints thanks to its unusual architecture and ability to keep user interactions on the permaweb (Arweave ledger) without sacrificing user experience. By delegating certain high-cost or high-throughput actions to Warp, existing social graph protocols built on EVM chains can be enhanced with seamless SmartWeave integration, leveraging the strengths of both technologies. An example of such a mutual symbiosis can be found in the graphic below:

SmartWeave’s adoption can be augmented by exploring AI and financial modeling, thanks to the benefits of transparent underlying data stored on-chain and the ability to combine it with other Arweave network modules. Such integration is economically infeasible on an EVM system due to high storage costs. While still nascent, experimentation with machine learning models utilizing Warp software is already happening today, here.

One of the most common use cases widely adopted now is a variety of database implementation systems built using the Warp SDK, which is capable of processing production-ready volumes of interactions on a large set of data that would be unmanageable on the EVM network. Leading the permissionless DB cohort are several projects, including WeaveDB, FirstBatch, Glacier, and Kwil.

There are still many interesting and unexplored possibilities for the Warp protocol, such as bringing business logic on-chain for document management or deal signing. The early stage of the tech stack and web3 gaming also present opportunities for specific engine modules to live on-chain, like scoreboards and ledgers of items. These areas have the potential to provide significant traction for Warp’s growth, even if just one sizable enterprise or game studio decides to offload some of their workflow on-chain.


While the Ethereum Virtual Machine (EVM) has been widely accepted as the go-to solution for blockchain applications, it may not always be the best choice.

At Warp, we believe that SmartWeave, a permanent and immutable execution environment without the limitations of network-wide consensus for state validation, could serve as a complementary network or viable alternative for specific modules in the web3 ecosystem.

Here’s a comparison table summarizing both execution environments:

Note: The dashboard does not include the TPS (Transaction Per Second) metric, as comparing network-wide consensus in Ethereum/L2s with single contract evaluation is not appropriate