Infrastructure

How the system is put together: where market data comes from, where prices are computed, what every candidate route has to clear, and how an eligible transaction reaches Solana.

01 — Pipeline

From market event to submitted transaction

Every stage below runs in one process. The path from a market event to a built transaction contains no remote quote call, because the round trip usually takes longer than the opportunity lasts.

Mobula market data Market state Route detection Local pricing Profitability check Risk validation Transaction builder Jito Solana
02 — Market data

Discovery and streaming through Mobula

Mobula is the market intelligence layer. It answers which ZEC markets, pools, pairs and venues exist, and it streams the activity that changes them.

Discovery calls are not latency sensitive and are deliberately kept outside the decision loop. Only the resulting state matters once the engine is running.

Discovery
Identify relevant ZEC markets, pools and execution venues.
Streaming
React to market activity and pool state changes as they happen.
Normalization
Deliver venue data in the single shape the engine evaluates.
Failover
A secondary data path takes over if the primary degrades.
03 — Market state

One in-memory view, updated incrementally

The engine holds pool reserves and venue parameters in memory. A market event updates the affected entries rather than rebuilding the whole view, so evaluating an opportunity never waits on I/O.

Each candidate carries the state version it was priced against. That version is what the freshness check compares before a transaction is built.

04 — Local pricing

Expected output computed in process

Whenever the integrated venue's curve is known, the expected output of a swap is computed locally in Rust, in integer arithmetic, against the reserves currently held in state — including the venue fee and the price impact of the intended size.

Price impact is the term that kills most routes. The size that makes a spread worth taking is the same size that moves the pool against you.
05 — Route detection

Direct and multi-hop paths

The engine evaluates closed paths that start and end in ZEC, so the position is opened and closed inside a single transaction and nothing is held between legs.

ZEC → USDC → ZEC
Two legs through a stable intermediate. The shortest useful path.
ZEC → SOL → ZEC
Two legs through a volatile intermediate, which is itself a cost to price.
ZEC → USDC → SOL → ZEC
Three legs. Reaches venues a direct path cannot, at the cost of another fee term.
Availability
A path is evaluated, never assumed. Most are rejected before any transaction exists.
06 — Profitability

A spread is not a profit

A visible price difference becomes an opportunity only after every execution cost is subtracted from it. The result is compared against a configured minimum, not against zero.

Final ZEC+
− Initial ZEC−
− DEX fees−
− Price impact−
− Priority fee−
− Jito tip−
− Safety buffer−
= Expected net profitevaluated per route

Clearing the threshold makes a route an execution candidate. It is not a guarantee of execution, and it is not a guarantee of profit.

07 — Risk controls

Applied before a transaction is built

Minimum profit
Reject routes below the configured minimum expected profit.
Slippage floor
Define the minimum acceptable output for each execution path.
Stale state
Reject opportunities priced against state that is no longer valid.
Position limit
Cap the capital allocated to an individual execution.
Fee ceiling
Reject trades when execution costs exceed configured limits.
Simulation
Validate before submission where the latency budget permits it.
08 — Execution

Built protected, submitted through Jito

The builder constructs the swap instructions for every leg of the route and attaches the minimum-output constraint, so the position cannot settle at a worse price than the one that justified it.

Where the transaction structure allows, dependent legs succeed together rather than leaving the strategy exposed to one side of the trade. Submission is not inclusion, and inclusion is never assumed.

Atomicity matters more than raw speed without protection. A fast unprotected fill is a worse outcome than a missed opportunity.
09 — Distribution

Profits distributed in 5-minute rounds

Realized results are settled in rounds of five minutes and distributed to holders. A round accounts only for transactions confirmed on-chain within it; submitted transactions that never land contribute nothing.

Rounds that close without a confirmed profitable execution distribute nothing. There is no fixed rate and no guaranteed return.

10 — Observability

Fields tracked by the engine

Metrics and structured logs are emitted for every decision, including the ones that end in a rejection — the rejected set is where a cost model is debugged.

Detected opportunities
Rejected opportunities
Submitted transactions
Confirmed transactions
Failed transactions
Average decision latency
Estimated edge
Realized PnL
Priority fees
Jito tips
RPC errors
Market data lag
11 — Security

Trading infrastructure stays private

✓No private keys in frontend code.
✓No signing secrets in public environment variables.
✓Website infrastructure separated from trading infrastructure.
✓Dedicated execution wallets with controlled balances.
✓API credentials kept server-side.
✓Kill switches and exposure limits.
✓Transaction decisions logged without secret material.

This site is a static deployment. It reads nothing, signs nothing and submits nothing.