I run the node, ingest the data, write the APIs, ship the UI and operate execution bots. This is the evidence—including the parts where I'm not the strongest fit.
No generic portfolio. No “exceptional engineer” paragraph. Open the evidence and decide.
WHY PROPR, SPECIFICALLY
I tell every recruiter the same thing: my next role should keep me in the Hyperliquid ecosystem. I just do not want to spend the next few years rebuilding the same product in a different wrapper. Propr lets me bring what I already know into prop trading—a business I genuinely want to understand.
Hyperliquid is not just a logo in Propr's stack; it is the venue underneath a much larger prop-firm product. I already run nodes, bots, data pipelines and trading products around it. My next job should make that context compound.
I watched Louis explain that the first priority was getting the Hyperliquid experience right, then opened a free demo and tried the challenge myself. I did not expect prop-firm rules, risk and incentives to be this interesting—but the product clicked.
I deliberately look for rooms where other people know far more than I do. I grow when I have to earn context, ask better questions and become useful outside my comfort zone.
I can be useful on day one around Hyperliquid and engineering. The parts I do not know yet—prop risk and operations—are exactly why I want to be there. Propr builds in public, so this page does the same: evidence, plus the gaps I will not pretend away.
CURRENT / END TO END
A Hyperliquid event begins at my node. I deliver it through a low-latency data layer, persist and aggregate it, expose it through a typed API, then consume it in a live trading product.
Mainnet + testnet infrastructure I own and operate today; node-adjacent delivery.
gRPC streams and low-latency ingestion into typed services.
Raw logs, materialized views, aggregation and replayable history.
REST, SSE, API keys, metering, webhooks and operational controls.
Live market state, wallet signing, builder codes and finished UX.
My interconnected Hyperliquid products and infrastructure live in one monorepo. It is a real dependency graph, not several folders under one root. Unrelated projects stay separate. The repository is a coordination boundary—not a deployment boundary—so each service can still ship and fail independently.
All of my current Hyperliquid VMs run on AWS. Cloudflare manages the public edge. Convex is an intentional shortcut when reactive product state matters more than owning every piece of backend plumbing.
Nodes, ClickHouse, ingestion, APIs, liquidators and supporting services run on EC2. Latency-sensitive node, data and execution paths sit in Tokyo; S3 archives, SSM deploys, SNS alerts and EBS snapshots surround the runtime.
My domains and DNS live on Cloudflare. Workers run application surfaces, read proxies, push relays and external sentinels; Tunnel fronts EC2 origins, Access gates admin surfaces and R2 serves public generated media behind the edge.
For a new product surface, I sometimes use Convex because reactive queries keep the frontend live without first building pub/sub plumbing. I keep custom services where latency, replay, analytics or execution control justify them.
Critical execution and replay stay explicit. Convenience is welcome where it is easy to replace.
The hard part is not drawing these boxes. It is deciding what happens on a reconnect, a duplicate event, stale state or a failed cutover. My systems include replay, targeted refresh, response diffing and explicit degraded paths.
Reorgs, duplicates, retries, backpressure and rebuildable projections show up whether the source is Moralis, HyperEVM or Hyperliquid. This is the production history underneath my current stack.
I source HyperEVM block history to reconstruct Morpho positions and surface risky accounts. Separately, I persist HIP-4 fills in ClickHouse and derive API, materialized-view and analytics projections from that history.
At Moralis, I was part of the backend refactor that became Continuum. We polled nodes for blocks and receipts, wrote durable positions into partitioned S3 history, and let independent consumers turn the ordered stream into their own projections. Redis coordinated the hot path.
With one other engineer, I built the production system behind Moralis Streams. Developers registered wallets or contracts and optional topic0 filters; we matched live transactions and logs, decoded the relevant activity and pushed webhooks through a hot path built for sub-second delivery. The hard parts were retries, duplicates, reorgs, confirmations and backpressure.
FINANCIAL CORRECTNESS
Propr calls out arbitrary precision for a reason. Raw amounts stay strings or BigInt at boundaries. Precision primitives are tested against an independent implementation. Integrations meet real dependencies before release.
No accidental JS float conversion at financial boundaries.
Custom primitives differentially tested against decimal.js.
Testnet, contracts, ClickHouse containers and shadow comparisons.
I have used TypeORM in production, although it was years ago. I would use it again where a transactional service accepts outside input and benefits from consistent entities, migrations and transaction boundaries. I use raw SQL for ClickHouse because its engine-specific analytics are the point, not an implementation detail to hide.
I studied computer science in Germany, then dropped out when Moralis offered me the job. One of the few exams I took was Informationssysteme—databases, SQL and relational algebra. I scored 98 out of 100.
Runtime validation → authorization → parameterized values → least-privileged database role. An ORM helps with this path; it does not replace it, solve decimal precision, or make an external exchange call atomic.
TypeORM parameter bindingEXECUTION SYSTEMS
I run Felix CDP and Morpho liquidation bots on HyperEVM. With no public mempool, the useful edge is reliable state and execution: the bots sit beside my Hyperliquid node in Tokyo to reduce round-trip latency.
Maintain the trove index, react to each block, refetch only affected state, simulate the opportunity, submit, then remove or reconcile positions after the result.
The second bot proves that the execution discipline is reusable. Health checks and opportunity math change; idempotency, observation and recovery do not.
I'm an execution and infrastructure builder, not an institutional quant researcher. I've run liquidation, funding, looping and small delta-neutral strategies. Sophisticated portfolio construction and rebalancing are not my expertise.
THE HONEST MATCH
“Proven” means I can point to a system, test or result. “Adjacent” means there is real transferable depth and a named limitation. “Gap” means gap.
Primary language across production frontend, backend, SDKs and bots.
Purrdict, signed Parlay RFQs and cashout, builder-code execution, liquidators, nodes and market data.
Mute: ClickHouse → NestJS → integration tests → Next.js. Parlay: Solidity → Bun relay → typed SDKs → live UI.
Core builder of Moralis Streams, plus Parlay maker/taker WebSockets, Hyperliquid gRPC block delivery, SSE and signed webhooks.
String/BigInt accounting, fixed e6 collateral identities and decimal.js differential tests.
HyperEVM testnet fills, Anvil/Foundry, ClickHouse test containers, Playwright and shadow traffic.
Felix, Purrdict and MakaPay span trading, risk and payments interfaces in production-grade Next.js.
Hyperliquid REST/WS integration plus a typed maker/taker RFQ relay, streamed state and explicit protocol errors.
Contributed to Moralis's AWS migration; every VM in my current Hyperliquid stack runs on AWS, with S3, SSM, SNS and snapshots around the runtime.
This is application and migration ownership; I am not presenting Terraform as current muscle memory.Connected systems—including the Parlay relay, maker fleet and two SDKs—live in one Bun/Turbo workspace and remain independently deployable.
Mute.sh's current API control plane runs on NestJS 11.
Backend ownership since Moralis in 2022; earlier work was full-stack/onchain.
I won't relabel seven years of crypto as seven backend-only years.Production TypeORM experience earlier in my backend career; current data infrastructure uses deliberate raw ClickHouse SQL, materialized views and aggregate views.
TypeORM is familiar but no longer daily muscle memory. I rely on validation, authorization and parameter binding—not the ORM alone—for injection safety.Moralis Continuum used replayable block/receipt partitions as the source for downstream ETL and query projections; my HyperEVM and HIP-4 pipelines use the same model today.
Continuum is infrastructure-level event sourcing: ordered event history and rebuildable projections, rather than a single-application aggregate store.Payments and transaction infrastructure, but not KYC ownership.
A real gap, not a keyword I can stretch.I use AI for nearly every implementation pass now. The edge is not typing faster; it is turning intent, product taste and repository knowledge into tight feedback loops.
I dictate the intent, constraints, edge cases and doubts before compressing the task. That prevents a lazy one-line prompt from making the model invent the brief.
For product work, I scaffold wireframes and variants first. Weak hierarchy and generic output get rejected before they harden into production code.
The repository and the risk choose the skills—frontend patterns, diagnosis, TDD, security, architecture or release—not one permanent mega-prompt.
Repo-aware agents inspect existing patterns, plan multi-file changes and take independent work in parallel worktrees while I keep the interfaces coherent.
I use the feature, review invariants and run tests, browser checks, builds, logs and live health. Repeatable failures become new repo rules. I own the rollback.
I also encoded failures back into the repository: one rule for Outcome's 14px Tailwind/Figma math, another for the Storybook mobile viewport setting that silently failed. The lesson survives the session.
TypeScript is my expert language. I use AI for almost every implementation pass; my Rust and Python work is AI-assisted and heavily tested. I do not present myself as a Rust or Python specialist. If I cannot explain, verify and operate it, it does not ship.
OPTIONAL DEPTH
The short case is above. These are the systems I would open during a call—not a wall of logos pretending every project is equally relevant.
LIVE / PROPR PRODUCTION API
GET /v1/health/services—THE DECISION
Give me one real problem from your backlog. I'll show you how I would break it down and the closest system I've already shipped.