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:
- The user's private key never leaves user-controlled hardware.
- The execution path from "user clicks buy" to "tx lands in block" passes through zero third parties who can see, leak, or front-run.
- 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:
| Contract | Owner-Model | Verifiable via |
|---|---|---|
| Founders Pass V2 | Ownable2Step, owner = Treasury Ledger | cast call $PASS "owner()(address)" |
| Token Factory V3 | Ownable, owner = Treasury Ledger | cast call $FAC "owner()(address)" |
| Treasury Sweeper V1 | Ownable, owner = Treasury Ledger | cast call $SWEEPER "owner()(address)" |
| LSR Airdrop | Ownable, owner = Treasury Ledger | cast call $AIRDROP "owner()(address)" |
| Fee Collector LUSD | No owner — owner() reverts | cast call $FEECOL "owner()(address)" ← will revert |
| LSR Token | No owner — owner() reverts | cast 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:
- redirect fees to another address
- swap LUSD out for USDC (Circle's freeze-power was the explicit reason we picked LUSD)
- 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 (Founders Pass cap, mint price, base URI) is operator-controlled by Ledger. What can the operator do, that affects users?
- Raise Pass
phaseCapfrom 500 → up toMAX_TOTAL_CAP=1500. Operator-committed cap is 500. After the 500th mint, werenounceOwnership()to lock the cap technically (the tx will be on chain that week). - Adjust mint price within 50%-200% corridor of the initial $216 (Chainlink-ETH/USD oracle-priced).
- Update Pass metadata URI.
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
| Constraint | Mechanism |
|---|---|
| Private key never leaves user-controlled hardware | WebAuthn passkey → PRF → HKDF → smart-wallet owner key. Hardware-bound by browser/OS. |
| Execution path has zero third-party observers | Local Reth via IPC for quotes; 4-builder private bundle for submit. |
| Every value-holding contract is byte-verifiable | Sourcify 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.