The Builder-Trader Overlap
There's a specific archetype in the SF crypto scene that doesn't exist anywhere else in the same density: the engineer who degens their own infrastructure. They run the protocol, they LP in it, they front-run the inefficiencies they noticed while debugging it at 2am.
This isn't a moral judgment. It's an observation about information asymmetry. The person who built the matching engine knows which tick sizes get skipped. The person who wrote the AMM knows at what reserve ratio the pool goes parabolic on slippage. That knowledge has value, and the SF scene has normalized building systems that systematically extract it.
The playbook is roughly: build a tool to understand something on-chain, run it long enough to develop an intuition, then use that intuition to trade. Not HFT. Not quant. Just compounding research into edge.
Wallet Tracking as a Research Method
The first primitive everyone learns is wallet tracking. Pick a protocol, find the top 20 wallets by realized P&L, and watch what they do for 30 days. The signal-to-noise ratio is terrible. Most of them will be bots, arbitrageurs, or insiders hedging known catalysts. But the ones who aren't — the ones who are just consistently right — teach you something about market structure that no paper does.
Helius gRPC makes this tractable on Solana. You can stream account state changes at sub-100ms latency, filter by program, and reconstruct position deltas in real time. The RPCsol P&L project came out of exactly this workflow: pulling Helius RPC, computing balance deltas per block, running 15 iterations of optimization across BO, CMA-ES, DE, and TPE to find the attribution algorithm that best explained realized P&L from raw on-chain data.
The meta-lesson: on-chain data is messy. Every wallet balance is a superposition of trades, fees, rebates, and protocol incentives. The interesting research is in the attribution, not the raw numbers.
MEV Exposure Mapping
Once you understand where wallets are making money, the next question is: how much of that is alpha, and how much is someone else's loss? This is the MEV question, and it's more nuanced on Solana than Ethereum because Solana doesn't have mempool MEV in the same form.
The attack surface is different. PAMM pools are vulnerable to oracle manipulation: if you know the oracle update is coming before the AMM reprices, you can sandwich the repricing. Binary options and concentrated liquidity pools amplify this because the payoff curves are nonlinear — a 0.5% oracle move can flip a position.
The PAMM MEV analysis ran Monte Carlo simulations across 10,000 attack scenarios to map how contagion spreads through interconnected AMM pools. The finding that surprised me most: adversarial trades spread furthest through pools with high inventory concentration, not high TVL. A pool with $50M TVL but 80% of liquidity from two wallets is more vulnerable than a $10M pool with broad distribution.
Liquidity Skew and the PMM Edge
The most underexplored area for builder-traders is proactive market making. CLOBs on Solana are competitive — Phoenix, Openbook, the perp DEXes — and the off-chain market makers have significant infrastructure advantages. But AMMs with oracle-based pricing are different. Here, the edge is in the skew mechanics.
A PMM (Proactive Market Maker) adjusts its bid-ask spread dynamically based on inventory position and oracle price. When inventory skews toward Token A, the PMM widens the ask and narrows the bid to attract Token B inflow. The formula is roughly:
skew = (dev² / 8000).min(eff)
ask = eff + skew bid = eff − skew
# A→B: out = in × 1e9 / (P × (1+ask))
# B→A: out = in × P × (1−bid) / 1e9
The PMM dashboard in the Prop AMM project tracks effective spread, inventory ratio, and oracle cycles in real time. The research question: can you predict the optimal base spread parameter given current volatility and liquidity depth? Spoiler: CMA-ES on a rolling 4-hour window converges to a better steady-state than any static parameter.
The Field Manual
If you're building this stack from scratch, here's the order that makes sense:
- Stream first. Set up Helius gRPC or equivalent. Everything else depends on low-latency account state.
- Build a P&L ledger. Track every wallet you care about. Attribution is harder than it looks — iterate on the algorithm, not just the data source.
- Map MEV exposure. For every pool you LP in, compute inventory concentration and oracle update frequency. These predict your bleed rate.
- Parameterize your PMM. Static spreads are suboptimal in every market regime except the one you designed them for. Run optimization loops.
- Dashboard everything. Not for aesthetics. Because the thing you don't monitor is the thing that kills you at 3am.
The SF degen edge isn't secret information. It's information processing at speed, with tooling you built yourself, applied to markets you understand at a protocol level. The moat is the compounding. Every week you run this, the model gets sharper.