Lighter opens EVM devnet access for developers building on Core

A testing environment for applications

Lighter announced its EVM devnet on 16 October, opening an early development environment for applications that interact with Lighter Core. Built with Axiom and powered by OpenVM, it lets developers deploy smart contracts, read trading information, manage orders and move assets. The immediate audience is teams building software around the exchange, rather than customers waiting for a finished new trading application.

The public announcement invites teams to request access through Lighter and says developers are being admitted in cohorts. Broader access is expected in the following weeks, without a firm opening date. Lighter also directs builders to its EVM Discord role and channels for updates. Public documentation therefore does not mean every developer already has network access.

How the contract environment connects to Core

EVM means Ethereum Virtual Machine, the environment that executes Ethereum-style smart contracts: programs deployed to a blockchain. Axiom describes Lighter EVM as a companion rollup to Core, with Core retaining its specialized matching and risk engine. The test release includes separate instances of both systems and test markets, allowing applications to work against an order book.

Contracts can read Core information synchronously, within the same execution, through a built-in interface called a read precompile. Writes are asynchronous: a request to place, change or cancel an order is handled separately, and its status can be checked afterward. This distinction matters for application design because sending a request is not the same step as establishing its result.

Axiom says existing Ethereum tools can be used and ETH pays for transaction execution.

Important limits of this devnet

The developer introduction says a privately deployed base chain stands in for Ethereum. More importantly, finalization on that chain uses mocked zero-knowledge proofs. A mocked proof is a testing substitute, so this environment does not demonstrate the complete production verification process described in the architecture. Builders should distinguish exercising an application from validating all of its intended security guarantees.

The documentation also says the permissionless escape hatch is not fully functional. That mechanism is intended to provide a recovery route when normal operation fails; its incomplete state is a material limitation of the test release. The broader architecture must not be read as a promise that this recovery path already works here.

Calls that read Core currently work only at the latest block. Earlier-block support is planned. An application that needs historical state cannot assume the same interface already provides it.

What a first transaction requires

The official quickstart begins with a disposable account controlled by the developer, access to the network endpoint and a balance of Lighter EVM ETH. It uses Foundry’s cast utility to inspect the connection and send a transfer. An endpoint is the address through which software asks the network to read information or submit a transaction.

Before sending anything, the example checks the chain identifier, which is 19529, and the sender’s balance. Its sample transfer uses a gas limit of 30,000. The guide explains that Lighter also derives a data-availability budget from this limit, so a plain transfer needs more than Ethereum’s usual 21,000. These are resource limits, not quoted dollar fees or a guaranteed price for every transaction.

After submission, the guide checks the transaction, its receipt and the recipient balance. Those separate observations make the example useful: a submission identifier alone does not replace checking what happened. The quickstart is a developer test procedure, not an invitation to transfer production assets into an unfamiliar network.

One application, several distinct domains

Lighter’s interoperability overview separates the base chain, EVM and Core. It organizes the integration around account authorization, reading Core, messages between domains and token representations. Interoperability here means making those systems work together; it does not erase their separate execution roles.

For a builder, the practical task is to follow a request across those boundaries and verify its outcome. That is why the testing release is useful even before broader access: it provides a place to develop the application’s handling of connections, requests and results, while the documented devnet limitations remain visible.