Rust Protocol Engineer — Autheo | Live Mainnet Consensus, P2P Networking & Node Performance

Launch Legends•Cheyenne, WY

1d•Remote

About The Position

Autheo is recruiting a Rust protocol engineer to improve the node itself, including consensus-adjacent paths, peer-to-peer networking, state sync, storage, and validator-set performance. Autheo Mainnet launched on May 14, 2026, with a decentralized validator set. The coordination layer is Cosmos-based, and Rust is a first-class path in the Eigensphere Engine. The role is hands-on: the engineer owns a technical surface, writes code, and reviews adjacent code. The engineer will harden and extend Rust components along block production, validation, and finality paths; work on state storage and synchronization; improve deterministic upgrades; own Rust P2P paths; instrument networking; measure and improve node performance; and collaborate with Site Reliability on validator and RPC operations. Work includes documenting invariants, adding benchmarks to CI, and instrumenting owned paths with OpenTelemetry or Prometheus. This is a part-time equity/token-based cofounder opportunity requiring at least 20 hours per week. Compensation includes equity in Launch Legends, Autheo, and the WFO Creator Network, plus Autheo token allocations. There is no cash salary currently. The role is remote. Mainnet is live and THEO is already trading.

Requirements

Provide public Rust code personally written, such as a GitHub/GitLab profile, crates.io crate, or merged pull requests to a public Rust project; applications without a code link will not be reviewed.
Production Rust experience with ownership, lifetimes, async programming (Tokio or equivalent), and concurrency debugged under load.
Hands-on experience in at least one real blockchain or distributed-consensus codebase, such as Substrate, Cosmos SDK/CometBFT or a Rust ABCI stack, reth/Lighthouse, Agave/Solana, Sui/Aptos, Fuel, Narwhal/Bullshark/HotStuff-family, or production Raft/Paxos; applicants should name the repository and their contribution.
Networking expertise in libp2p, QUIC, gossip protocols, or an equivalent, with the ability to explain message types and failure modes.
Comfort using Linux performance tools such as perf, flamegraphs, heaptrack, or equivalent.
Comfort working with a CI pipeline that builds and tests Rust.

Nice To Haves

Contributions to rust-libp2p, smoldot, Substrate/polkadot-sdk, reth, Lighthouse, Agave, Sui, Aptos, Fuel, NOMT, or a comparable project.
Experience with light clients, state sync, or storage engines such as RocksDB, MDBX, Merkle-Patricia, JMT, or NOMT.
IBC or cross-chain message-handling experience.
A public artifact for review, such as a design document, talk, paper, or post-mortem.

Responsibilities

Read, harden, and extend Rust components on block production, validation, and finality paths, and document the invariants relied upon.
Work on state storage and synchronization, including Merkle/state database layout, pruning, snapshots, warp or fast sync, and replay tooling for the live chain.
Ensure upgrades are deterministic so nodes built from the same commit produce the same state.
Own Rust peer-to-peer paths, including peer discovery, gossip, request/response protocols, backpressure, and handling slow, malicious, or partitioned peers.
Instrument the network with metrics and traces to diagnose missed blocks and slow synchronization.
Profile hot paths such as block import, signature verification, state reads and writes, and the mempool on replay and Mainnet; report measured p50/p99 latency, allocations, and throughput.
Add benchmarks to CI using criterion or an equivalent tool so performance regressions fail the build.
Work with Site Reliability on validator and RPC operations, readiness and health signals, upgrade runbooks, and incident write-ups for node-level faults.
Add OpenTelemetry or Prometheus coverage to the paths owned.
Within the first 90 days, produce a written map of the node's Rust surface, identifying live, stubbed, and risky areas, with an agreed stop/continue/start list.
Within the first 90 days, measure one consensus, sync, or networking path on replay, cover it in CI, and document it.
Within the first 90 days, add a CI benchmark for one hot function and document its measured result.
Within the first 90 days, write a design note for an improvement, such as faster sync, peer scoring, or state pruning, and obtain protocol-lead review.