Vara-AMM: High-Concurrency Trading in the Actor Model

Moving beyond the synchronous global lock to build a decentralized exchange that scales like a distributed system.

• View on GitHub • More from gear-foundation

An illustration of a massive clockwork post-office where a clerk hands a letter into a pneumatic tube and receives a numbered token, symbolizing asynchronous message tracking.
In an asynchronous AMM, users do not wait at the counter for their swap to finish. They hand off a message and track its progress through the system.

Key Takeaways

The Ghost in the Machine: Asynchronous Atomic Swaps

The Actor Model is a staple of distributed systems like Erlang and Akka. It is a radical departure for decentralized finance. In the Ethereum Virtual Machine (EVM), transactions are atomic and synchronous. Everything happens or nothing does. In Vara-AMM, a single trade is a distributed conversation between independent actors.

This architecture introduces a unique risk known as partial failure. What happens to a trade when the first half succeeds but the second half hangs? The system cannot rely on a global lock to roll back the state. It needs a memory of its own actions.

The Wait-and-Track lifecycle of a message in the Vara-AMM architecture.

The Pair as a State Machine

To solve the partial failure problem, the developers built a message tracker. The file msg_tracker.rs acts as the memory of the trade. It replaces EVM atomicity with a state-machine-driven recovery system.

When a user initiates a swap, the contract records the message ID and enters a locked state. If the contract asks an external token contract to transfer funds, it must wait for a reply. The message tracker stores the state of these in-flight messages.

pub enum LockCtx {
    Swap(SwapCtx),
    AddLiq(AddLiqCtx),
    RemLiq(RemLiqCtx),
    SwapRefund(SwapRefundCtx),
    AddLiqRefund(AddLiqRefundCtx),
}

The LockCtx enum captures the full snapshot of an operation. The existence of refund variants proves the architecture is designed to handle partial failures by transitioning into a state where the user can claim back their assets.

Modular Liquidity via Sails

The project uses the Sails framework to split the contract into distinct services. This prevents a single monolithic file from managing the Pair, the LP Token, and the Factory.

This modularity enables a local lock pattern. The LP service is paused during reserve updates. This ensures that users cannot transfer LP tokens while the pool is in the middle of recalculating reserves.

Vara Network adopts core technologies such as the Actor Model, supports parallel computing, and offers native features like delayed messages and payless & gasless transactions. These features enable developers to easily build GameFi, DeFi, RWA, and other applications in a user-friendly and secure environment.

Gear Protocol, Developer of Gear Protocol and supporter of Vara Network · Building the Next-Gen Layer 1 with Gear Protocol

Synchronous vs. Asynchronous Liquidity

The architectural divergence becomes clear when compared directly to Uniswap V2. EVM execution is a stop-and-wait process. Gear execution is fire-and-forget-but-track.

FeatureLegacy EVM (Uniswap)Actor Model (Vara-AMM)
Atomicity ModelSynchronous global lockAsynchronous message tracking
Execution StyleSequentialParallel
Failure ModeAutomatic full rollbackState-machine driven refunds
State HandlingMonolithicSharded and service-based

Built for the Agentic Web

Parallel execution is the endgame for decentralized finance. Vara-AMM supports thousands of concurrent swaps without blocking them in a single-threaded queue. It is a blueprint for a world of automated agents and high-frequency execution.

A close-up illustration of a ledger book where a mechanical hand crosses out a Pending stamp and replaces it with a Recovered stamp.
The recovery-first design of the message tracker ensures the system handles failures gracefully without relying on global rollbacks.