[RFC] HyperCow is a decentralized orderbook exchange built on Anoma

Preface
The purpose of this document is to provide a high-level motivation for why we want to build a DEX application as part of our go-to-market Anoma on Ethereum product launch. The Executive memo below is specifically designed to provide the high-level motivations and links to various sources that would benefit the curious reader. The remainder of the document attempts to begin the process of outlining the product.

One of the things that really hurt Apple was that after I left John Scully got a very serious disease. I’ve seen other people get it to. Its the disease of thinking that a really great idea is 90% of the work. And if you just tell all these other people, here’s this great idea then of course they can go off and make it happen. The problem with that is there is just a tremendous amount of craftsmanship in between a great idea and a great product.
– Steve Jobs

The above note is a reminder to both the reader and the author that an idea is not sufficient. In order to bring a product like this to life it will take tremendous craftsmanship from many individuals and teams contributing to Anoma.

This document was co-authored with @maurice and initially reviewed by @cwgoes. Feedback != endorsement. Thank you.

tl;dr

  • HyperCow is a decentralized orderbook exchange built on Anoma.
  • HyperCow is designed to acquire real users and inspire future developers.
  • This application features trading based on Anoma intents (constraints and preferences).

Table of contents

Executive memo

Choose wisely

Apple doesn’t have the most resources of everyone in the world and the way we have succeeded is by choosing what horses to ride very carefully, technically. We try to look for these technical vectors that have a future, and that are headed up. Different pieces of technology kind of go in cycles. They have their springs and summers and autumns and then they go to their graveyards. So we try to pick things that are in their springs. And if you choose wisely, you can save yourself an enormous amount of work versus trying to do everything. And you can make those technologies be great on your platform rather than just okay because you are spreading yourself too thin.
– Steve Jobs

Its all just swaps

There are only four application types in crypto.

  1. Payments
  2. Swaps
  3. Yield (staking, lending and borrowing, vaults, OTC lending)
  4. Leverage (CDPs, Looping, Perps, Options, other derivatives)

In reality, it’s all just swaps, though.

  • Sending a payment to Alice because she gave you coffee—that is a swap.
  • Exchanging ETH for USD—that is a swap.
  • Depositing ETH and USD in a contract for an LP share—that is a swap.
  • Depositing collateral into Aave and receiving a loan—that is a swap.
  • Depositing ATOM and receiving stATOM on stride—that is a swap.
  • Depositing USDC as collateral and receiving a leveraged perp position—that is a swap.

There are more examples, but the point should be clear.

Swaps sit at the heart of Decentralized finance. Quite literally, exchanges are the core primitive. Although the global bitcoin stock exchange, EtherDelta and Wyvern DEX all preceded onchain AMMs, the first phase of successful exchanges in crypto was mostly automated market makers, with the biggest success being Uniswap v2.

The next phase included onchain order books (Serum, Phoenix) and off-chain auctions like CowSwap or UniswapX. Unfortunately, onchain order books always will have some latency because you need to update your maker orders every block. As a result, the spreads will always be wider to account for this latency vs. Binance. No matter how cheap gas is on your chain, it will eventually get spammed enough to cause the spreads to widen further because of the gas costs to update the onchain orders. (USD cost). Auctions are great for price discovery for assets that you don’t know the true value of; however, for major assets like ETH there are other venues that can provide more liquidity and better pricing. So makers and takers are never incentivized to bid the fair value of ETH.

The final form of exchange is off-chain order books with exclusive on-chain settlement. This is an off-chain auction. However, solvers or market makers can compete in real-time because there is no block time constraint. Unless you impose one for batching purposes. As a result, you can eliminate gas overhead of updating orders and any latency constraints. You can also enforce custom sequencing rules with constraints, sometimes referred to as application-specific sequencing.

Crypto economies

Every economy will need some form of payments, borrowing and lending, staking, leverage, and swap capabilities. Beyond these core primitives, perhaps communities will also need messaging applications, prediction markets, crowdfunding, depin networks, and maybe some other more niche or far-out use cases like transport and logistics.

Indeed, in order for Anoma to be a successful economy, there will need to be a successful DEX somewhere in the network. A crypto economy cannot survive without an exchange. But that’s starting from the top down. If we start from the bottom up, we see that two of the most successful products in this cycle were: Hyperliquid and Raydium (Pumpfun). While there was no new DEX that took off on the Ethereum main-net, Cowswap, 1 inch and UniswapX continued to see steady order flow and remain in dominant positions. This comes as no surprise. From the recent article Execution Welfare Across Solver-based DEXes:

Our results indicate that, compared to vanilla routing through Uniswap V2 or V3, solver-based protocols effectively enhance execution welfare for end users on DEXes within certain trade size ranges. This effect is most pronounced with USDC-WETH, a short-tail asset, and somewhat less significant with PEPE-WETH, a long-tail asset.

This also makes sense because market makers on Ethereum hold inventory for well understood / highly traded assets. Solvers typically double as market makers or receive quotes directly from market makers. And so they can provide better fills on short-tail assets. One nice feature of Anoma is that we can leverage solvers for exactly this type of activity. And as discussed above, because of our architecture, we can design some unique off-chain systems with onchain settlement for both long- and short-tail assets (as a reminder off-chain and on-chain are both part of the Anoma protocol, the term off-chain here is used in the sense of off-Ethereum main-chain and other semantic patterns).

What do solvers actually do?

They solve intents of course. Solvers in the Ethereum context play three roles:

  1. Routing, path finding, and execution - DEX aggregators and algorithm optimizers (Copium Capital)
  2. Fillers - Deal in cross-chain settings mostly carrying inventory of the same asset across chain participating in credit now, debit later intent bridge systems (Across, Relay)
  3. Market makers - fill users with their own inventory, Can offer quotes upon request

If you squint without your glasses, its really just market makers and routing algorithms. And typically, a “team” manages some type of entity that refers to itself as a “solver”. The economics of solving are still wait and see. Not everyone is willing to play ball for basis points in cross-chain filling. But swaps are an area where there can be a clear incentive for makers to compete, so long as there are users.

We’ll need many “solver” teams for Anoma over the long run. Starting with a DEX juices this necessary process.

What are intents?

Intents = preferences and constraints.

In particular, intents provide a way for the user to express what they want without needing to think about how to get what they want. See a simple introduction here. If you would like a refresher on the theory, or the mathematics of intents, please click through the links.

Intents are often linked to various exisiting order types. They are all intents;

  • Is a limit order an intent?–Yes
  • Is an RFQ an intent?–Yes
  • Is a Ethereum transaction an intent?–Yes
  • Is a market order an intent?-- Yes
  • Binding conditional commitments from 50-year-old game theory? – Yes.

Major Key :exploding_head: :key::

The key thing to understand is that intents enable the user to get what they want, without needing to know how to get it.

What Do users want?

It’s pretty clear that crypto users like to trade. They like to use decentralized exchanges, centralized exchanges, and hybrid constructions. Anoma provides an incredible substrate for a new type of hybrid construction that retains many of the properties of decentralization, reliability, scalability, and coordination that users come to expect from these products.

Aggregator Volumes

DEX Volumes

DEX Volumes by Chain

Perpetual Volumes

Big Picture

A DEX is the most adversarial venue that exists in crypto. We will be able to test our system in a highly adversarial setting. This will give us many insights in dealing with MEV, auctions, the slow game mechanisms (solver accountability), the peer 2 peer network, the resource machine, intents, and many other technical things.

There is also clear extensibility built into this strategy. A successful DEX in one domain (Ethereum) can be scaled with the deployment of the protocol adaptor to another domain. With a controller system that is live, users will be able to trade cross chain in the same way they trade the Ethereum MVP (HyperCow). This inevitably leads to an everything auction – multiparty, multivariate private bartering from the White Paper, also cross-chain HyperCow (credit to UniCowxSea).

If you want an argument for why EVM you can read this position, backed by data.

Partnerships

One clarifying point in choosing a DEX built on top of a clear Ethereum construction (Resource Plasma) allows us to reason about what types of integrations and partnerships will be required for our success. Some examples include;

  • Long-term Storage Providers
  • DA providers (publication / temporary retrieval)
  • Oracles
  • Market Makers
  • Wallets
  • Security Audits (Solidity Contracts)
  • Operator selection (anarchy, rotation, single operator)
  • MEV stuff
  • Interop partners

Community Engagement

Another benefit is that communicating this with the community allows us to start talking to potential HyperCow DEX users sooner than later. We can try to understand what is lacking from spot trading applications they use today, our competition. If we focus on user stories (agile) we’ll be able to scope out version features that make sense for our users.

Other Benefits

  • DEX users are willing to pay fees - profitability is more than possible
  • We become experts on our own stack, which enhances the knowledge we impart and share with our intents initiates and beyond.
  • We will learn how to talk to users and iterate. This is invaluable for the product design process.

The Future of the Crypto industry

Going forward, the best infra teams will build the best applications.

One trend we have seen in the marketplace over the last 5 years is that successful applications often look to scale once they find product-market fit. Examples include

  • DYDX - smart contract application → Starkware rollup → DYDX chain
  • Jupiter Aggregator → Perps → Order Types → Chain Jupnet
  • Uniswap v1 -v3 → UniswapX → Uniswap V4 → Unichain
  • Compound v1 → Compoun v2 → comp chain (fail) → Compound v3
  • Bored Apes - BAYC → BAKC → BAMC → Yuga Sale → Land Deeds → Token Drop → Orbiter L3

These are all wonderful teams, but often they run into problems or will run into problems when it comes to building a distributed system. Building a smart contract application with some off-chain server-side components is hard. But then taking that concept and building it into a distributed system, which your team has zero expertise in, is even harder. Fortunately, we know how to build distributed systems. We have researchers, engineers, and founders who are particularly good at it. Distributed Systems are hard.

On the other-side of the spectrum, teams like Espresso and Astria have been forced to pivot multiple times. Astria realized they needed to “do the hard work” and get good at product because no one was just going to show up and build an Astria sequenced rollup. Espresso has not made the user focused pivot yet; maybe you won’t see it until its too late. Similarly, Polkadot had some fantastic ideas, executed their architectural vision, raised tons of money, and pumped their token twice, but by many accounts, was a commercial failure. Parachains never amounted to anything significant, according to users. Perhaps JAM is the correct pivot; it’s early to say, but it’s clear they did not achieve the Ethereum killer vision that was set out from the beginning. It is not enough to do all these things well. You also need to build something people want.

Endgame

Our job is to deliver great Anoma products to the world. This includes AnomaDOS, a distributed operating system.

Indeed, we have to pick a path to get there. We have raised money from “crypto” venture capitalists who expect some kind of a crypto product. We have engaged with crypto “community” members; builders, hobbyists, friends, air drop farmers, and bots. Many of our go to market ideas revolve around some type of crypto product. In this document we clearly lay out what that product is (application tentatively called HyperCow built on Anoma on Ethereum (Resource Plasma) and why we should persue it which includes technical, strategic, and community alignment. This path makes logical sense.

Along the way we will learn things, talk to users, refine our user stories, talk to developers, refine our developer stories, encounter bugs and external attacks both technical and social. We will have successes and failures. Make no mistake, delivering a world class product is not easy, and building a DEX application will be hard too. But we can figure it out.

HyperCow

Background and Why

Most traders are used to orderbooks: Most liquidity historically and by volume, sits in orderbooks – and consequently most traders, their trading systems and strategies are uniquely adapted to the structure and interface of orderbooks. […]
-from Tycho’s orderbook description

Why DEX?

  • Starting with a DEX allows us to test our theories about distributed intent solving and settlement. If we are able to execute this vision in a single domain like Ethereum then scaling the application across multiple domains becomes viable.
  • Heart of any crypto economy requires a DEX. You want payments, swaps, lending/borrowing, staking, leverage and yield along with communication (multi-chat).
  • Inherently adversarial (Alice and Bob both want best prices), testing many features at the same time

Why Spot?

  • Spot trading is the core primitive for all crypto economic activity.
    • Can be easily compossable with other applications (async and synchronously)

Goals

  • External: Provide intent-based trading venue in a familiar orderbook interface to interact with Anoma’s Resource Plasma.
  • Internal: In-house E2E testing of cutting-edge product features of the Anoma software stack.

Highlevel Requirements

  • Intent-based trading mechanism implemented as native Anoma application
  • External solver integration
  • State-of-the-art wallet support
  • Typical orderbook functionality (e.g., chart, orderbook chain, order history)
  • Plasma Operator

Product vision

HyperCow is a decentralized orderbook exchange that will serve as a core infrastructure component for the Anoma ecosystem. Our primary objective is to create a trading platform that demonstrates the practical application of intent-based trading while solving real technical challenges in blockchain interoperability.

To Anoma users, HyperCow will provide a modern compelling trading experience. To solvers, the exchange will yield clear improvements over existing intent-based exchanges, such as optimized fee and reward structures and a best-in-class auction mechanism. To Anoma ecosystem applications, HyperCow will function as a liquidity engine and backbone for other DeFi activities.

All these features are enabled by the underlying Anoma Resource Plasma architecture and the Anoma metastability mechanism on Ethereum mainnet.

Product Features

It’s important to note to the reader that what follows is not complete. The Product Features list needs more thought and further refinement, but should provide a solid foundation to jam with.

Minimal Viable Product Features V1

  • Fast fills (COWs, Ring trades, Market Maker liquidity ~ 250 ms) We’ll need to understand what pre-confirmations look like in our system.
  • Composable with EVM liquidity Integration with DEX aggregator APIs like 0x
  • 7702 onboarding (if possible one signature to Anoma)
  • Variety of order types (market and limit to start)
  • Gas abstraction - can pay in any token solvers will accept
  • Solver accountability (Slow game) (Solver Dashboard)
  • Custom DA and storage for user
  • Embedded Wallet, Session Keys, Pass keys

Minimal Viable Product Features V2

  • Best Fills - EBBO Ethereum Best Bid Offer
  • Natural language Intents
  • Flash liquidity
  • Custom order types (conditional, stop, bracket, etc.)
  • Dark Pools - Shielded Swaps (Binance Midpoint and other methods)+ Private Solving with TEE + MPC
  • Slow game MVP 2 (add slashing commitments)
  • More DA + Storage options

Product requirements

  • Decentralized Orderbook Exchange built as Anoma intent application with Juvix
  • Simple orderbook landing page inspired by Hyperliquid
    • Modern wallet UX (e.g. SDK from Privy/WalletConnect)
    • Chart (e.g. TradingView SDK)
    • Orderbook chain panel
    • Order/intent panel (should have market + limit order types)

Essential Requirements

  • Anoma application written in Juvix
  • Orders are expressed as Anoma intents via Anoma Client/Node

Important Requirements

  • External solver integration
    • Solvers should be able to poll intents
    • Solvers should be able to run Rust code to solve intents
    • Solvers should not be forced to deal with Nockma
  • Modern UI/UX elements
    • Wallet
    • Charting
      • TradingView
      • Airbnb Visx chart library (still partially used by Uniswap)
  • Orderbook chain
  • Trades history

Nice to have Requirements

  • User-specific order history
  • Fee-less transactions
  • Solvers can compose Ethereum intents with HyperCow intents
  • Shielded intents
  • Time limit for orders (like CowSwap implements it)
  • [Maybe not an MVP feature] have simple & advanced mode UI

Other Notes

Timeline

  • Q1 2026 - HyperCow product launch

Go To Market

  • Onboard market makers (necessity to have them for a modern crypto trading application)
  • Routing API available (0x, 1inch, bebop, cowswap)
  • Auction process (-> how do we handle ring trades)
    • Will largely decide over quality of fills
  • Will require audit(s)

User Stories

  • some users will prefer to trade against intent liquidity or Market Maker liquidity and receive pre confirmation in 500ms or less, ideally 250ms, and eventually “real-time” with local solving not constrained by fiber optics and round trips - without waiting for Ethereum blocktimes. Batch auction users may prefer to wait for the ebst price in a batch.
  • some users care about simplicity in a trading platform. Some users like low clutter setups like coinbase, Uniswap front-end, Hyperliquid.
  • some users prefer more advanced functionality, dexscreener, think or swim, coinbase pro style interfaces with charts, order books, and custom order types present
  • some users like coinbase’s toggle switch from regular npc mode to advanced or pro mode. The pro mode has all of the above functionalities. the npc mode makes it very easy for the user to navigate with tons of space and modern design aesthetics where the affordances are apparent. The pro mode will be prefered by “traders” retail and professional types who want more of a spot FX, commodity futures, options, or perpetual futures trading type of experiences (dydx v3 did this very well).
  • some users may prefer a shielded mode toggle switch might be helpful so that they can move back and force betwen shielded and unshielded.
  • users may want the option to express intents in natural language because they enjoy this experience more than pressing buttons to sign things
  • users may want the ability to choose their DA and storage providers on demand? perhaps on a per intent basis so that they can customize their security for the action (trading size in major ETH pairs vs. trading memecoins).

Positioning note

  • positioning as shielded might come back to bight us if users do not understand that they can also trade transparently and that the transparent UX will be best in class. Renegade makes this mistake by advertising privacy so much but then giving you the option to opt out of the dark pool, reveal more information to white listed solvers and participate in the “lit book”. It feels like an after thought though. Penumbra’s UX to date has been challenging as well.
    • In 2025 users are still more comfortable using CEX’s as mixers to fund fresh accounts than trade privately if there is a significant trade-off between quality of execution and time to execution. For example for a simple 100k ETH-USDC swap it takes Renegade 7 minutes to execute this trade.

Open questions and points of interest

Intents

  • computable predicate (resource logics)
  • weighted predicates (preference function)

Operator

  • us (does the operator make the succinct proofs?)
  • third party (astria, espresso, radius, etc.)
  • Operator Selection
    • Total anarchy
    • consensus protocol
    • round robbin
    • centralzied single operator
    • custom something something

Ethereum Solver

  • Router/path finder - does not carry their own inventory
  • Market maker - carries private inventory that users trade against
  • Filler - carries private inventory for cross chain fills of the same assett

Anoma Solver

  • Gossiper - gossips intents around
  • Selector - routes intents to relevant solvers
  • Searcher - finds solutions for intents given constraints + preferences
  • Picker - picks the winning solution
  • Liquidity Provider - provides liquidity to trade against

Note that we have an opportunity to rebrand this however we want and do so exclusively for resource plasma or just use the existing ethereum taxonomy

Liquidity sources for Distributed intent solving

  • Cows
  • ring trades
  • Binance mid point (shielded)
  • market maker (RFQ)/order book
  • On-chain routing (aggregator API / proprietary algorithms)
  • Metastability Mechanism liquidity

Selection Criteria

  • Auction
    • what is the objection function?
    • batch time intervals (12 seconds/less)
    • pre-confirmation times (250ms)
    • type - Dutch, Vickrey, Custom, etc.
    • Threshold Decryption auction
    • who selects the winner? Operator?
    • user-run auctions?

Other integration questions

  • Indexers?
  • Oracles?
  • Wallets (signatures)?
  • Storage Options (long-term)(Arweave, Filecoin, Anoma node)
  • Data Publication options (short-term) (Celestia, Eigen, user, Volition mode, etc.)
  • Ethereum intent standards interoperability (7683, etc.)
  • Donation mechanism (reroute surplus to donation destination XYZ)

Security questions

  • Withdrawal from the Protocol Adaptor
  • Operator goes down (what do)
  • Prover Failure (what do?)
  • Data Availability (pick one)
  • State Validation (Succinct proofs)
  • Forced TX inclusion on main-chain

Order Types

  • Preferences + constraints
    • Market orders (fill at EBBO (Ethereum best bid and offer))
    • Limit orders (fill at specific price or midpoint)
    • stop loss orders
    • Good till cancelled
    • Bracket orders (one cancels the other - take profit + stop)
    • stop loss orders
    • trailing stop loss
    • Immediate or Cancel (Fill or Kill over some time t)
    • All or none (fill the whole order order none of it)
    • Iceberg (Shielded functionality - programmable disclosure)
    • conditional orders (buy ETH for 100 usdc in my account IFF the price stays above 2000 for 4 hours)
    • custom orders (I want to swap 100 USDC for ETH at the binance midpoint but if the fill is better for in stETH or rETH I’ll take that instead).

Future HyperCowFun

  • Fun - give users the ability to request coin creation in a two sided marketplace. Users could create the coins themselves, but also request a coin to be created by a particular identity. Token creation as requested by a community or group of people which takes advantage of the demand side signal not present in kick starter.
    • this feature may not be something we need in our first version of the product. However, it could be a feature which gives us a competitve edge. For example, Cowswap does not have this feature, neither does UniswapX or 1inch for example.

Additional strategic thoughts

  • One problem that arises in privacy preserving DEXes like Renegade or even non-privacy preserving DEXs like Cowswap is that there is a thin order book of two sided intents (buys and sells) for particular assets. As a result most trades in COW are filled with either market maker liquidity or via optimal DEX routes through aggregators or custom solver algorithms. Trades of $100k take 7 minutes to find enough matching liquidity for Renegade. Having some liquidity availble to trade against that is owned by the protocol (Metastability Mechanism) would provide just in time fills to backstop liquidity and offer better prices to users potentially.
  • We should be careful about selling programmable privacy as a feature, most evidence in the marketplace points to this being a bug rather than a feature. In my view we need to have a better user story(ies) around this and have it as a feature but not the main thing we sell, unless our customer stories lead us there
3 Likes

Love the whole article, but this pic :sparkles: all shapes and colors!

1 Like