Projects

Problem

Evaluating a deal's cap table in crypto means answering questions a spreadsheet can't: which co-investor combinations actually correlate with good outcomes, which Tier 2/3 funds have real winrates vs. reputation, and how capital moves through an ecosystem. I needed a tool that could surface these patterns across 11K+ funds instead of stitching them together manually.

Approach

I indexed 11K+ crypto VC funds into a graph database — entities and edges, not flat tables — because the questions are relational. Built a TypeScript app to query the DB: look up a project's cap table, traverse to co-investors, check their public returns and portfolio overlaps. On top of that, a graph visualization layer to map co-investing patterns across verticals — DeFi, infrastructure, AI-agent, gaming — so you can see clusters instead of reading lists.

Key decisions

• Graph over relational. The value is in traversing networks — fund → portfolio → co-investors → their outcomes. A relational model stores this; a graph model makes it queryable.
• Focus on Tier 2/3 patterns. Everyone knows what a16z does. The real edge is spotting which smaller fund combinations consistently show up around breakout deals.
• Tool, not oracle. The system surfaces structure for a human to evaluate. It doesn't score deals — it makes the first pass faster and more grounded.

Outcome

Used at V3V as part of deal flow triage and BD. Compressed the gap between "this looks interesting" and "here's the investor structure around it" from hours of manual research to minutes. Particularly useful for evaluating cap table strength and spotting when a familiar investor set is real signal vs. noise.

What I learned

The best internal tools don't automate decisions — they change what you can see fast enough to matter. Most of the value came from killing mechanical research work so the team could spend time on judgment calls instead.

Problem

Manual crypto trading loses money because humans react late and trade on emotion. I wanted to test whether an LLM reasoning layer inside a disciplined system could make better decisions — not as a black box, but as one component with clear boundaries.

Approach

I built a set of custom indicators and connected them to TradingView alerts via WSS. When a signal fires, the system pulls DOM data to read current market structure — liquidity, order flow, where the pressure is. An LLM evaluates the signal against that context and produces a structured trade instruction. That instruction goes to a Rust engine with built-in guardrails: position sizing, risk limits, max exposure. The engine executes the trade on Bybit and manages it from there — adjusting stops, scaling out, or requesting an audit from the LLM when conditions shift.

Key decisions

• Separated reasoning from execution. The LLM interprets signals and context. The Rust engine enforces risk. One component should never do both.
• DOM over price-only analysis. Price candles miss what's happening in the orderbook. DOM data shows where real liquidity sits and where it's being pulled.
• Audit loop. The engine doesn't just fire-and-forget. When market conditions change mid-trade, it can request the LLM to re-evaluate — but execution stays in Rust.

Outcome

What started as an exploration of how hard this would be to do properly turned into a live production system on Bybit with real capital. The system handles the full cycle: signal → evaluation → execution → trade management → audit.

What I learned

LLMs are good at synthesizing noisy signals into a structured view faster than I can. They're bad at precise risk management — that's why the Rust layer exists. The useful insight is knowing where to draw the line between the two.