OneSwap Operational Control Review: How the Live System Is Actually Run

Smart contract audits answer one question: was the code clean on review day. Operational reviews answer a different one : how is the live system actually run?

We just finished an operational control review of OneSwap mainnet. We're publishing it because we'd rather show you how the platform is run than ask you to take our word for it.

What this is, and what it isn't

This is an operator-prepared review of the live OneSwap mainnet deployment as of April 29, 2026, conducted by the protocol operations and infrastructure team responsible for reserve monitoring, settlement handling, and production runtime controls.

It covers four areas:

• Reserve integrity

• Settlement handling

• Runtime segregation

• Production release controls

We picked those four because they're the controls that most directly affect liquidity provider capital and trader outcomes in normal operations.

The review included live ledger reconciliation checks, reserve state verification across active pools, settlement path tracing, and deployment workflow validation against current production infrastructure.

It is not an external third-party audit. We're saying that out loud because the distinction matters. It also does not assess smart contract exploitability or formal code security review outcomes only the operational controls of the live deployment. What it is, is an honest accounting of the controls that are live today, with one open item flagged transparently.

Why operational, not just contract

Most DEX losses since 2021 weren't contract bugs. They were operational mispriced oracles, settlement edge cases, admin key compromises, reserve drift between internal accounting and on-chain state. The questions that matter for capital are usually about how the system runs, not how the code reads.

That's the gap this review addresses. We'll publish smart contract audit results separately when those are complete. This document is the other half of the picture the half that's harder to externalize and gets talked about less.

What was reviewed

Reserve integrity: How OneSwap knows what's actually in the pools, and what happens if internal accounting drifts from the live ledger state.

Settlement handling: What happens when a swap doesn't complete cleanly, and how the platform avoids silently marking ambiguous outcomes as success.

Runtime segregation: How the live system is structured across separate process boundaries so that a failure in one component doesn't cascade across the rest.

Release controls: What stands between a code change and production deployment.

What we found

Reserves are ledger-anchored, not database-trusted

OneSwap derives the tradable reserve view from live ledger holdings on the pool swap parties. The reserve number used for trading decisions is tied back to ledger state not trusted from application memory or a stale accounting table.

Balances that aren't deployable liquidity reserved fees and non-tradable holdings are explicitly excluded from the usable reserve view by design. This matters because including them would create an optimistic reserve picture that doesn't reflect what's actually available to trade against.

A separate database reserve field exists, but it's treated as an operational read model. The platform's maintenance layer reconciles the database view back against the ledger-derived view and corrects drift if it appears.

On the review date, every active mainnet pool was in sync between the database view and the ledger-derived view. No material variance requiring reconciliation was identified across active pools at the time of inspection. Reserve alignment was verified against the April 29, 2026 ledger snapshot rather than inferred from application state alone.

Settlement handling holds ambiguous outcomes open

A swap completing successfully isn't the same as a swap completing cleanly. The control objective for settlement is to carry a swap through output transfer, reserve accounting, fee accounting, and final bookkeeping without silently finalizing an incomplete state.

Where clean completion can't be established, OneSwap's posture is conservative. The platform doesn't force a terminal success state. Instead, the case remains visible for recovery or operator follow-up.

Ambiguous outcomes stay visible rather than getting silently classified as success. From a capital protection perspective, that's the correct failure posture it reduces the risk of misclassification when post-settlement evidence is incomplete.

The runtime is split across separate components

Mainnet operates as a split service runtime. The HTTP backend, ledger-facing workers, maintenance worker, and Temporal workers run as separate process boundaries rather than a single collapsed monolith.

The practical consequence is fault containment. A failure in one processing lane doesn't automatically take down visibility across the broader operating stack. Individual control planes can be restarted or recovered without taking down the entire execution path.

Production releases are gated

Production rollout to EC2 is gated by an automated backend test suite and a production dependency audit. Dependency update automation is also in place to limit lag in third-party packages.

These controls don't eliminate release risk nothing does but they materially improve release discipline and reduce the probability of shipping a preventable regression directly into the live runtime.

The one open item

A uniform crash-safe checkpointing model across all settlement and recovery paths is not yet complete.

That's a recoverability hardening item. It improves restart safety and operational recoverability under failure conditions. It does not affect the reserve alignment we observed on the review date, and it's not a reserve solvency concern.

Implementation is currently in progress, with staged testing across settlement recovery paths before full production rollout. We're flagging it because the honest answer matters more than the clean one. Most projects don't disclose their open items publicly. We think that's a mistake. If you're trusting a venue with capital, you should know what's done and what's still in progress.

Why we published this

Two reasons.

First, the controls described here are the ones LPs and active traders should be evaluating across every DEX they consider not just OneSwap. Reserve methodology. Settlement posture. Runtime segregation. Release discipline. These are the questions worth asking. If publishing our answers raises the bar for what people expect from any venue, that's a good outcome for the industry, not just for us.

Second, we'd rather be specific than vague. "Strong operational controls" is not a claim. "Reserves are derived from live ledger holdings and reconciled against the database read model, with no material variance requiring reconciliation across active pools on the review date" is a claim. The first one can't be checked. The second one can.

Trust in DeFi gets built through specifics, not adjectives. Read the audit here https://oneswap.cc/audit