Aquantis

Demo

About

Aquantis is an application that runs trading strategies for Herculis Gold Coin (XAUH) [https://xauh.gold/] on the Aqua protocol, delivered as a Telegram Mini App with a built-in AI agent – a convenient, all-in-one Telegram experience for managing an XAUH gold portfolio. The system is built directly on top of XAUH, an Real-World-Asset (RWA) token that is already deployed and trading on Mainnet, so Aquantis operates against a live, gold-backed on-chain asset rather than a simulated or testnet environment. Herculis Gold Coin (XAUH) is a Swiss gold-backed payment token issued by Herculis Tokens SA [https://herculis.ch/herculis-tokens-sa], where each token represents one gram of 999.9-purity LBMA [https://www.lbma.org.uk/] gold that is refined, audited, stored, and insured in Swiss vaults. XAUH is already live across four networks – Ethereum [https://ethereum.org/], TON [https://ton.org/], TRON [https://tron.network/], and Polkadot [https://polkadot.com/], with JAMTON [https://app.jamton.network/] serving as the bridge connecting TON and Polkadot infrastructure. On Ethereum specifically, it's deployed as a verified ERC-20 token tracked on Etherscan [https://etherscan.io/token/0xa9b17f572341219703Bc951725Bdb3CA756B1A65], with an active XAUH/USDT liquidity pool on Uniswap [https://app.uniswap.org/explore/tokens/ethereum/0xa9b17f572341219703Bc951725Bdb3CA756B1A65] – giving Aquantis a live, tradable market to build its strategies on from day one. A key technical limitation of Aqua, 1inch's self-custodial shared-liquidity protocol, is that it does not natively support fee-on-transfer (FoT) tokens – assets that deduct a percentage on every transfer, so the amount received is less than the amount sent. Because Aqua's core contract and its AquaApps track maker and taker balances based on the amount specified in a swap rather than the amount actually delivered, an unhandled FoT token can desynchronize that internal accounting, breaking pricing logic and putting maker funds at risk; 1inch itself lists "Lack of support for Fee-on-Transfer (FoT) tokens" as out of scope in its bug bounty program, treating it as a known, unaddressed gap rather than a bug to be patched. Solving it matters because Aqua's own stated ambition is to become a venue for real-world-asset trading – letting users swap tokenized gold, equities, and other RWAs directly against each other – and fee-on-transfer mechanics are common in exactly that asset class, so leaving this gap unhandled quietly locks a meaningful share of RWA tokens out of Aqua's strategies. This is where Aquantis comes in: because XAUH is central to the product, Aquantis adds fee-aware transfer handling on top of Aqua so XAUH swaps settle accurately instead of relying on Aqua's default 1:1 transfer assumption. We already have a working prototype of the TMA – the Herculis XAUH Agent – and we're now adapting it to work with 1inch's Aqua Protocol. The agent is designed to support several functions, one of which is trading strategy selection for XAUH: the user picks a strategy from the options the agent presents, and the Herculis XAUH Agent processes that choice by routing it through Aqua Strategies, choosing whichever shipped strategies currently offer the most advantageous terms. In other words, the strategy choice stays with the user and the agent, while Aqua Strategies function purely as the execution layer that prices and settles the trade on-chain. Aquantis integrates ID Quantique's [https://www.idquantique.com/] quantum random number generator (QRNG) to bring true, physically-sourced randomness into two parts of the product. Inside the Herculis XAUH Agent, it is used to randomly assign which of the agent's trading strategies a user runs, so strategy selection can't be predicted or steered by anyone, including Aquantis itself. The more interesting use case is feeding that same quantum randomness into the auction-style strategies makers ship on 1inch's Aqua protocol, giving those auctions a genuinely unpredictable, tamper-resistant randomness source that today simply doesn't exist in that part of the protocol.

How it's made

RWA support in the protocol. On the protocol side, the goal is to make XAUH – and any token with non-standard transfer behavior – tradable on Aqua without touching what already works, by treating fee-on-transfer support as an opt-in, backward-compatible layer rather than a rewrite. First, SwapVM already prices fees through its Fee instruction, with flat, protocol, and dynamic fee types deployed today; we'd add a further, equally first-class "token transfer fee" instruction that a maker can wrap around a swap to declare that the input or output token deducts a fee on transfer and how that fee should be priced, while every other opcode – Controls, XYCSwap, XYCConcentrate, Decay, PeggedSwap, Extruction – and every strategy already built from them keeps running exactly as it does today. Second, Aqua's settlement layer currently assumes a 1:1 relationship between the amount a push()/pull() call requests and the amount that actually lands, which is fine for standard ERC-20s but wrong for deflationary, fee-on-transfer, or rebasing tokens; reconciling based on the balance delta the token itself produces – checking the recipient's balance before and after the transfer instead of trusting the requested amount – makes settlement correct for XAUH-like assets while staying completely invisible for every token that already behaves normally. Third, because a taker's input today typically crosses two transfers before it reaches the maker's balance – taker to router, router to maker – a fee-on-transfer token gets taxed twice, leaving the maker short of what the strategy expected; an additional single-hop settlement mode, where the taker's tokens go straight to the maker, or the router simply forwards on whatever amount it actually received rather than the amount originally requested, removes that double deduction, while the existing two-hop path stays the default for every token that doesn't need it. Aqua Strategies as execution layer. This is exactly what we mean when we describe Aqua Strategies as an execution layer: Aqua.sol only tracks virtual balances and access – a strategy is opaque, ABI-encoded bytes from its perspective – while the actual pricing and execution logic lives in SwapVM or a custom AquaApp, which is precisely the separation the Herculis XAUH Agent relies on when it picks "the most advantageous option." Concretely, Aqua's own strategy catalog already gives the agent more than one way to execute the same XAUH swap: a basic constant-product curve (what we're calling the 1D strategy – a single XYCSwap price curve, x·y=k) and a concentrated-liquidity variant (the 2D strategy – the XYCConcentrate opcode, which adds a bounded price range on top of that same curve for deeper depth around the current price). Both are built from the same SDK strategy builder (AquaXYCAmmStrategy.new() for the 1D version, .newConcentrate() for the 2D version), so shipping either one is a matter of parameters, not a different integration. When a user wants to trade XAUH, the agent calls SwapVM's free quote() against every currently shipped strategy that can fill the order – a 1D XYC pool here, a 2D concentrated position there – compares the amountOut each one returns after fees, and then executes swap() against whichever (maker, app, strategyHash) currently prices best; the strategy choice is entirely the agent's, Aqua and SwapVM simply settle whichever one wins. Random number generation in this context. Both of our quantum-randomness use cases plug into that same execution-layer picture. For strategy selection inside the Herculis XAUH Agent, a call to ID Quantique's Quantis QRNG returns a block of true random bytes, which we reduce (modulo, with rejection sampling to avoid bias) to an index into the agent's list of available trading strategies – the agent then executes that strategy the normal way, through whichever Aqua strategy prices best, exactly as described above. For the Aqua side, the SDK's strategy builders already expose a withSalt(...) parameter – salt is meant to be an arbitrary, ideally unpredictable value, which is exactly what a QRNG is for; instead of deriving that salt from something guessable (a counter, a timestamp, a locally-seeded PRNG), we draw it directly from the Quantis QRNG before the strategy is built and shipped, so the resulting strategyHash – and, in a Decay-priced strategy, the auction parameters riding alongside it – carry entropy that no party, including Aquantis, chose or could have predicted in advance. Because this all happens off-chain, in the same AquaProgramBuilder step every maker already uses before calling ship(), it's a drop-in substitution rather than a protocol change.