lingnovo

Project 1: DEX/MEV Arbitrage and Liquidation Bot System for EVM-Compatible Public Chains Project Description An automated trading system deployed on Ethereum and other EVM-compatible public chains. The same digital asset (for example ETH) can be quoted at slightly different prices on different decentralized exchanges (DEXs) as buy and sell orders shift, and these price gaps are short-lived. The system monitors the latest price in every new block; whenever it finds a profitable "buy low on venue A, sell high on venue B" opportunity, it completes the full buy-to-sell loop inside a single transaction, locking in the spread as profit. The transaction is actually broadcast only when the trade stays net-profitable after network fees. It addresses three core pain points. First, speed: the arbitrage window usually lasts only a few seconds, sometimes a single block, so the conventional "send one transaction and wait for the receipt" approach is too slow. Second, capital: conventional arbitrage requires fronting the buy-side funds, whereas this system borrows the working capital atomically on-chain through flash loans / flash swaps (borrowing and repaying the full notional within one transaction, so no capital has to be deposited in advance), letting the contract start from a zero balance. Third, reliability: before broadcasting, the trade must be dry-run locally to confirm it will not lose money because someone else already took the price, slippage is too large, or the token has anomalous transfer rules. Ecosystem and business value: arbitrage bots of this kind objectively act as cross-venue price convergence agents, pulling the price of the same asset on different exchanges back into alignment, and are part of the infrastructure that keeps DeFi (decentralized finance) markets price-efficient. The system also covers the liquidation scenario on the Aave lending protocol (liquidation: closing another user's position and claiming their collateral once the collateral value falls below the required threshold). Tech Stack •Languages and layering: Rust + Python, bridged through PyO3 (the Rust-to-Python FFI binding framework) and Maturin (the PyO3 build and packaging tool); the core crate is deliberately free of any PyO3 dependency, so it can be used from pure Rust or driven by Python. •On-chain interaction and clients: alloy / alloy-rs (the Rust Ethereum client library), web3.py (early Python layer), and dual WebSocket/HTTP channels for subscribing to new blocks and events. •Transaction simulation: a self-developed in-process simulation engine built on revm (the Rust implementation of the Ethereum Virtual Machine). Instead of sending requests to an RPC (Remote Procedure Call) node, it forks the current chain state in memory and executes the transaction locally, combined with a layered database, an access list collector (which records the storage slots touched so the access list can be pre-populated) and a warm code cache, driving the network round-trip cost of "one simulation per opportunity" to zero. •On-chain executor contracts: executor contracts written in Vyper 0.5 (tstore_executor static queue / cmd_executor compact instruction stream: 1-byte opcodes plus an address-table index), sourcing working capital atomically through V2/V3 flash swaps and the V4 PoolManager take(), achieving zero pre-funding. •Protocol math: Uniswap V2 (constant-product AMM), V3/V4 (concentrated liquidity), Curve V1 (StableSwap for stablecoin swaps), Balancer V2 (weighted / stable / MetaStable / Composable), Solidly V2, Aave V3 (supply / borrow / liquidation / E-Mode / GHO); price oracles sourced from Chainlink. Note: AMM: automated market maker, a pool that prices assets by a formula instead of an order book. Concentrated liquidity: V3/V4 mechanism letting LPs allocate capital to a chosen price range. E-Mode: Aave efficiency mode, which raises borrowing power for correlated assets. GHO: Aave's native stablecoin. •Data and storage: SQLAlchemy 2.0 ORM + Alembic migrations + SQLite; on the Rust side, the db module has taken over schema DDL. Key Contributions •Arbitrage path discovery and graph search (DEX routing): modelled tokens as graph nodes and liquidity pools as type-labelled edges, forming a multigraph, and used iterative depth-first search (DFS) to enumerate arbitrage cycles (paths returning to the starting token) under minimum/maximum hop-count constraints and per-hop pool-type constraints. To cope with tens of thousands of edges per block, I made three engineering optimizations: pre-computing each node's legal positions at each depth to enable lookahead pruning, iterative dead-end node pruning, and compressing external addresses into contiguous u32 indices so the DFS hot loop walks cache-friendly contiguous memory. The path-search crate was designed as a zero-dependency leaf (no tokio, alloy or pyo3), so it can be unit-tested in isolation and reused by pure Rust programs. •Closed-form arbitrage solver (optimal trade size): recognised that the constant-product swap y = (γ·s·x)/(r + γ·x) is mathematically a Möbius transformation (a fractional linear transform), so an n-hop path composes into l(x) = K·x/(M + N·x); the exact optimal input therefore follows in one step from the closed-form expression x_opt = (√(K·M) - M)/N, with zero iterations. I unified the V2 constant-product model and the V3/V4 concentrated-liquidity tick ranges into a single "hop state" input contract, reused it across the Balancer / Curve / Solidly math leaves, and implemented a closed-form QuantAMM N-token basket solver. This removes the CPU cost that conventional bisection or Newton iteration would impose on a high-frequency hot path. Note: The source calls this a Möbius transformation that "does not fix the origin" (不动于原点). Note that the composite form l(x) = K·x/(M + N·x) does map 0 to 0, so the intended meaning may instead be that the transformation is not a simple translation anchored at the origin. The wording here stays deliberately close to the source; restate it if you prefer a strictly literal reading. •In-process simulation and risk control: forked chain state in-process with revm and ran a "7-call packet" per candidate path (3 balance snapshots, then execute, then 3 balance read-backs), judging true profit and loss from token balance deltas rather than return values; captured and decoded the actual fill of each hop through a SwapEvent Inspector, and maintained a "recent-divergence pool blacklist" (pools whose solver output has deviated from on-chain results are skipped for a while) plus a "fee-on-transfer suspicious token registry", bucketing simulation failures and suppressing them by category to cut wasted broadcasts. •Gas and priority-fee optimization: implemented market-aware priority-fee calculation: back-solving the priority fee to pay from a target profit ratio (TARGET_PROFIT_RATIO = 1.25), applying age decay (older results bid lower), and clamping the priority fee into the 10th-50th percentile band of the last N blocks; the EIP-1559 signing layer finalizes with maxFeePerGas = 1.5 x next-block baseFee + priority fee, so the transaction still wins inclusion without overbidding away the net profit. The signing key is held in memory exactly once (alloy PrivateKeySigner), using ECDSA secp256k1 with RFC 6979 deterministic signing, and cross-checked byte-for-byte against Python eth_account to guarantee identical signatures across languages. •Concurrency and performance architecture: organised parallelism as a role-switchable worker fleet: each role class has its own bounded queue and follows a "simulate first, solve second" lease priority, the cgroup CPU quota acts as the global budget ceiling, and a state machine switches between Nominal and Cordoned postures so no single task class can saturate the machine. Combined with in-process simulation (no RPC round trip per opportunity), the mimalloc allocator and rayon parallelism, the per-block hot path was brought into an acceptable range. Project 2: Local-First Quantitative Trading Terminal for the Solana DeFi Ecosystem Project Description Every day, hundreds to thousands of newly issued tokens appear on Solana (a high-performance public chain), known as memecoins in English and colloquially as "tu gou" (土狗, "mutt") in Chinese crypto communities. The core pain point for retail and quantitative traders is how to screen automatically, within seconds, through tens of thousands of tokens to find candidates whose liquidity is deep enough, whose volume is active, and which carry no risk of the project team hiding tokens or draining and abandoning the liquidity pool (a rug pull), then to buy automatically when conditions match and sell automatically at target prices. This project is a trading system built to run entirely on the user's own computer (local-first). Unlike the vast majority of comparable tools, it never uploads the user's wallet private key to the cloud: the key stays on the local machine at all times, encrypted at rest with AES-256-GCM (Advanced Encryption Standard with a 256-bit key in Galois/Counter Mode, an authenticated symmetric cipher), and the user keeps self-custody of their own key. On the product side it does four things: •Real-time "screening": reads on-chain pool reserves and computes prices itself instead of relying on delayed third-party market-data APIs, and fuses three data sources (DexScreener, GeckoTerminal, RugCheck) to assess liquidity, volume, holder concentration and risk. •Automated trading: a strategy engine triggers buys and sells against a user-configured condition tree, with stop-loss, trailing stop (a stop and take-profit line that ratchets upward with the highest price reached), ROI take-profit, DCA (dollar-cost averaging, buying in scheduled increments) position building, and partial take-profit. •Copy trading: monitors the on-chain actions of designated addresses, and every new task is required to run in paper trading (simulated trading with no real funds) to validate win rate and latency before live trading is "unlocked". •Remote alerting and control: a Telegram bot pushes fill, stop-loss and anomaly alerts and accepts commands. Tech Stack •Language and async runtime: Rust 2021 edition; the Tokio multi-threaded scheduler (rt-multi-thread); jemalloc (a high-concurrency allocator open-sourced by Facebook) explicitly substituted for the system malloc to reduce memory fragmentation and latency in high-frequency trading. •Blockchain interaction: Solana SDK / Solana client; 11 self-written native DEX program decoders that parse on-chain account data directly from Raydium (CLMM / CPMM / Legacy AMM), Orca Whirlpool, Meteora (DAMM / DBC / DLMM), Pump.fun (AMM / bonding curve), Fluxbeam and Moonit. Trade execution runs over two channels: Jupiter V6 (Solana's largest DEX routing aggregator) and self-constructed instructions (an instruction is Solana's term for one call into an on-chain program) sent directly to liquidity pools; both are quoted concurrently, the best price is selected automatically, and failures fall back with retries. •Data pipeline and availability: batched RPC requests (50 account reads per request) plus an adaptive rate limiter (GCRA, Generic Cell Rate Algorithm, with exponential backoff and 10% random jitter), a circuit breaker, and health checks with automatic failover across multiple RPC endpoints. Why: Solana RPC nodes enforce strict rate limits and are jittery, so unified rate limiting avoids IP bans, circuit breaking stops a single failing endpoint from dragging down the whole data path, and two or three endpoints from different vendors back one another up to keep market data flowing around the clock. •Storage: SQLite (an embedded relational database, rusqlite compiled in) plus an r2d2 connection pool (pre-built connections reused from a pool), sharded to disk by transaction subject (subject-scoped: own wallet versus monitored wallets), with schema migrations and event persistence. •Server and real-time push: Axum (a high-performance web framework in the Tokio ecosystem) serves REST APIs and WebSocket (a full-duplex real-time channel) that push quotes and fills to the dashboard; tower-http handles response compression and CORS (cross-origin resource sharing). In GUI mode it binds only to the 127.0.0.1 loopback address, allocates a dynamic high port in the 49152-65535 range and validates a one-time security token. Why: a local application must never be exposed to the public internet, and the dynamic port plus token prevents other local processes or malicious pages from impersonating the dashboard. •Concurrency and caching: dashmap (a thread-safe concurrent hash map), moka (an in-memory cache with eviction policies), arc-swap (lock-free atomic pointer swap, giving zero-pause reads during hot configuration reloads). •Security design: private keys encrypted with AES-256-GCM, the key derived from a machine fingerprint (machine-uid); the login and lock screen support TOTP (time-based one-time password) two-factor authentication; MCP (Model Context Protocol) connections opened to AI agents are governed across five permission classes (analytics / positions / trading / config / system) at three levels, Allow / Ask (approve on request) / Off, and wallet key fields are masked on read and rejected on write at every permission level. •Integration and automation: teloxide (a Rust Telegram Bot framework) for notifications, commands and inline buttons; a unified client wrapper over nine LLM (large language model) providers (OpenAI, Anthropic, Groq, DeepSeek, Gemini, Ollama, Together AI, OpenRouter, Mistral) supporting tool calling and scheduled tasks; and a built-in "mcp serve" bridge that lets external AI coding agents such as Claude Code drive the application. •Desktop shell and engineering: Electron (a Chromium + Node.js desktop application framework) provides the native window shell, launching the local Rust backend at startup and loading the embedded dashboard; cargo-nextest runs layered integration tests (L0 pure functions / L1 read-only mainnet / L2 real mainnet swaps); Playwright covers front-end UI contract tests. Key Contributions •Backend service architecture: modelled tokens as graph nodes and liquidity pools as type-labelled edges, forming a multigraph, and used iterative depth-first search (DFS) to enumerate arbitrage cycles under minimum/maximum hop-count constraints and per-hop pool-type constraints, with lookahead pruning, iterative dead-end node pruning and contiguous u32 index compression for the DFS hot loop; the path-search crate is a zero-dependency leaf (no tokio, alloy or pyo3), independently unit-testable and reusable from pure Rust. Note: Translator's note: this bullet is identical to the first bullet of Project 1 in the source document and appears to have been pasted here by mistake. It is translated verbatim; consider replacing it with a description of this terminal's own service architecture (Axum + WebSocket event streaming, subject-scoped SQLite sharding). •On-chain data pipeline design and performance optimization: designed the main chain "market-data API, then token store, then screening engine, then strategy, then entry gates, then swap routing, then positions"; used batched RPC plus GCRA adaptive rate limiting, circuit breaking and multi-endpoint failover to maximize the number of monitorable tokens within the RPC rate quota; and used dashmap / moka / arc-swap to keep hot paths (price computation, strategy evaluation) lock-free on read and pause-free on configuration reload. •Real-time pricing and trade execution: implemented real-time price computation by parsing on-chain reserves directly, deliberately split from the OHLCV (open / high / low / close / volume) system: the former drives execution and P&L (profit and loss), the latter drives charts and technical indicators, so that chart lag cannot contaminate trading decisions. Designed seven entry safety gates (global kill switch, connection health, position cap, deduplication, cooldown, blacklist, strategy signal) and an eight-level exit priority ladder (blacklist emergency exit, then 90% loss protection, then trailing stop, then ROI take-profit, then timeout, then strategy exit). •Security and risk control: implemented machine-bound AES-256-GCM private-key encryption, loopback binding plus dynamic port plus token authentication, and TOTP two-factor authentication; designed a tiered authorization model for the AI agent channel, guaranteeing architecturally that an agent can never reach plaintext private keys and that signing only ever happens on the local machine. •Full-stack and delivery: used Axum + WebSocket to stream backend events into the embedded web dashboard, and delivered macOS / Windows / Linux installers with the Electron shell; wrote layered tests and UI contract tests so that changes remain safe to regress. Project 3: US Equities Quantitative Trading Terminal Project Description An "institutional-grade" quantitative trading terminal built from scratch in Rust, aimed at the low-latency trading systems that were once affordable only for investment banks and hedge funds. In non-technical terms: it packs the entire trading pipeline - watch market data, compute risk, decide, place and fill orders, review afterwards - into one independently runnable program, with nanosecond-resolution timing and sub-millisecond latency. Where ordinary systems measure speed in milliseconds, its critical path measures in tens of nanoseconds (one nanosecond is one billionth of a second). It solves three core problems: •Languages such as Python make quant development fast but suffer garbage-collection pauses and unpredictable latency; Rust, with no garbage collector and with memory safety, reaches performance close to C++. •It consolidates the official binary market-data and order-entry protocols of US exchanges (Nasdaq, NYSE), real-time feeds from cryptocurrency exchanges, risk control, backtesting and AI analysis into one event-driven architecture, avoiding the latency and error surface of stitching several systems together. •All values are stored as exact integers rather than floating-point numbers, eliminating accumulated floating-point precision error in financial computation. Within the Rust quantitative finance ecosystem it is comparable to RustQuant (a quantitative finance algorithm library), NautilusTrader (a production-grade framework with a Rust core and Python strategies) and hftbacktest (high-frequency backtesting); its value lies in presenting a complete, auditable reference implementation spanning the whole chain from market-data decoding to execution algorithms, with no external trading SDK. Tech Stack •Language and toolchain: Rust (2021 edition, stable toolchain) and a Cargo workspace (the mechanism that compiles multiple crates together and shares dependencies and release configuration). The release profile uses opt-level = 3 plus lto = "fat" (link-time optimization: whole-program cross-crate inlining and dead-code elimination at maximum aggressiveness), codegen-units = 1 (a single code-generation unit for better instruction layout) and strip = true (stripping the symbol table to shrink the binary). •Async and concurrency: the Tokio async ecosystem; async-trait (the macro that marks trait methods as async) to implement pluggable MarketDataSource / ExecutionGateway / PluggableStrategy / FillModel abstractions; Rayon (the Rust data-parallelism library that parallelizes iterators across cores) driving 100,000-agent market microstructure simulations; AtomicU64 (a lock-free atomic counter) for event sequence ordering. •Serialization and networking: Serde (the Rust serialization/deserialization framework) plus Postcard (a compact no_std binary format built on Serde, used for zero-copy low-latency inter-process transport); axum 0.7 (an async HTTP framework in the Tokio ecosystem) for REST API and WebSocket push; a self-written TCP event bus framed with a 4-byte length prefix. •Financial computation: Black-Scholes-Merton option pricing (including Delta / Gamma / Theta / Vega / Rho and the second-order Greeks Charm and Vanna), Heston (stochastic volatility), SABR (volatility smile and surface), Hull-White (short-rate model), GARCH(1,1) / EGARCH (conditional heteroskedastic volatility models), VaR / CVaR (value at risk / conditional value at risk, also called expected shortfall), Monte Carlo simulation, walk-forward rolling out-of-sample backtesting, Almgren-Chriss optimal execution (a closed-form trajectory trading market-impact cost off against risk), the Avellaneda-Stoikov market-making quote model, and microstructure indicators including OFI (order flow imbalance), VPIN (volume-synchronized probability of informed trading), microprice and Kyle's Lambda (price impact coefficient). •Storage and observability: PostgreSQL (relational store for historical persistence) plus Redis (in-memory store for hot state); a Prometheus-compatible /metrics endpoint; tracing (the Rust facade for structured logging and distributed tracing) exported to Jaeger over OTLP. •Protocols and front end: a self-written FIX 4.4/4.2 engine (FIX, Financial Information eXchange, the standard broker-to-exchange protocol, length-framed with checksums); decoders for the official binary protocols Nasdaq ITCH 5.0 and OUCH 4.2 and NYSE XDP / Pillar; a six-screen TUI dashboard built with Ratatui (a Rust terminal UI library), plus an axum-hosted static web dashboard. Key Contributions •System architecture and memory safety: led the split of the monolith into a Cargo workspace of 34 strictly bounded Rust crates (a crate is Rust's independent compilation and distribution unit, comparable to a module or library elsewhere), using traits (Rust's interface abstraction) to make market-data sources, execution gateways, strategies and fill models fully replaceable: a dead feed can be swapped, strategies hot-plugged, and backtesting shares the same traits as live trading, guaranteeing at the root that a backtested strategy can go live unchanged. At the event layer, a generic Envelope<T> wraps all system events and UnixNanos timestamps plus AtomicU64 monotonic sequence numbers give deterministic ordering, with a switchable clock (the real clock for live trading, a DeterministicClock for backtests) so replays are reproducible. Critical modules carry #![forbid(unsafe_code)]; data races are eliminated at compile time by Rust ownership and the borrow checker rather than by runtime locks. •High-performance, low-latency computation: prices are normalized to i64 fixed-point integers (with 1e-9 USD as the smallest unit), eliminating floating-point error accumulation, and a Level-3 (order-by-order) order book was implemented. Measured results: about 40 ns for one order-book match update, about 34 ns for a Black-Scholes European call price, about 2.3 ns for a GARCH volatility update. Fat LTO plus a single codegen unit push the critical hot path to its limit, and Criterion establishes performance regression baselines; measured overheads such as "about 42 ns to read the clock" are explicitly folded into instrumentation design, with record_path taking a timestamp from the caller instead of reading the clock itself, so that measuring does not pollute the thing being measured. •Financial model implementation: independently implemented option pricing (the full BSM Greek set including second-order Greeks), stochastic volatility (Heston), interest rates (Hull-White), bond duration and convexity, real-time GARCH(1,1) / EGARCH volatility, historical / parametric / Student-t fat-tailed VaR and CVaR, portfolio VaR decomposition, Monte Carlo path simulation and walk-forward backtesting; on the execution side TWAP / VWAP / Iceberg / POV (participation rate) and Almgren-Chriss optimal execution trajectories, with the urgency parameter kappa adapted from GARCH volatility and market state. Rayon parallelizes the 100,000-agent microstructure Monte Carlo simulation. •Backend services and full-stack delivery: Tokio + axum implement the REST/WebSocket server (health checks, market-data push over /ws); a self-written Postcard length-framed TCP event bus connects the daemon (a long-running background service) to the TUI client, and a broadcast channel provides one-to-many fan-out; PostgreSQL / Redis persistence and Prometheus metrics are integrated. On the front end, Ratatui powers a six-screen live trading dashboard (price chart, L2 book, positions, AI panel, emergency kill switch), while axum hosts a static web dashboard with WebSocket push, closing the full-stack loop as "one event bus, two front ends - terminal and browser". Project 4: Decentralized Perpetual Futures Exchange on a Custom Modular Blockchain Project Description A blockchain written from scratch, whose core product is a decentralized futures exchange (DEX, decentralized exchange: an exchange that depends on no traditional broker, where users complete trades and custody their own funds through smart contracts), focused on leveraged perpetual futures (perpetuals: derivatives with no expiry date, pegged to the spot price by a "funding rate", tradable long or short). The pain point it solves: existing centralized exchanges carry the risk of absconding with or misusing user assets, while early on-chain exchanges were generally slow, expensive and weak at matching. The approach here is to move the order-book matching engine of a traditional exchange directly on-chain, so that code rather than a company guarantees matching, clearing and fund safety. Architecturally it follows the modular blockchain route (splitting execution, consensus, data availability and other functions that used to be coupled inside one chain into independent, replaceable modules): the team did not build its own consensus algorithm, but connected a self-developed execution layer (the state machine that actually runs transactions and updates the ledger) as an application to the mature CometBFT consensus layer (formerly Tendermint, a Byzantine-fault-tolerant consensus engine that makes many nodes agree on block order), communicating over ABCI (Application Blockchain Interface, the standardized protocol between the execution and consensus layers). This reuses consensus already proven in the Cosmos ecosystem while keeping full control of execution-layer performance and contract semantics. In ecosystem terms it integrates Pyth (a decentralized oracle network that feeds traditional-finance prices on-chain) for pricing and uses Hyperlane (a general cross-chain messaging protocol) for cross-chain deposits and withdrawals of assets between Ethereum and other external chains. Tech Stack •Languages and runtime: Rust (Edition 2021, covering the execution environment, all contracts, the indexer and the node CLI); TypeScript / React (front-end dApp and SDK); a small amount of Python SDK. •Blockchain core: a self-developed state machine (the core program that deterministically turns a batch of transactions into a new ledger state) plus CometBFT / Tendermint 0.40 and tower-abci; a dual-storage model (following Cosmos SDK ADR-065, splitting the raw state store that contracts read and write from the state commitment used for cryptographic proofs); RocksDB (a persistence layer tuned per column family); and the Jellyfish Merkle Tree (JMT, a sparse Merkle tree proposed by Diem, used to produce the state root and inclusion / non-inclusion proofs). •Smart contracts and virtual machines (VM, the sandbox that executes contract bytecode): a dual-VM design, with RustVm (native Rust executed directly: no sandbox and no gas overhead, used for official system contracts in exchange for maximum performance) and WasmVm (running third-party WebAssembly bytecode on Wasmer, with a compile-time gatekeeper capability whitelist, per-instruction metering, a 32 MiB memory cap, query depth capped at 3, and other sandbox protections); account-level gas metering (charging per operation and per byte, rolling state back but still collecting the fee when the limit is exceeded). •Business contracts (all first-party official contracts, running on RustVm): Bank (bank / token ledger), account factory and account abstraction, Oracle (price oracle), on-chain order-book perpetuals (Perps, covering margin, funding rate, forced liquidation, auto-deleveraging ADL and the insurance fund), Vault (EIP-4626-style shares with inventory-skewed quoting), Gateway (cross-chain gateway), Hyperlane mailbox / ISM, Vesting (linear release) and Upgrade (chain upgrade). Note: ADL (auto-deleveraging): when the insurance fund cannot absorb a liquidation, the exchange reduces opposing profitable positions automatically. EIP-4626: the Ethereum tokenized-vault standard. ISM: Interchain Security Module, Hyperlane's pluggable message-verification module. •Data-consistency safeguards: a dimensional type system (using compile-time type parameters to tag the dimensions of quantity, USD and time, so that a "price x quantity = amount" mistake surfaces at compile time rather than at run time), Borsh serialization, overflow-safe fixed-point numbers, and Bounded types. •Data stack and API: a read-only indexer (which observes blocks and writes to external databases without entering the consensus critical path) writing to PostgreSQL (sea-orm ORM plus migrations) and ClickHouse (an analytical columnar store); GraphQL (async-graphql + actix-web) queries exposed externally with PostgreSQL LISTEN/NOTIFY and graphql-ws for real-time subscriptions, plus DataLoader to eliminate N+1 queries; Prometheus metrics and Sentry / OpenTelemetry telemetry. •Front end: React 19 + TanStack (Router / Query / Table / Virtual) + RSbuild + Tailwind + Zod validation + graphql-ws subscriptions + TradingView / Recharts candlestick charts, managed as a pnpm + Turborepo monorepo, with Playwright end-to-end tests. Key Contributions •Modular execution layer and state machine design: under an architecture that decouples the execution layer from the consensus layer, implemented and maintained the ABCI lifecycle (CheckTx mempool validation, then FinalizeBlock per-transaction atomic execution, then Commit two-phase persistence), and used layered buffer rollback (block-level / transaction-level / sub-message-level, discarded as a whole on failure) to guarantee that a transaction either takes effect completely or leaves no trace at all. Why: the consensus layer only guarantees block order, so the execution layer must independently provide determinism and rollback, or different nodes would compute different ledgers and the chain would fork. •Dual storage and state commitment: implemented the ADR-065-style split of state storage from state commitment, using separate column families in a single RocksDB to carry two very different workloads - high-frequency small writes from contracts versus deletion-heavy chained state - and tuned each differently; maintained the JMT state root, historical version proofs and version pruning. Why: separating read performance and write flexibility from cryptographic verifiability keeps contract reads and writes fast while still offering verifiable state proofs to the outside world (light clients, cross-chain). •Contract execution environment (VM) and gas system: owned the RustVm / WasmVm abstractions, the WASM host functions (storage reads and writes, secp256k1 / secp256r1 signature verification, hashing, cross-contract queries) and the gas metering table, and used a compile-time gatekeeper to disable SIMD, threads, exceptions and other features that risk non-determinism or memory leaks. Why: derivatives demand that every node compute byte-identical results, and any non-determinism (floating-point SIMD, parallelism) can split consensus, so it has to be constrained proactively at the sandbox layer. •DeFi core contract development (perps / order book / vault): implemented the pure business logic of margin, funding rate, matching, forced liquidation and ADL on top of the dimensional type system, and used the type system to catch high-risk unit errors such as mixing amounts with prices at compile time. Why: in contracts that hold funds, a bug directly equals users losing money, so moving validation forward to compile time blocks a large class of fatal errors before testing even starts. •Indexer and read-only API layer: built a read-only indexing pipeline that "computes the state root first, then writes to the databases asynchronously" (PostgreSQL business tables plus ClickHouse analytical tables plus an on-disk cache), exposing GraphQL queries and WebSocket subscriptions and using DataLoader to solve N+1 on list pages. Why: taking heavy queries off the consensus critical path means block production continues even if the indexer goes down, balancing performance against safety boundaries. •Cross-chain and oracle integration: implemented cross-chain message verification and the deposit/withdrawal gateway (routing, rate limiting, cancellation fees) on Hyperlane mailbox / ISM, and integrated the Pyth price client with freshness checks on the consuming side. Why: off-chain assets and prices are external sources of trust, so trust boundaries, expiry checks and rate limits have to be modelled explicitly to stop a bad price or an abused channel from amplifying risk. •Front-end and full-stack collaboration: maintained the React dApp and TypeScript SDK, wired up GraphQL queries/subscriptions and the signed-transaction flow, and handled live refresh of candlestick charts and the order book plus wallet / Passkey (WebAuthn) signing.

China Mobile Chain - EVM-Compatible Subnet Project Description A blockchain fully compatible with Ethereum, whose goal is to raise transaction throughput from Ethereum's current tens of transactions per second to about 10,000 per second, and to compress finality (the time until a transaction is confirmed and can no longer be rolled back) from Ethereum's several minutes to about 600 milliseconds, all without sacrificing decentralization or security. The core business pain point it solves: applications in the Ethereum ecosystem that cannot run today because the chain is too slow and too expensive - high-frequency trading, on-chain gaming, large-scale payments, social applications - can be moved over directly with their existing Solidity code and Ethereum wallets: no wallet switch and no contract rewrite. Hundreds to thousands of globally distributed validators (servers running the consensus software and voting on the ledger) must still agree on which transactions, in what order, go into the next block, even when nodes crash, the network lags, or a minority of nodes behave maliciously, and once agreement is reached it must never be reversed. It introduces two key innovations on top of classical BFT (Byzantine Fault Tolerance, a distributed-systems algorithm that still reaches consensus when malicious nodes are present): •Pipelining: the voting processes of multiple blocks overlap in time, instead of waiting for one block to be fully confirmed before starting the next. •Tail-forking resistance: through reproposal and the No-Endorsement Certificate (NEC), a malicious or offline block leader is prevented from deliberately discarding a previous block that already won a majority of votes and stealing its block reward and MEV (maximal extractable value: the extra profit a validator earns by reordering or inserting transactions). Tech Stack •Programming languages and systems: Rust, C++, TypeScript, Docker, Linux networking (UDP). •Core consensus protocols: Pipelined BFT, Quorum Certificate (QC), Timeout Certificate (TC), No-Endorsement Certificate (NEC), speculative finality. •Network and communication architecture: the RaptorCast protocol (a broadcast protocol built on Raptor erasure coding), erasure coding, a multicast broadcast tree, a dataplane (the data-forwarding plane) and peer discovery. •Transaction pool and component architecture: a tracked TxPool (a transaction pool in which entries are tracked), a Sequencer (transaction orderer), an Execution State Bridge (a bridge for reading execution-layer state) and a Control Panel (node control panel). Note: QC / TC / NEC: certificates proving respectively that a quorum voted for a block, that a round timed out, and that a leader failed to endorse the previous block. Speculative finality: a block is treated as final after one round of voting, with full finality after two. Key Contributions •Byzantine consensus engine development and state machine design: contributed to the core consensus logic module, owning the generation and verification of the Quorum Certificate (QC, proving that a majority of nodes have voted), the Timeout Certificate (TC, handling the case where the leader node goes down) and the No-Endorsement Certificate (NEC), and implementing single-round speculative finality and two-round full finality at linear communication complexity. •RaptorCast high-performance transport protocol development: used Raptor erasure coding (slicing data and adding redundancy so packet loss is survivable) to split a block proposal into chunks, and combined a two-level multicast broadcast tree with round-robin scheduling to reduce the upstream bandwidth pressure on the block producer and propagate large blocks efficiently across the network. •TxPool and network dataplane optimization: developed the network dataplane module that manages how a node receives and forwards transactions; designed a decoupled architecture for a bounded tracked TxPool and the Sequencer, and used P2P peer discovery with encrypted ports to keep transaction forwarding efficient at high throughput while preventing DDoS attacks. •Consensus-to-execution state bridge interface design: refactored the ExecutionStateRead abstraction in the consensus module so the consensus layer can fetch the latest execution-layer state efficiently, ensuring transaction validation and reserve balance checks. Full-stack operations console and service monitoring: developed the node Control Panel and the underlying RPC interfaces, and maintained full-node networking logic, the block synchronization mechanism (BlockSync peers) and Docker single-node / multi-node automated deployment scripts, so that operations staff and front-end applications can easily obtain node connectivity and consensus status data.

•Employee #1 of the company's technical team: responsible for building the engineering talent pipeline, designing role definitions, planning how the team would be assembled, supporting recruitment, and completing the technical team restructuring. •Led continuous source-level study of the IPFS and Filecoin projects, and designed and implemented the Filecoin Lotus cluster mining solution. •Researched emerging blockchain projects including NEAR, Substrate and Cosmos, and delivered internal technical training.

•Coordinated colleagues on the development and implementation of building drawing review systems (施工图审查, the statutory review of construction drawings) in Jinan, Weifang, Zhuhai and other cities. •Built and maintained Hyperledger Fabric consortium blockchain clusters. •Performance optimization and maintenance of the drawing-review platform backend (Golang), and PostgreSQL database performance tuning. •Day-to-day maintenance of servers (Ubuntu / Windows), databases and business application programs.

•Employee #2 of the company; participated in building the engineering talent pipeline and designing role definitions. •Operations of Alibaba Cloud servers (Docker containerization, production Kubernetes cluster), RDS and OSS; maintenance of Beego-based business systems (bug fixes, code refactoring, feature maintenance); participated in the design and implementation of a DevOps platform. •Delivered one-stop digital marketing products: a multi-platform core operations system supporting Alipay Service Window, Baidu Zhidahao and WeChat Official Accounts, plus micro-restaurant, micro-distribution, micro-community and micro-anti-counterfeiting products and a mobile DSP advertising platform. •Foundational interface microservices (Alibaba Cloud RDS and OSS; WeChat Official Account, Alipay Service Window and Baidu Zhidahao APIs; internal and external business data interfaces); ESC/POS command encapsulation for 58 mm thermal printers, cross-platform driver development and the cloud-print backend service; batch deployment and maintenance system for smart cloud boxes (sensor devices supporting the WeChat Hardware Platform). Built and maintained Hyperledger Fabric consortium blockchain clusters; led the development and implementation of the Kaixun anti-counterfeiting system.

•Participated in project management design for the information management platform of Da Hua CPAs; owned the design and development of generic permissions, wrapped an Active Directory data-listening component, and kept Active Directory data and the permission database in real-time sync; integrated permissions with the project management, HR and portal modules; handled quality control, risk assessment, late-stage code consolidation and optimization for the project management system. •Served as the vendor-side project manager on the VTRON high-resolution (Gaofen) satellite application visualization design platform, leading a six-person .NET team building the related tools. Main responsibilities: a plugin-based development framework centered on Caliburn.Micro + MEF + AvalonDock, built to the requirements of the visualization platform's second-development IDE; development of the run-preview tool and the control-end tool; and cooperation with the vendor manager and other colleagues on overall quality supervision, risk assessment and integration testing. •On the Yimeina customer relationship management (CRM) project: cooperated with colleagues on shared class libraries and component packaging, and handled UI design and coding for inventory management and cash management. Main technologies: the MVVM pattern, with client UI designed in Expression Blend 4 and business processing in view models; WCF RIA domain services for client-server communication; Entity Framework for data access, with LINQ and Lambda expressions for data processing; plus DES encryption and decryption, caching, dependency injection, custom controls, custom formulas, XML-driven menus and a report server. The development model differed from previous projects: iterative development, interface-oriented and service-oriented design, easy to maintain and easy to extend for secondary development. •On the Huikang Group financial management system project: worked on the generic permission management module, performance tasks, employee change records, employee attendance, employee social insurance and national finance standards, mainly responsible for ExtJS page design and front-end/back-end data interaction, and for the design, implementation and testing of the shared permission module. Main technologies: the MVVM pattern, DES encryption and decryption, NPOI for importing and exporting Excel data, custom controls, caching, dependency injection, custom formulas, XML-driven menus and a report server. Development model: waterfall, with interface-oriented and service-oriented design, easy to maintain and easy to extend for secondary development.