2026-06-09 · Architecture deep-dive · 6-7 min read

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 user's private key never leaves user-controlled hardware.
  2. The execution path from "user clicks buy" to "tx lands in block" passes through zero third parties who can see, leak, or front-run.
  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 is a passkey-derived Smart Wallet

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)
  ↓ owner EOA of Coinbase Smart Wallet (factory + salt=0)
  ↓ derive smart-wallet address (CREATE2)

Same passkey on the same device deterministically reproduces the same smart-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. For traders arming 50 limit-orders, that's painful. So we ship a "cached-key" mode (default off): after the first passkey-derived secret of a session, cache it in the React app's memory for a user-set TTL (default 1 minute, max 24h). On TTL expiry the cache is wiped from process memory. Off-by-default keeps the secure case secure; opt-in is explicit.

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

Public-RPC providers (Alchemy, QuickNode, Infura) are not adversaries by intent, but they are observers. Their endpoint receives your eth_call (the quote), your eth_getLogs (the watchlist), your eth_sendRawTransaction (the submit). They build their business on aggregating that traffic for analytics. There are documented cases of RPC-side data leakage to favored partners; even the most expensive private plans give 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: every contract is Ownable-honest

Most "decentralized" protocols brag about renounced ownership. In practice, full ownership renunciation means you can't fix bugs, pause hostile flows, or correct oracle drift when ETH/USD goes haywire. We made the opposite choice — and tried to be honest about it.

LOSURIA ships six on-chain contracts:

ContractOwner-ModelVerifiable via
Founders Pass V2Ownable2Step, owner = Treasury Ledgercast call $PASS "owner()(address)"
Token Factory V3Ownable, owner = Treasury Ledgercast call $FAC "owner()(address)"
Treasury Sweeper V1Ownable, owner = Treasury Ledgercast call $SWEEPER "owner()(address)"
LSR AirdropOwnable, owner = Treasury Ledgercast call $AIRDROP "owner()(address)"
Fee Collector LUSDNo ownerowner() revertscast call $FEECOL "owner()(address)" ← will revert
LSR TokenNo ownerowner() revertscast call $LSR "owner()(address)" ← will revert

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

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 (Founders Pass cap, mint price, base URI) is operator-controlled by Ledger. What can the operator do, that affects users?

Sourcify verification covers all six contracts at exact_match status (the strictest grade). One-click lookup from losuria.com/audit. If anything described above doesn't match the bytecode, please file an issue at github.com/LOSURIA/contracts — public since Day 1.

The three constraints, met

ConstraintMechanism
Private key never leaves user-controlled hardwareWebAuthn passkey → PRF → HKDF → smart-wallet owner key. Hardware-bound by browser/OS.
Execution path has zero third-party observersLocal Reth via IPC for quotes; 4-builder private bundle for submit.
Every value-holding contract is byte-verifiableSourcify exact_match on 6 contracts; immutable fee-flow slots; renounce on Pass-sellout.

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. Founders Pass V2 mint open, 500 hard cap, oracle-priced at ~€200 in ETH via Chainlink.

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: github.com/LOSURIA/contracts. PRs welcome.