Inside LOSURIA: local Reth, a four-builder bundle, and a passkey wallet — the three decisions that define non-custodial sniping

The problem

Server-side MEV sniping bots get to where they are by trading correctness for trust. The protocol holds your funds. The protocol holds your private keys. The protocol sees every quote, every armed limit-order, every block-N target. When the protocol is honest, you get sub-block execution. When the protocol leaks your arming signal to a builder it has a side-deal with, you become the exit liquidity.

A non-custodial design has to solve this without the trust-shortcut. That means three things have to be true at once:

1. The wallet owner key never leaves user-controlled hardware; the opt-in first-block mode uses a capped session key (Terms §4a).
2. On Ethereum the execution path from "user clicks buy" to "tx lands in block" passes through no third party who can see, leak, or front-run it. On Base, Solana, Monad and Bitcoin the RPC endpoint you supply is in that path.
3. Every contract that holds value is verifiable byte-for-byte against published source.

LOSURIA is one implementation of those three constraints. This post explains the architectural choices.

Decision 1: the wallet key is derived from a passkey

The standard Web3 self-custody UX is "back up your seed phrase." Seed-phrase loss accounts for the majority of self-custody failures. Worse, seed phrases are by definition extractable — if you can write them down, they can be photographed, leaked, or coerced.

A WebAuthn passkey lives in your device's secure enclave (Apple Secure Enclave, Android Keystore, YubiKey). It cannot be extracted in plaintext. You cannot back it up as a string. The browser exposes a signing primitive, not the key itself.

The mechanism:

WebAuthn passkey
  ↓ user gesture (Face ID / Touch ID / YubiKey touch)
  ↓ PRF extension challenge-response → 256-bit secret
  ↓ HKDF-SHA256(salt=domain-pin, info="losuria-eoa-v1")
  ↓ secp256k1 private key (deterministic from passkey)
  ↓ your wallet address — the same one on every EVM chain

Same passkey on the same device deterministically reproduces the same wallet address. Different device, different passkey → different sub-account (you register multiple).

The library is webauthn-rs v0.5 server-side; the PRF extension is available in Safari 17+, Chrome 116+, and 1Password 8+. We tested on iOS PWA standalone (the hardest case — Safari on iOS in "Add to Home Screen" mode), and the PRF path holds through Face ID prompts during a signing flow.

Trade-off: every signature requires a user gesture, and today there is no way around it — a wallet action means a passkey prompt, every time. For traders arming many orders at once that is real friction, and an opt-in cached-key mode is on the roadmap rather than in the build. Until it ships, the honest description is the strict one: no derived secret outlives the signing operation that needed it.

Decision 2: the execution path runs on a local Reth node + 4-builder bundle

Any shared public RPC is not an adversary by intent, but it is an observer. Its endpoint receives your eth_call (the quote), your eth_getLogs (the watchlist), your eth_sendRawTransaction (the submit) before the chain does. That traffic is, by construction, visible to the provider. Even the most expensive private plans give you contractual non-leakage guarantees, not cryptographic ones.

In a sniper hot path, "contractual non-leakage" is not enough. We need to eliminate the read-side observer entirely.

Architecture:

React PWA
   ↓ HTTPS over Caddy (TLS pinned)
   ↓
Rust backend (axum + tokio)
   ↓ IPC (Unix domain socket)
   ↓
Reth node (local, same VPS)
   ↓ devp2p
   ↓
Ethereum mainnet

Quote-and-sign: the React PWA fetches quotes over HTTPS from the backend. The backend issues eth_calls to its local Reth node over IPC. The IPC traffic never crosses the network. Reth talks devp2p to peers, but no quote-request ever reaches a third-party endpoint.

Submit: the user signs locally on their device. The signed raw transaction goes back to the backend, which submits via a private bundle to four blockbuilders simultaneously: Flashbots, Beaverbuild, Titan, and Lightspeed. No public mempool. Whichever builder includes the bundle first lands the tx; the others drop it.

The 4-builder setup gives us bundle redundancy plus implicit price-discovery — if one builder is reorg-targeted or rate-limited, three others carry the bundle. The probability of all four failing simultaneously on the same block is negligible.

Decision 3: the trust model is on-chain, not on our word

Three contracts are Ownable to the Operator Treasury (a Ledger hardware wallet). The fee-flow contracts have no owner at all. The table below states exactly which is which, and every line is verifiable by a single cast call.

The contracts below carry the trust model. They are a subset of what is deployed — the verify page lists every address:

The fee-flow path has no admin key at all. The Fee Collector's TREASURY, STABLE (DAI), WETH, and UNIV3_ROUTER are immutable constructor-set slots — verified on-chain to be the Operator Treasury, DAI, canonical WETH, and Uniswap V3 SwapRouter02 respectively. A compromised operator key cannot:

• redirect fees to another address
• swap DAI out for another stablecoin
• route swaps through a malicious DEX router

The LSR token is fixed supply, no mint() function exists. The supply cap is enforced by the absence of any mint path post-deployment.

The configuration path (subscription price) is operator-controlled by Ledger. What can the operator do, that affects users?

• Adjust the per-tier subscription price within a 50%-200% corridor of the initial price (Chainlink-ETH/USD oracle-priced). It never touches an already-paid 30-day period.

Sourcify verification covers every deployed contract at exact_match status — the strictest grade — with one exception named on the verify page: the Monad launchpad factory, which is deployed but not yet source-verified. One-click lookup from losuria.com/audit. If anything described above doesn't match the bytecode, the security contact on losuria.com/audit reaches us directly.

The three constraints, met

This is one implementation. There will be others. The space needs them. The MEV-sniper category should not be a custodial monopoly.

If you want to use it: losuria.com. Access is an on-chain subscription (LosuriaSubscription): two tiers, priced in EUR and paid in DAI (settled to DAI) per 30-day period, non-custodial, cancel anytime.

If you want to read the code first: losuria.com/audit → click any contract → Sourcify → read the Solidity.

If you want to argue with the architectural choices, the verified bytecode is the thing to argue with: every deployed contract is readable on Sourcify via losuria.com/audit, and the security contact there reaches us directly.