LogicEncoder
I build async backends and operator-facing dashboards for high-frequency data domains — crypto exchange feeds, blockchain transaction streams, on-chain analytics. WebSocket where streaming fits, REST where polling is cheaper or safer. Deployed, observed under load, and tuned until the numbers change.
Engineering approach
Three rules that cut through most of the noise in backend engineering. Not principles for slides — constraints that shape every decision.
Every optimization starts with a number — latency, throughput, memory, CPU time. Rewriting code that isn't the bottleneck wastes engineering time and introduces new failure modes. Profile first, act on evidence, verify the result. Repeat.
Edge cases, rate limits, partial failures, and malformed inputs — checked before a deploy, not discovered by users. Behavior that's not tested is behavior that's assumed, and assumed behavior is where production incidents come from.
Fewer moving parts means fewer surprises when traffic spikes or a dependency changes. Structured logs, metrics, and reproducible failure paths from day one — not bolted on after something breaks in production.
What I build
Under load, not in staging. Fix the bottleneck that actually shows up in production traffic, not the one assumed in a code review.
Streaming ingestion, fan-out to multiple consumers, and hybrid WebSocket + REST architectures where polling is cheaper or safer. Built and benchmarked under production traffic.
Dashboards and APIs that turn high-volume event streams into sortable, filterable operator views. Buy/sell ratios, on-chain analytics, gas fee heatmaps — actionable signals, not chart noise.
Aggregation, caching strategies, async discipline; CPU and RAM pressure reduced on constrained VPS and shared hosting. Profile first, rewrite only what the numbers actually justify.
Structured logging, metrics collection, and reproducible failure paths — production issues stay bounded and diagnosable, not guessed at from a stack trace in a ticket three days later.
Edge cases, rate limits, partial upstream failures, and malformed inputs — behavior verified before and after every deploy. Not assumed to be unchanged from last time.
Custom themes, plugins, SSR-friendly pages, admin tooling, and caching layers when WordPress is the right public-facing surface. Performance-aware from the start, not after the SEO audit.
Live applications
Specific behavior is in the apps. Short technical descriptions here. All tools are kept small, fast, and boring on purpose — fewer moving parts, fewer surprises when traffic spikes.
Blockchain / Ethereum
Live Ethereum gas fee monitoring with trends, heatmaps by hour-of-day, and an interactive fee calculator. Async Python backend feeds a WebSocket-connected frontend — built for timing Uniswap and mempool transactions accurately, not estimating.
Open appExchange / Realtime data
Realtime exchange statistics with async ingestion from the MEXC API. Tracks buy/sell volume ratios, order flow signals, and per-pair analytics. SEO-optimized static surfaces sit alongside the live dashboard — each layer serves its purpose.
Open appBlockchain / Token analytics
Holder distribution and incentive-program analytics for the DHIP v2 token set. On-chain data structured into sortable, filterable operator views — wallet ranks, concentration metrics, and program participation.
Open appBlockchain / Transaction monitor
Significant on-chain movement monitoring for the Dynex network — transfers decoded and presented for operator use. Configurable threshold filtering, full input decoding, and address context. Low-noise by design.
Open appTechnical blog
Written for reuse by search and by Future Me. Concrete problems with reproducible steps — no filler, no marketing language.
If you’ve lost money to an unexpected gas spike on Uniswap or had a transaction stall in the mempool, you already understand the problem.…
Read article
Quick answer: The DNX Swap Bot is a standalone desktop web application that executes DNX swaps in one click from preset sizes (16 sell…
Read article
At a glance: The buy/sell volume ratio divides total buy volume by total sell volume over a given window. On MEXC spot pairs, a…
Read articleStack (typical)
Most work lands in this shape. Hosting constraints, latency requirements, and maintenance burden drive the choices — not hype cycles.
Python, FastAPI, asyncio — structured service boundaries, testable handlers, Web3 libraries when the domain requires on-chain interaction.
HTML/CSS/JS operator dashboards; WordPress custom themes and plugins; React/Vite or Vue when a client-side SPA is actually warranted by the use case.
SQLite for local/single-writer workloads, PostgreSQL for concurrent access, JSON artifacts and in-memory caches — chosen from latency and durability requirements.
Self-hosted or VPS, shared-hosting-aware WordPress with caching layers, Docker when the environment is stable, tunnels when testing webhooks locally.
About
Most of my work involves Python and FastAPI backends that handle high-frequency data from crypto exchange APIs, blockchain RPCs, and on-chain event streams. I build the async ingestion layer, the operator-facing dashboard, and the instrumentation that keeps everything observable in production.
The public tools here run on constrained infrastructure by design — shared hosting, small VPS. The constraint forces engineering discipline: if the code can't run lean, the architecture needs work. Performance engineering on tight hardware is more honest than optimizing an over-provisioned cloud instance.
Technical writing follows the same bar: symptom, cause, fix, verification. No padding, no affiliate links — concrete problems with reproducible steps that search can actually use.
Get in touch