C++, Rust, and Decentralized Crypto Exchanges: Applicability and Efficiency

Contents

• Introduction
• The first mistake: treating a DEX as one thing
• Where C++ fits naturally
• Where Rust fits naturally
• What changes between AMMs and order-book DEXs
• Economics, latency, and where performance actually pays
• Latency, throughput, safety, and operational cost
• Three practical architecture patterns
• What AI-assisted engineering changes
• My practical recommendation
• Examples and counterexamples by DEX layer
• A practical architecture thought experiment
• Hands-On Lab: Build a tiny AMM route evaluator
• Test Tasks for Enthusiasts
• Summary
• References

Introduction

Hello friends!

When engineers argue about C++ versus Rust in the context of decentralized exchanges, they often start from the wrong premise.

A decentralized exchange is not one program.

A real DEX is a stack:

• smart contracts or on-chain programs
• validators or blockchain nodes
• mempool or block-building logic
• market data ingestion
• indexers
• matching engines or AMM pricing paths
• liquidation engines
• searchers and arbitrage bots
• front ends
• observability, risk controls, and operations

Once you understand that, the language debate becomes much more productive.

The correct question is not:

"Should we build a DEX in C++ or in Rust?"

The correct question is:

"Which layers of a DEX benefit more from C++, which layers benefit more from Rust, and where does each language pay for itself?"

My short answer is this:

• Rust is often a very strong choice for modern blockchain-native development, especially on chains and frameworks where Rust is already the first-class path.
• C++ remains extremely strong for latency-sensitive off-chain infrastructure, searcher systems, market-data paths, simulation engines, and any component where raw systems control still dominates the tradeoff.

And in many serious systems, the right answer is not "pick one". The right answer is hybrid architecture.

There is a reason for this that goes beyond mere compromise. Decentralized exchanges are not philosophically mixed systems; they are materially mixed systems. Some parts live where correctness under adversarial conditions dominates every other consideration. Other parts live where a few milliseconds, or a few hundred microseconds, may change whether an opportunity is captured at all. Still other parts are really bookkeeping, indexing, and operator convenience by another name.

Once one sees that clearly, the language debate becomes less ideological and more architectural.

The first mistake: treating a DEX as one thing

Before choosing a language, define which DEX you are actually building.

There are at least three broad categories:

1. EVM-style AMM-centric exchanges

Examples in the public literature include designs such as Uniswap v3, where the on-chain logic is concentrated in smart contracts and the market behavior is dominated by liquidity math, routing, slippage, and MEV dynamics rather than a traditional low-latency central matcher.

In such systems, the core on-chain language is often Solidity, not C++ or Rust. That means C++ and Rust usually show up in supporting systems:

• routing engines
• simulators
• searchers
• quoting services
• analytics
• risk tools

2. Solana-style program ecosystems

Solana's own documentation is explicit: programs are primarily developed in Rust. The ecosystem around Anchor reinforces this strongly, because Anchor is the dominant framework for building secure Solana programs and production-ready developer workflows.

In this world, Rust is not just an option. It is often the native path for on-chain logic.

3. App-chain or order-book-centric decentralized trading systems

dYdX Chain is a good public example of a more ambitious architecture. Its official documentation describes an open-source application-specific blockchain powering a decentralized perpetuals exchange with a decentralized order-book and matching engine.

That matters because once you leave pure AMM territory and move toward order books, matching, and streaming market-data semantics, your system starts looking more like traditional exchange infrastructure. That often reopens the door for C++ in surrounding components even when the chain or validator logic itself is implemented elsewhere.

So before any language argument, decide whether you are mostly building:

• on-chain AMM logic
• Solana-native programs
• off-chain searcher infrastructure
• market-data and execution bots
• an app-chain matching stack
• or a mixed system spanning all of the above

Where C++ fits naturally

Now let us talk about the places where C++ remains an extremely strong choice.

1. Market data ingestion and normalization

DEX-adjacent systems increasingly consume:

• node streams
• WebSocket feeds
• indexer outputs
• oracle updates
• mempool events
• cross-venue prices

These paths are often sensitive to:

• allocation rate
• serialization overhead
• thread scheduling
• binary protocol parsing
• cache locality

C++ is excellent here because it lets engineers build high-throughput parsers and normalization pipelines with tight control over memory layout and CPU behavior.

2. Searchers, routing engines, and simulators

MEV and DEX execution are fundamentally optimization problems under time pressure.

Ethereum's public MEV documentation explains how opportunities such as DEX arbitrage, liquidations, and sandwich trading arise from transaction ordering and price movement. To exploit or defend against these dynamics, teams build:

• mempool listeners
• state simulators
• route finders
• pricing engines
• bundle builders
• opportunity scorers

These systems often benefit from C++ when:

• the search space is large
• latency matters
• repeated simulation dominates runtime
• memory reuse matters
• integration with existing HFT-style infrastructure is desirable

3. Order-book and matching-related off-chain services

Even in decentralized systems, not everything meaningful happens on-chain.

Many production-grade exchange stacks still include off-chain or semi-off-chain components for:

• market-data fanout
• pre-trade checks
• quote aggregation
• position caching
• risk computation
• liquidation scheduling
• latency-sensitive strategy logic

These are classic C++ territories.

4. High-performance cryptographic and systems plumbing

A lot of DEX engineering is not "blockchain logic" in the abstract. It is systems work:

• networking
• encoding and decoding
• persistence
• signatures
• batching
• compression
• concurrency

C++ remains highly competitive when those layers dominate the cost profile.

Why C++ still wins these jobs

Because these jobs reward:

• control over allocation
• deterministic performance tuning
• mature profiling tools
• proximity to existing low-level libraries
• long-standing literature on throughput and latency engineering

That is why, even in very modern crypto stacks, C++ often survives or returns in the most performance-sensitive subsystems.

Where Rust fits naturally

Rust has a different but equally important set of strengths.

1. Solana-native and Rust-first blockchain environments

This is the clearest case.

Solana's official docs state that programs are primarily developed in Rust. The docs also describe native Rust development as a path for direct control over program logic and optimizations, while Anchor adds higher-level ergonomics and security-oriented structure.

If your product strategy is fundamentally tied to Solana program development, Rust is usually the sensible default.

2. Framework-assisted smart contract development

Anchor is important here because it changes the developer experience materially.

Its official documentation positions it as a framework for building secure Solana programs and production-ready applications faster. That matters because a language becomes much more attractive when the ecosystem around it reduces boilerplate, increases safety, and standardizes workflows.

3. Greenfield services where safety and maintainability dominate

Rust can be a very good fit for:

• new indexers
• gateway services
• transaction builders
• chain-integrated daemons
• data pipelines
• control-plane software

especially when the team values memory safety and long-term maintainability more than shaving every last microsecond off hot loops.

4. Blockchain ecosystems that are already Rust-shaped

The more your surrounding stack already assumes:

• Cargo
• Rust crates
• Rust SDKs
• Rust examples
• Rust-native tooling

the stronger Rust becomes. Language choice is never made in a vacuum.

Why Rust wins these jobs

Rust often pays for itself when:

• the project is greenfield
• safety bugs are costly
• correctness and auditability are central
• the ecosystem already expects Rust
• the most expensive failures are reliability failures, not tiny latency losses

In those conditions, Rust can absolutely be the right answer.

What changes between AMMs and order-book DEXs

This distinction is central.

AMM-heavy systems

In AMM-centric designs such as Uniswap v3, the main difficulties are often:

• on-chain math
• pool state transitions
• routing across pools
• slippage management
• MEV exposure
• indexing and analytics

For these systems, C++ usually appears more in off-chain routing, simulation, and bot infrastructure than in the core protocol itself.

Order-book or hybrid systems

Once your architecture includes:

• order placement semantics
• price-time priority
• order-book streaming
• matching behavior
• liquidation coordination
• high-rate incremental state updates

the performance and systems-engineering requirements start to resemble traditional exchange software much more closely.

This is where C++ becomes especially attractive for supporting infrastructure, and sometimes for core components when the platform allows it.

The deeper truth

AMM systems are usually more "smart contract and routing" heavy. Order-book systems are usually more "market-data and matching" heavy.

The more your DEX starts looking like an exchange engine rather than a pure on-chain math primitive, the stronger the C++ argument becomes.

Economics, latency, and where performance actually pays

Language debates often become confused because they use the word performance too loosely.

A DEX can be "slow" in several very different senses:

• slow at confirming state
• slow at surfacing state to off-chain consumers
• slow at simulating opportunities
• slow at routing
• slow at risk evaluation
• slow at transaction construction

These are not the same bottleneck, and they are not improved by the same kind of code.

Where C++ often pays for itself

C++ tends to pay for itself where the business value of improvement is close to the machine:

• opportunity search
• multi-venue normalization
• route simulation
• execution gateways
• pricing under tight time budgets

In these layers, even moderate latency reductions can compound because they occur inside loops that run constantly.

Where Rust often pays for itself

Rust tends to pay for itself where the business value of improvement is closer to correctness and long-term operational confidence:

• chain-native programs
• safety-sensitive state transitions
• protocol-facing services
• auditable greenfield infrastructure

In those layers, the expensive failures are often logical or operational rather than purely temporal.

A useful counterpoint

This does not mean C++ is only about speed and Rust is only about safety. That would be a cartoon. The deeper point is that language choice should follow the dominant economic pressure of the layer:

• if the layer wins or loses on latency and throughput, C++ becomes more attractive
• if the layer wins or loses on correctness and maintainability, Rust becomes more attractive

That single distinction clears away a surprising amount of confusion.

On-chain determinism, auditability, and language choice

Now let us look at the opposite side of the stack.

When code runs on-chain or in chain-defining logic, the evaluation criteria change. Raw speed is still important, but the most painful failures are often:

• safety bugs
• logic bugs
• account-handling mistakes
• invalid state transitions
• upgrade hazards
• auditing complexity

This is where Rust often earns its place.

Why Rust feels natural in blockchain-native environments

Rust's value in these environments is not just that it is "safe". It is that it makes many forms of stateful systems programming more explicit:

• ownership is visible
• mutation is visible
• error handling is structured
• project layout is disciplined

When a framework such as Anchor sits on top of that, the team also benefits from conventions around:

• account validation
• IDL generation
• testing workflows
• deployment ergonomics

That ecosystem effect is powerful. In chain-native development, the right language is often the one that reduces protocol bugs and audit friction, not the one that wins a microbenchmark in isolation.

Why C++ is less natural for most on-chain protocol teams

C++ can obviously express the logic. The issue is not theoretical capability. The issue is ecosystem fit.

If the chain, toolchain, framework, auditors, and example repositories are already Rust-shaped, then choosing C++ for core protocol logic usually means fighting the ecosystem instead of leveraging it.

That is why I would not recommend forcing C++ into on-chain layers that are already solidly Rust-native.

Latency, throughput, safety, and operational cost

Let us compare the languages across the dimensions that actually matter.

Latency

For ultra-low-latency off-chain services, C++ still has a very strong case because:

• memory layout control is excellent
• mature profiling culture exists
• integration with native libraries is straightforward
• teams can tune allocation, threading, and cache behavior aggressively

Rust can also be fast, but in practice many high-performance crypto teams still find more ready-made patterns, libraries, and institutional knowledge in C++.

Throughput

Both languages can deliver high throughput.

The deciding factors are usually not the syntax. They are:

• library quality
• serialization strategy
• batching model
• threading design
• allocator behavior
• data layout

That said, C++ still has an advantage in some extreme throughput-oriented ecosystems simply because there is more historical code and more performance literature around these kinds of systems.

Safety

Rust clearly wins the language-level safety story.

This matters a lot when:

• you are handling critical wallet or transaction logic
• reliability is more valuable than tiny latency gains
• the team is greenfield and wants strong ownership discipline
• audit pressure is intense

Operational cost

This dimension is more nuanced.

Rust can lower some maintenance costs through stronger correctness constraints.

C++ can lower some integration and tuning costs when the existing infrastructure, performance tooling, and system libraries are already native and battle-tested.

So operational cost depends heavily on whether your organization is already a Rust shop or already a C++ shop.

Settlement speed is not the same as execution-path speed

This distinction is crucial in decentralized trading discussions.

Many architecture debates collapse different types of "performance" into one word. But there are at least two very different things happening:

1. Execution-path speed

How fast can your off-chain systems:

• ingest data
• simulate state
• price opportunities
• build transactions
• route and submit actions

This is where C++ often shines.

2. Settlement and protocol-level speed

How fast does the chain itself:

• accept transactions
• order them
• finalize them
• expose resulting state

This is often influenced much more by the blockchain design than by your off-chain implementation language.

Why the distinction matters

A team can build a beautiful ultra-low-latency C++ searcher and still be constrained by:

• mempool visibility
• block times
• validator behavior
• builder markets
• finality properties

Likewise, a team can build on a Rust-native chain and still lose performance if the off-chain services feeding it are slow, allocation-heavy, or poorly profiled.

So the honest architecture conversation should always ask:

• Which part of the latency do we control with language choice?
• Which part belongs to the protocol and network environment?

This prevents a lot of confused arguments.

Three practical architecture patterns

Here are three patterns that I believe are genuinely useful.

Pattern 1: Solidity or chain-native on-chain core, C++ off-chain performance layer

Use this when:

• protocol logic lives on-chain
• routing, pricing, or simulation is heavy
• MEV/searcher infrastructure matters
• latency-sensitive strategy code exists

This is a very realistic design for EVM ecosystems.

Pattern 2: Rust on-chain programs, Rust control plane, C++ hot-path engines

Use this when:

• the ecosystem is Solana or otherwise Rust-shaped
• on-chain logic clearly belongs in Rust
• some subsystems still demand aggressive latency tuning
• your team wants memory safety for most of the stack but not at the cost of hot-path performance

This hybrid architecture often gives a strong balance of safety and speed.

Pattern 3: Mostly Rust for product velocity, C++ only where the profiler demands it

Use this when:

• the team is Rust-native
• the product is greenfield
• performance assumptions are still uncertain
• you are willing to introduce C++ later only for proven hotspots

This is often the least emotionally satisfying pattern and the most economically sensible one.

Team skill, hiring, and maintenance reality

One more section is worth adding because language debates often pretend organizations are abstract machines. They are not. They are teams with uneven experience, hiring constraints, and production obligations.

C++ teams often win when

• the company already has strong low-level talent
• performance work is part of the culture
• the stack already includes native libraries
• profiling and benchmarking discipline are mature

Rust teams often win when

• the team is building mostly greenfield components
• the organization values stronger correctness defaults
• the chain ecosystem is already Rust-first
• maintainability risk is a bigger fear than raw latency loss

Mixed teams should be realistic

If nobody on the team is truly comfortable with low-level C++, then forcing C++ into every component can be as costly as forcing Rust into latency-sensitive paths that really want native performance tuning.

The winning architecture is usually the one that matches both the system shape and the team's real competence, not the architecture that wins the loudest internet debate.

What AI-assisted engineering changes

Since we are in the AI era, we should say this explicitly:

AI coding agents change the economics of both languages.

Where C++ benefits

For off-chain exchange infrastructure, C++ benefits from:

• larger public code corpus
• deeper networking and performance examples
• more public optimization patterns
• richer interop history with native libraries

This makes it easier for agents to generate code that at least looks familiar to existing production systems.

Where Rust benefits

Rust benefits from:

• strong compiler diagnostics
• disciplined project structure
• ergonomic package management
• good signal when ownership or lifetime assumptions are wrong

This can help agents converge faster on correct code in some greenfield services.

My practical conclusion

For DEX-adjacent hot paths, C++ often gets the edge because the surrounding performance ecosystem is so mature.

For chain-native program development and safety-oriented service layers, Rust can be the better ergonomic choice.

In other words, AI does not eliminate the tradeoff. It just makes the tradeoff more visible.

Security boundaries and failure domains

One more distinction matters a lot in DEX architecture: where failure is allowed to happen.

Some components can fail "softly":

• analytics jobs
• dashboards
• reporting pipelines

Other components fail "hardly":

• on-chain state transitions
• transaction construction
• liquidation execution
• order routing under volatile conditions

Rust earns trust in hard state-transition layers

Where the system manipulates protocol-critical state and mistakes are expensive, Rust's explicitness can be a major advantage. Teams often find it easier to reason about ownership, mutation, and error propagation when correctness is under the microscope.

This is especially relevant in code that will be:

• audited
• reviewed by protocol engineers
• maintained across upgrades
• exposed to adversarial conditions

C++ earns trust in hard latency layers

Conversely, there are failure domains where the biggest risk is not a memory bug but missing a timing window, overloading a path, or producing unstable latency under burst conditions.

That is where C++ often feels more natural:

• state simulation
• search loops
• route evaluation
• cross-venue market-data normalization
• high-rate execution gateways

The best DEX architecture separates these failure domains instead of pretending one language solves them all equally well.

My practical recommendation

If you forced me to recommend a language strategy for a serious decentralized exchange project today, I would say:

1. Use the language the chain expects for on-chain logic.
2. Use C++ for latency-critical off-chain systems when profiling and throughput genuinely matter.
3. Use Rust for greenfield services and chain-native components where safety and maintainability dominate.
4. Do not be ideological about one-language purity.

The most expensive mistake in crypto systems is often not "we used two languages."

The most expensive mistake is "we forced one language into layers where it was not the natural tool."

That is especially true for DEXs, because they are not monoliths. They are distributed systems with very different failure modes and performance profiles across their layers.

Examples and counterexamples by DEX layer

This is usually the section that makes the architecture discussion feel real.

Example 1: a Solana-native protocol team

Suppose a team is building:

• Solana programs
• account-validation logic
• instruction handlers
• Anchor-based tests and deployment flows

In that world, Rust is the natural choice for the protocol layer. The ecosystem, examples, and toolchain are already aligned around it.

Counterexample 1: forcing C++ into a Rust-native on-chain workflow

Could someone theoretically express the logic in another language? Maybe. But in practice this usually creates more friction than value:

• fewer ecosystem examples
• weaker framework alignment
• more custom tooling burden
• worse fit with audit and team workflows

This is a clean example of where C++ is not the hero language.

Example 2: an EVM searcher or routing engine

Now switch contexts completely.

Suppose the team is building an off-chain system that:

• consumes mempool data
• simulates pool states
• explores arbitrage routes
• computes profitability under gas and slippage
• submits transactions quickly

That is a very strong fit for C++. The work is latency-sensitive, simulation-heavy, and much closer to exchange engineering than to smart-contract ergonomics.

Counterexample 2: building that hot path like an ordinary service

If the searcher is implemented with:

• heavy allocation
• convenience abstractions everywhere
• slow serialization
• little profiling discipline

then the team may lose the timing battle before strategy quality even matters.

Example 3: a hybrid architecture that respects both worlds

A very realistic and often excellent design looks like this:

• Rust for chain-native logic and safety-sensitive services
• C++ for market-data, simulation, routing, and hot-path execution tooling

This is not philosophically pure, but it often maps better to the actual shape of DEX infrastructure.

Counterexample 3: one-language purity as an ideology

Teams sometimes insist that one language must own every layer because consistency feels elegant.

That can backfire:

• forcing Rust into every hot path can increase interop and tuning cost
• forcing C++ into every chain-native layer can fight the ecosystem and audit flow

The prettiest architecture diagram is not always the cheapest architecture to run.

The practical lesson

When someone says "Rust is better for DEXs" or "C++ is better for DEXs," the first response should be:

For which layer?

That one question improves the whole conversation.

A practical architecture thought experiment

Let us imagine a team building a decentralized perpetuals platform with the following components:

• on-chain state logic
• liquidation logic
• market-data collectors
• a route and pricing engine
• an internal simulation service
• operator dashboards

Now ask, one by one, what each piece is punished for.

On-chain state logic

If this layer is wrong, the failure is expensive, public, and difficult to undo. The pain comes from correctness failures more than from shaving tiny latency margins. This is where a Rust-first chain ecosystem can be very compelling.

Market-data collectors

If this layer is slow, stale, or allocation-heavy, every downstream component becomes dumber. This is where C++ starts looking attractive because the cost is near the wire and repeats endlessly.

Pricing and route simulation

This layer usually lives or dies by repeated computation under time pressure. Again, that is a natural C++ zone.

Operator dashboards

This layer may be operationally important, but it is rarely the place to spend your most expensive low-level engineering talent.

The lesson

The point of this thought experiment is not that the answer will always be hybrid. The point is that if you inspect the failure modes honestly, the architecture often stops looking like a single-language identity statement and starts looking like a carefully partitioned system.

Hands-On Lab: Build a tiny AMM route evaluator

Let us build something small enough to understand and real enough to touch.

The goal is not to recreate Uniswap. The goal is to feel how quickly DEX work becomes a matter of repeated simulation and comparison.

main.cpp

#include <cmath>
#include <iomanip>
#include <iostream>
#include <string>
#include <vector>

struct Pool {
    std::string name;
    double reserve_in;
    double reserve_out;
    double fee; // 0.003 for 0.3%
};

double swap_out(const Pool& p, double amount_in) {
    const double effective_in = amount_in * (1.0 - p.fee);
    return (effective_in * p.reserve_out) / (p.reserve_in + effective_in);
}

double two_hop(const Pool& a, const Pool& b, double amount_in) {
    const double mid = swap_out(a, amount_in);
    return swap_out(b, mid);
}

int main() {
    Pool eth_usdc_a{"ETH/USDC pool A", 500.0, 1750000.0, 0.003};
    Pool eth_usdc_b{"ETH/USDC pool B", 650.0, 2262000.0, 0.0005};
    Pool usdc_dai{"USDC/DAI stable pool", 900000.0, 901200.0, 0.0001};

    const double trade_eth = 4.0;

    const double direct_a = swap_out(eth_usdc_a, trade_eth);
    const double direct_b = swap_out(eth_usdc_b, trade_eth);
    const double routed = two_hop(eth_usdc_b, usdc_dai, trade_eth);

    std::cout << std::fixed << std::setprecision(4);
    std::cout << "Input: " << trade_eth << " ETH\n";
    std::cout << "Direct via " << eth_usdc_a.name << ": " << direct_a << " USDC\n";
    std::cout << "Direct via " << eth_usdc_b.name << ": " << direct_b << " USDC\n";
    std::cout << "Two-hop via " << eth_usdc_b.name << " -> " << usdc_dai.name
              << ": " << routed << " DAI\n";

    if (direct_b > direct_a) {
        std::cout << "Best direct route: " << eth_usdc_b.name << "\n";
    } else {
        std::cout << "Best direct route: " << eth_usdc_a.name << "\n";
    }
}

Build

On Linux or macOS:

g++ -O2 -std=c++20 -o amm_router main.cpp
./amm_router

On Windows:

cl /O2 /std:c++20 main.cpp
.\main.exe

Why this matters

Even this tiny program already hints at the real shape of off-chain DEX work:

• repeated path evaluation
• fee-aware comparison
• state-dependent output
• constant tension between correctness and speed

Scale this up to hundreds of pools, frequent state updates, and adversarial timing pressure, and you begin to see why language choice stops being abstract very quickly.

Test Tasks for Enthusiasts

1. Add slippage tolerance and reject routes whose effective output falls below a configured threshold.
2. Extend the program to compare five or ten pools instead of two and profile where the time goes.
3. Add a loop that re-evaluates the route one million times with slightly changing reserves and measure how a "toy" router starts to resemble a real hot path.
4. Replace floating-point output formatting with structured numeric logging and observe how much "non-math" work appears around the actual route logic.
5. Add a second version in Rust or another language and compare not only raw runtime, but also how comfortable the language feels once the simulation loop becomes the center of the work.

This is a good exercise because it reveals something subtle: in exchange software, the interesting difficulty often lies not in a single formula, but in the repeated, stateful, latency-sensitive use of many ordinary formulas at once.

Summary

C++ and Rust are both useful in decentralized exchange engineering, but they win in different places.

Rust is a first-class citizen in ecosystems such as Solana and is excellent for chain-native development, framework-assisted smart contracts, and many new services where safety is a dominant concern.

C++ remains exceptionally strong for off-chain infrastructure that behaves like exchange engineering rather than like application scripting: market-data ingestion, routing, simulation, searcher infrastructure, matching-adjacent services, and ultra-low-latency execution paths.

So the right question is not "C++ or Rust?" The right question is "Which layer are we designing?"

Once you answer that honestly, the architecture usually becomes much clearer.

References

1. Uniswap v3 whitepaper: https://uniswap.org/whitepaper-v3.pdf
2. Uniswap v3 core repository: https://github.com/Uniswap/v3-core
3. Ethereum.org MEV documentation: https://ethereum.org/developers/docs/mev/
4. Solana programs overview: https://solana.com/docs/core/programs
5. Solana Rust program development: https://solana.com/docs/programs/rust
6. Anchor documentation: https://www.anchor-lang.com/docs
7. dYdX Chain documentation: https://docs.dydx.exchange/
8. dYdX integration documentation: https://docs.dydx.xyz/
9. dYdX on off-chain order books with on-chain settlement: https://integral.dydx.exchange/dydx-closes-10m-series-b-investment/
10. Cosmos SDK documentation: https://docs.cosmos.network/