Auticuro vs Solana: two approaches to high-throughput account balance management

Airwallex just open-sourced Auticuro, the Rust-based wallet service that powers money movement across their global payments platform. The benchmark they ship with it: P99 latency under 20ms at 10,000 transactions per second across a five-node cluster on GCP, with fault recovery in under four seconds. That is a serious number for traditional infrastructure. It is also interesting to compare against Solana, which handles 65K+ TPS with 400ms finality on a permissionless network. Both are solving high-throughput account balance management. The approaches are almost opposites.

What Auticuro is

Auticuro is a permissioned, clustered wallet service — not a blockchain. It is the kind of system a bank or payments company builds internally and never shows anyone. Airwallex built it to handle multi-asset account balances (cash, crypto, coupons) across their global operations, then open-sourced it under their GitHub org.

The architecture is CQRS with event sourcing: commands (writes) and queries (reads) are completely separate systems. The write path is a single leader node accepting gRPC requests, appending them to a Raft log, and waiting for a quorum of followers to acknowledge before responding. The read path is stateless services that consume the event log and build materialized views — account hierarchies, balance history, analytics — without ever touching the write path.

// Auticuro's write path (simplified)
// 1. gRPC request arrives at leader
// 2. Appended to Raft log (single-threaded, no locks)
// 3. Replicated to N-1 followers
// 4. Committed once quorum acknowledges
// 5. Response returned to client

// Key properties:
// - Exactly-once semantics via request ID deduplication
// - Strong consistency (no dirty reads)
// - P99 < 20ms at 10K TPS (5-node GCP cluster)
// - RTO <= 4s on node failure (automatic leader election)

// Supported operations:
// - create_account / lock_account / delete_account
// - transfer (bilateral, atomic)
// - batch_transfer (multi-account, atomic)
// - Multi-asset: cash, cryptocurrency, coupons

What Solana is

Solana is a permissionless L1 blockchain — anyone can participate as a validator, anyone can deploy a program, and no central operator controls which transactions are included. The consensus mechanism is Tower BFT (a PoH-optimised variant of PBFT), not Raft. Finality is around 400ms. TPS in production exceeds 65,000.

For account balance management specifically, Solana has token accounts — SPL Token program accounts that hold a balance of a particular mint. Every transfer is a Solana transaction: signed by the owner, executed by the runtime, committed on-chain, and permanently visible to anyone. There is no operator who can roll back a transaction, adjust a balance silently, or freeze the system for maintenance.

// Solana: transfer SPL tokens between accounts
import { createTransferInstruction, getAssociatedTokenAddress } from "@solana/spl-token";
import { Transaction, sendAndConfirmTransaction } from "@solana/web3.js";

const src  = await getAssociatedTokenAddress(mint, sender.publicKey);
const dest = await getAssociatedTokenAddress(mint, recipient);

const tx = new Transaction().add(
  createTransferInstruction(src, dest, sender.publicKey, amount)
);

const sig = await sendAndConfirmTransaction(connection, tx, [sender]);
// Finality in ~400ms. Permanently on-chain. No operator can reverse it.

The key differences

Trust model

This is the fundamental difference. Auticuro requires you to trust the operator — Airwallex, or whoever you deploy it for. The Raft cluster is permissioned: only known nodes participate. The operator can freeze accounts, reverse transactions (with appropriate tooling), and control who can submit commands. This is a feature for a regulated payments company; it lets them comply with sanctions, chargebacks, and court orders.

Solana requires you to trust the protocol, not any operator. No single entity controls which transactions are processed. A validator cannot selectively censor your transaction without colluding with a supermajority of stake. There is no admin key that can reverse a committed transfer.

Consistency model

Auticuro uses strong consistency: every read sees the most recent committed write. Raft guarantees this within the cluster. A balance query returns the actual current balance, not a possibly-stale snapshot. The tradeoff is that writes block until a quorum acknowledges, which is why the P99 under load is 20ms rather than sub-millisecond.

Solana uses eventual consistency in the sense that different validators may be at different slot heights, but once a transaction reaches confirmed or finalized status (typically 400ms), it is irreversible and globally visible to all nodes. The runtime uses optimistic concurrency on accounts — parallel transactions touching different accounts execute simultaneously.

Throughput and latency

Auticuro's 20ms P99 is measured within a private cluster — no cross-internet hops, known hardware, controlled load. Solana's 400ms is end-to-end on a global permissionless network with thousands of validators across multiple continents. These are not directly comparable numbers; they measure different things.

Fault recovery

Auticuro ships a log reconciliation engine that continuously compares Raft and event logs across replicas. If a discrepancy is detected, it can roll back or roll forward to a consistent state, then isolate the failed replica. Recovery from a node failure takes under four seconds. This is the kind of operational tooling that mature financial systems need — audit trails, discrepancy detection, and deterministic recovery procedures.

On Solana, there is no concept of rolling back a committed transaction. The equivalent of fault recovery is validator slashing (for Byzantine behaviour) and fork resolution (via Tower BFT). Once a transaction is finalized, it is final. Error handling has to happen at the application layer — programs use checked arithmetic, authority verification, and optimistic locking via account version fields.

When you would choose each

Auticuro fits when you need: a regulated environment where an operator must be able to freeze accounts or reverse transactions; sub-20ms latency; an air-gapped or private deployment; multi-asset accounts (cash, crypto, loyalty points, coupons) in one system; and event sourcing for compliance audit logs.

Solana fits when you need: permissionless access (no operator approval to transact); global settlement between parties who do not trust each other; programmability (arbitrary logic in programs executes atomically with transfers); composability (any program can call any other); and a public audit trail that no single party controls.

The interesting observation is that these two systems could be complementary. A bank could run Auticuro internally for real-time intrabank transfers — settling positions between internal accounts in 20ms — and use Solana for cross-bank settlement, stablecoin issuance, or programmable payment rails where counterparty trust is not established. The internal ledger handles speed; the blockchain handles trust between institutions.

The Rust connection

Both Auticuro and the Solana runtime are written in Rust. For financial infrastructure, this matters: memory safety without garbage collection means no GC pauses during high-load periods, and ownership semantics make certain classes of concurrency bugs impossible at compile time. Auticuro explicitly chose Rust for “performance comparable to C++ and memory and thread safety.” The Solana Labs team made the same bet in 2017. It has aged well for both.

# Run Auticuro locally
git clone https://github.com/airwallex/Auticuro
cd Auticuro
# Requires Rust toolchain
cargo build --release

# Single-node dev mode
cargo run --bin wallet-service -- --config config/dev.toml

# 5-node cluster (production topology)
# See deployment/ directory for cluster configuration