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.
- Vara-AMM replaces the synchronous global locks of traditional blockchains with an asynchronous Actor Model to enable high-concurrency trading.
- A dedicated message tracker manages partial failures by recording in-flight message IDs and transitioning the contract through a state machine.
- The architecture utilizes the Sails framework to modularize liquidity services and implement local locks for reserve updates.
- The system handles failed transactions through state-driven recovery and refund mechanisms rather than automatic universal rollbacks.
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 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.
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.
| Feature | Legacy EVM (Uniswap) | Actor Model (Vara-AMM) |
|---|---|---|
| Atomicity Model | Synchronous global lock | Asynchronous message tracking |
| Execution Style | Sequential | Parallel |
| Failure Mode | Automatic full rollback | State-machine driven refunds |
| State Handling | Monolithic | Sharded 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.