Why Algorand?
Building Orbital AMM on Algorand wasn't just a deployment choice — it was a technical necessity. The AVM's (Algorand Virtual Machine) architecture provides specific capabilities that make the Orbital invariant verifiable on-chain, while the EVM's limitations would have required compromising the design.
Native 512-bit Math
The Orbital invariant requires computing sums of squares of reserves. For a pool with 50,000 USDC (50,000 × 10⁶ microunits), squaring the reserve gives 2.5 × 10²¹ — far beyond uint64's max of 1.8 × 10¹⁹. The AVM provides native 512-bit multiplication via mulw (which returns both low and high 64-bit words), allowing us to compute and compare large squared values directly.
On the EVM, we would need a custom fixed-point math library, burning opcode budget on every operation. Algorand gives us this capacity as a first-class opcode.
√ as First-Class Opcode
The equal-price point calculation requires computing:
The AVM's sqrtopcode computes integer square roots in constant time. This is critical for computing tick boundaries and verifying crossing conditions. On EVM, square root requires Newton's method iteration — expensive and variable-gas.
Box Storage for Arbitrary Data
Orbital requires storing per-tick state (r, k, isActive) and per-position data (shares, fee checkpoints). Algorand's box storage provides arbitrary key-value storage attached to the app, with 64KB per box and up to 64MB total.
Our storage layout:
| Box Key | Size | Contents |
|---|---|---|
reserves | n × 8 bytes | Per-token reserve microunits |
fee_growth | n × 8 bytes | Fee growth per unit radius |
token:{idx} | 8 bytes | ASA ID for token index |
tick:{id} | 25 bytes | r (8), k (8), isActive (1), totalShares (8) |
pos:{owner}{tickId} | 8 + n × 8 bytes | shares (8), fee checkpoints (n × 8) |
Atomic Transaction Groups
Adding liquidity requires transferring n different ASAs to the pool and calling the smart contract. On Algorand, these happen in a single atomic group: either all transfers succeed and the app call executes, or everything fails. This eliminates reentrancy risk and ensures invariant preservation.
The same pattern applies to swaps: the user's input transfer, the app call, and the pool's output transfer all happen atomically. No intermediate state is observable.
Opcode Budget Pooling
Algorand allows grouping multiple transactions that share a single opcode budget. For complex operations like tick crossing (which requires re-consolidating the torus invariant), we can split verification across multiple app calls in the same group, effectively parallelizing the computation.
The Tradeoff: Unit Scaling
Despite the AVM's strengths, we still needed to introduce AMOUNT_SCALE = 1000to prevent overflow. Reserves are divided by 1000 before squaring, bringing the max square from 10³² to 2.5 × 10⁹. This is documented in theUnit Scaling section.
The EVM would have required far more aggressive scaling, losing precision. Algorand's uint64-centric model is actually a better fit for Orbital's math than the EVM's 256-bit words, because the opcodes we need (sqrt, mulw) are native rather than emulated.
Bottom line: Algorand gives us cheaper verification, better math opcodes, and atomic composability. The Orbital invariant would be prohibitively expensive to verify on EVM.