Overview
The YoorQuezt mesh network is a decentralized P2P relay layer that privately routes transactions from users to block builders. Nodes communicate over QUIC with encrypted gossip, ensuring transactions never touch the public mempool.
Why Run a Node
- Earn relay fees — Nodes earn a share of protocol revenue proportional to the traffic they relay
- Lower latency — Nodes closer to block builders reduce inclusion time for your transactions
- Strengthen the network — More nodes means better censorship resistance and redundancy
- Multi-chain coverage — Each node can subscribe to multiple chains, increasing network reach
- Reputation rewards — High-reputation nodes receive priority routing and higher fee shares
Protocol Stack
QUIC + TLS Transport
All peer-to-peer communication runs over QUIC with mutual TLS authentication. Each node generates an ECDSA P-256 keypair and self-signed certificate during yqmesh init.
- Connection multiplexing — Multiple streams over a single QUIC connection
- 0-RTT handshake — Returning peers reconnect instantly
- NAT traversal — QUIC's UDP transport works through most firewalls
Gossip Protocol
Messages propagate through the network via batched gossip:
- Receive — Node receives a transaction, bundle, or block message
- Deduplicate — Check the bloom filter (100K capacity, 0.1% FP rate). Drop if seen.
- Validate — Verify ECDSA signature, decompress (zstd), decrypt (AES-256-GCM)
- Process — Add to local mempool, trigger block building if applicable
- Batch — Accumulate messages for up to 100ms or 64 messages (whichever comes first)
- Propagate — Compress, encrypt, sign, and send the batch to all connected peers
Reputation System
Each peer maintains a reputation score for every connected peer. Peers below the threshold (-10) are disconnected.
| Factor | Weight | Description |
|---|---|---|
| Valid messages | +1 | Message passes signature and format validation |
| Invalid messages | -5 | Message fails validation (bad signature, malformed) |
| Duplicate flood | -3 | Sending excessive duplicate messages |
| Latency | +1 to -2 | Based on round-trip gossip ACK time |
| Uptime | +1/hour | Continuous connection time bonus |
| Stale data | -2 | Sending transactions or blocks that are too old |
Message Types
| Type | Payload | Size (typical) | TTL |
|---|---|---|---|
TransactionMessage | Signed EVM/SVM transaction | 200-500 bytes | 5 minutes |
BundleMessage | Ordered set of transactions | 1-10 KB | 2 minutes |
BlockMessage | Built block with transactions | 10-100 KB | 30 seconds |
PeerMessage | Peer discovery announcement | 100 bytes | 10 minutes |
Security
| Layer | Mechanism | Details |
|---|---|---|
| Transport | TLS 1.3 | Mutual authentication with ECDSA P-256 certificates |
| Encryption | AES-256-GCM | All gossip payloads encrypted with shared key |
| Signing | ECDSA P-256 | Every message signed; unsigned messages rejected |
| Compression | zstd | Payloads compressed before encryption |
| Deduplication | Bloom filter | 100K capacity, 0.1% false positive rate, prevents replay |
Block Building
When a node has enough transactions and bundles, it builds a candidate block:
- Fee-priority ordering — Transactions sorted by gas price (descending)
- Bundle-first inclusion — Bundles are placed at the top of the block to capture MEV
- Validation — Each transaction is checked for nonce correctness and sufficient balance
Built blocks are gossiped to the network and forwarded to the MEV engine webhook (if configured) for submission to builders.
Incentive Model
Node operators earn revenue from two sources:
- Relay fees — A percentage of the backrun auction revenue for transactions the node relayed. Distributed proportionally based on the node's position in the relay path.
- Reputation bonus — High-reputation nodes are preferred for priority routing, increasing their share of relay traffic and fees.
Payouts are processed weekly on Ethereum mainnet via the RebateDistributor contract.
Network Topology
┌─────────────┐
│ Bootstrap │
│ Server │
└──────┬──────┘
│
┌────────────┼────────────┐
│ │ │
┌─────┴─────┐ ┌───┴───┐ ┌─────┴─────┐
│ Node A │ │ Node B│ │ Node C │
│ ETH, BSC │ │ ETH │ │ ETH, SOL │
└─────┬─────┘ └───┬───┘ └─────┬─────┘
│ │ │
┌────┴────┐ ┌───┴───┐ ┌────┴────┐
│ Node D │ │Node E │ │ Node F │
│ETH, ARB │ │BSC,SOL│ │ETH, BASE│
└─────────┘ └───────┘ └─────────┘
│ │
└────────┐ ┌────────────┘
│ │
┌─────┴──┴─────┐
│ MEV Engine │
│ (webhook) │
└──────────────┘
Nodes discover each other through the bootstrap server, then form a fully connected mesh. Each node can subscribe to different chains. Transactions are relayed only to peers subscribed to the same chain. The MEV engine receives bundles via webhook from any node configured with a webhook_url.