I tracked 98 ETH whales for six months. Their direct wallet holdings fell 19.2%—but that does not mean 19.2% was sold. Here’s where 1.37M ETH went across exchanges, staking, Sky, SparkLend, and Aave.

$56.51M flowed into @sparkfinance’s spUSDC V2 in under 40 minutes. A related wallet later moved ~$10M from legacy sUSDC V1 to Hyperliquid before opening an ETH long. A case study of capital moving between market exposure and onchain yield.

Robinhood Earn’s Steakhouse USDG Vault grew from $7.9M to ~$376M in under eight weeks. For @sparkfinance, the next test is turning that distribution into active capital deployment and sustainable revenue.

Three Ethena-linked Aave positions began deleveraging on the same day, withdrawing $85.3m in four days. No direct on-chain link between the wallets. One wallet held 31% of Aave's entire USDe supply.

How does @sparkfinance balance USDT yield, liquidity, and borrowing conditions through large redemptions? Building on @MonetSupply’s public framework, I use onchain data to unpack a $633m spUSDT stress window—what happened to liquidity, rates, and P&L.

A DAO should not start buybacks merely because it is profitable. It should start only after proving the capital is truly excess. @sparkfinance turns this into a live system: Returns → liabilities → operating runway → risk capital → buybacks Here is a framework every DAO can use ↓ ➢ The original DeFi treasury framework In 2021, @hasufl and @MonetSupply proposed a new mental model for DeFi treasuries. Spark puts three of its ideas into practice: • Exclude SPK from treasury assets • Recognize depositor liabilities and set risk-capital requirements • Reserve operating and risk buffers before buybacks ➢ Six questions before any DAO buyback Before any DAO buyback, ask: • Gross or net revenue? • Profit after opex? • Own token counted as treasury? • Unpaid liabilities? • Operating and risk reserves? • Based on accounting profit—or capital left after all required reserves? ➢ Gross returns are not protocol profit Spark Liquidity Layer projects $88.7M in yearly gross returns. After ~$80.4M in capital costs to Sky and Savings V2 depositors, projected net return is $8.3M. For treasury decisions, net return—not gross return—is the relevant figure. ➢ Profit is not yet buyback capacity Spark projects $19.1M in yearly net returns. After the current $14.4M opex override, projected surplus is $4.7M. Hasu's Rule 2: decide whether to retain, reinvest or distribute that surplus. It is not automatically excess capital. ➢ Why SPK is not treasury Spark's net treasury calculation does not count SPK. Hasu's Rule 4: treasury-held native tokens resemble authorized-but-unissued shares, not cash. Turning them into spending power requires selling into the market, creating price impact. ➢ Recognizing liabilities Spark deducts ~$6.7M in yield owed to Savings V2 depositors from treasury. This reflects part of Hasu's Rule 6: money owed to users is a protocol liability—not available treasury. ➢ Operating and risk reserves come before payouts Hasu's Rule 5: hold enough non-native assets to survive a 2–4 year bear market. Rule 6: understand and hedge liabilities specific to the protocol. For a lender, reserves should cover operating costs and potential position losses before payouts. Spark turns that principle into a measurable threshold. RRC is a capital requirement for the risk of Spark's positions—not a realized loss. • Opex: $14.4M override + $1M backstop = $15.4M • Risk: 90-day peak RRC ÷ 90% + $1M = $46.99M The higher value sets the current buyback threshold: $46.99M. ➢ Only excess capital funds buybacks Under SAEP-09, Spark compares Proxy USDS with the current $46.99M target each month. Below target → no standard buyback. Above target → 25% of the difference is allocated to standard buybacks. The target changes with opex and RRC. ➢ What Spark has operationalized Spark's answers: Use net returns. Calculate profit after opex. Exclude SPK. Deduct liabilities. Set reserves from opex and RRC. Fund standard buybacks only from excess capital. My role is to make each step transparent, verifiable and continuously monitored. ➢ Sources and methodology Treasury framework: Spark Financials: SAEP-09: Data: Aug 6, 2026. Projections use current methodology and are not investment advice.

Spark, @Uniswap and @SkyEcosystem have taken the first step toward a Stablecoin FX Layer. Stablecoin issuance is no longer the hard part. Coordination is. Capital already exists, but it sits across isolated pools, venues and ecosystems where it cannot be used efficiently. The first deployment migrated +$150M to Uniswap v4 across the USDS/USDT and USDS/PYUSD pools, one of the largest AMM liquidity migrations in DeFi history. USDS provides the initial quoting foundation, while Spark coordinates allocation through governance defined frameworks. This is where liquidity stops being a passive asset and starts behaving as coordinated infrastructure.

The @Dune dbt migration is done. 287 models. 42 dashboards. All hourly. 🧵 Over the past several weeks — entirely outside my regular work hours — I migrated all 287 dbt models powering @sparkfinance's analytics infrastructure on @dune. 42 dashboards. All refreshing hourly. Production-grade. Done. ➢ What this means for Spark @sparkfinance is one of the most data-driven protocol teams I've worked with. Data here directly informs protocol decisions — numbers need to be right before they're trusted, not after. Over the past year I built 42 @Dune dashboards for @sparkfinance from scratch — covering P&L, user behavior, and protocol-level analytics. The migration made all of that durable, maintainable, and accessible to the whole team — not just to me. ➢ What changed Before: ~100K credits/month. Daily refresh. Logic living in my head. After: Hourly refresh. Incremental models. Full dependency resolution. Every model QA'd against its legacy query before cutover. And one net-new capability: EOH (end-of-hour) snapshots powering Time-Weighted Average P&L — capturing intraday rate spikes that daily snapshots miss entirely. Not possible before. ➢ What made it possible @cursor_ai+ @claudeai + @Dune MCP + a living SOP. By the end: SOP v2.43. 31 dated incidents. Each one root-caused, traced to a specific query, documented, and encoded as a permanent guardrail before moving on. No incident was closed until the root cause was understood. Not the symptom — the cause. That patience is the only reason the pipeline is stable now. Bug → rule → Cursor keeps it in Claude's context → fewer bugs per model. The document became the system's memory. ➢ Why Dune made this possible None of this works without @dune's dbt + Trino stack. Hourly incremental jobs on complex DeFi financials — per-user balances, multi-chain borrow rates, supply indices — at sustainable cost. That's not a given. Thanks to @kdotkrisp @onchain_ben @fr0zensun for the technical support throughout. 🙏 All data logic is now version-controlled in Git. Dune MCP closes the loop — AI can understand not just how the data is built, but how it's consumed in dashboards. The goal was never to be the person who knows everything. It was to build a system that doesn't depend on any one person knowing anything. That's what makes this valuable — the knowledge is in the system now, not in my head. Queryable by anyone on the team, or by AI directly. 287 models. Done. 🚀

99 @dune dbt models. Hourly. Production-grade. Here's the honest version of how we got here. ➢ The beginning was not smooth. Weekend Slack alerts firing. Models broken. Me debugging incremental window logic at 11pm. Every incident got root-caused. Every root cause became a SOP rule. Slowly, the alerts stopped. Not because I got lucky — because the system learned. The turning point wasn't a single fix. It was patience + documentation. SOP v1 → v2.43. Every weekend alert became a permanent guardrail. Now migrations are genuinely smooth. The next model starts from a baseline that has already survived every failure mode we've hit. Big thanks to the @dune team — @kdotkrisp @onchain_ben @fr0zensun — for the technical reviews. They reviewed my incremental model designs, read through a very long SOP, and helped me think through the architecture properly. That kind of support matters. ➢ A thought on web2 vs web3 data work. At my previous big tech job, I had: • A fully managed internal data platform • A dedicated data engineering team to build the tables • Tooling that abstracted away almost everything I was a good analyst. But I was operating inside a very comfortable box. In web3, none of that exists. I own the full stack: upstream event indexing → dbt models → incremental design → CI validation → dashboard cutover. It's harder. But I enjoy it more. Because now I understand the entire data supply chain — not just the last mile. And an analyst who understands the full stack is significantly harder to make obsolete. That's what I mean by antifragile. The friction was the point.

41 production dbt models migrated in ~20 hours this week — including full data quality validation against legacy outputs before every cutover. And yes — I completely burned through my Cursor monthly quota doing it. Here's the workflow that made it possible. 🧵 ➢ The stack: @cursor_ai + @claudeai + @dune MCP + a living SOP Every model follows the same loop: 1. Author in Cursor with Claude Cursor keeps the SOP in-context across the entire session. Claude writes the SQL. Known Trino failure patterns (integer division, USING join resolution, sequence() 10k limit) are in-context before they become bugs — because the SOP is always there. I've tested other models. Claude still produces the fewest SQL bugs on Trino-specific edge cases. Not close. 2. Validate on Dune FULL OUTER JOIN new vs legacy. Every metric. Every day. The gate runs before cutover — not after. 3. Update the SOP Every edge case becomes a guardrail. The next migration starts from a better baseline. ➢ The SOP isn't documentation. It's a feedback loop. Bug → rule → Cursor keeps it in Claude's context → fewer bugs per model. By model 47, the failure modes in the SOP are all real — each traced to a dated incident with root cause and fix. The document became the system's memory. ➢ Why this matters — and why Dune made it possible Complex DeFi financials (per-user balances, supply indices, borrow rates across chains) used to refresh once a day at best. Dune's dbt + Trino stack makes hourly incremental jobs on this data actually viable — at sustainable cost. That's not a small thing. Hourly on-chain financial data, production-grade, open to the ecosystem. Thanks to @dune and the team ( @onchain_ben @fr0zensun @kdotkrisp @Maria) for building infrastructure that makes this real. 🙏 ➢ Why I care this much about accuracy @sparkfinance is one of the most data-driven teams I've worked with. Data here isn't a dashboard for show — it directly informs protocol decisions. The team asks hard questions. Numbers need to be right before they're trusted, not after. That standard is what pushed me to build the validation gate in the first place. Working with a team that respects data rigor pushes you to build better systems, not just better dashboards. I'm grateful for that.

I just shared a workflow with stakeholders @sparkfinance — get data insights directly through @claudeai + @Dune MCP, no analyst needed. 🧵 ➢ The workflow: 3 steps 1. Identify the right dashboard Match the stakeholder's question to the relevant dashboard. Each dashboard sits on top of pre-validated intermediate tables I maintain — two reasons this matters: • Accuracy — data is validated before AI even touches it • Cost — pre-aggregated tables consume far fewer Dune credits than pulling raw on-chain data 2. Drop the dashboard URL into Claude No SQL. No data wrangling. Just a prompt. 3. Keep drilling down in the same chat The tables are granular enough for follow-up questions without starting over. ➢ Why dashboards? Raw tables are slow and error-prone. Dashboards are pre-validated, pre-aggregated, and always fresh. You get accurate data instantly — and the AI can reason on top of it without guessing. ➢ Example prompt for SparkLend weekly analysis: Please use Dune MCP to pull the latest data from these dashboards. Summarize key changes over the past 7 days: TVL, utilization, whale activity, top risks. One message. One minute. Done. ➢ Somewhere along the way, I became the AI's data engineer. I build the tables. I validate the logic. I maintain the pipelines. The AI does the analysis. Honestly? I'm fine with that. That's what frees me up to learn more, ask better questions, and do the work that actually matters. Setup Dune MCP: Thanks @Dune for building this — making it genuinely easy to bring AI into on-chain data workflows. 🙏 cc @blstamm11 @kdotkrisp @fr0zensun

🚨 UPDATE: The rsETH exploit exposed a different risk than I predicted What I warned (April 14): Aave's $8.6B looping amplifies market crashes What happened (April 18): A security breach froze the protocol But the root cause is the same: concentrated collateral dependency ➢ The attack (April 18, 17:38-17:43 UTC) Attacker executed 4 rapid transactions: 1️⃣ Supply 1 rsETH → Borrow 0.98 WETH (test) 2️⃣ Supply 5,000 rsETH → Borrow 4,924 WETH 3️⃣ Supply 20,000 rsETH → Borrow 19,745 WETH 4️⃣ Supply 27,999 rsETH → Borrow 27,771 WETH Total: 53,000 rsETH → 52,440 WETH borrowed (~$120M) Result: WETH drained → stablecoin markets locked → $5.08B frozen Attacker: (Labeled by @zachxbt as "Kelp DAO Exploiter 3" | Funded by Tornado Cash) ➢ Why Spark survived Jan 20, 2026 (88 days before): Spark froze rsETH citing "concentrated usage" But the real difference: Strategic choices Spark: • Looping exposure: $519M (controlled) • rsETH: Froze in January • ETH max rate: High (deters loopers) • Current WETH liquidity: $66.5M available Aave: • Looping exposure: $8.6B (aggressive) • rsETH: Kept live until exploit • ETH max rate: 10% (attracts loopers) • Current USDT/USDC liquidity: $0 available (5.05B 100% utilization) Spark chose safety over growth. ➢ The real danger ahead @MonetSupply's warning: "At 100% utilization, liquidations can't execute. A 15-20% ETH drop could cause significant bad debt on Aave (on top of the rsETH exploit)." Translation: • Trigger was different (security breach vs market crash) • But the systemic risk is identical: over-concentrated collateral + no liquidity buffer • The real test comes if ETH drops Original analysis: Live data: |

63% of DeFi lending appears to be leverage stacking—while real demand shrinks I analyzed 6 months of data across the top 3 lending platforms @aave @sparkfinance @Morpho. The results suggest a concerning trend ↓ ➢ The shift from Nov 2025 → Apr 2026 Peak (Nov 2025): • Real demand (BTC/ETH collateral → borrow stablecoins): $9.3B (43%) • Looping (same-asset leverage): $12.1B (57%) Now (Apr 2026): • Real demand: $6.3B (37%) • Looping: $10.6B (63%) Real borrowing is shrinking—while the circular leverage ratio climbs. ➢ What's the difference? Real demand: Deposit BTC/ETH → borrow USDC/USDT (actual utility - pay bills, invest, etc.) Looping: Deposit wstETH → borrow WETH → deposit WETH → borrow more WETH (just stacking leverage on same asset) One creates economic value. The other just inflates TVL. ➢ Current breakdown by platform Real borrowing vs Looping: • SparkLend: $461M (47%) vs $519M (53%) • Aave V3: $4.99B (37%) vs $8.60B (63%) • Morpho: $822M (36%) vs $1.43B (64%) Note: Spark maintains the highest real demand ratio at 47%—closer to balanced lending ➢ What's actually being looped? Note: Classification based on collateral-borrow asset pairs. Some same-asset borrows may have legitimate use cases, but the pattern suggests significant leverage stacking. Breaking down the $10.6B in likely circular leverage: • Spark ($519M): 93% is wstETH → WETH (likely looping) • Aave ($8.6B): 70% ETH-based + 21% USDe-based (high leverage risk) • Morpho ($1.43B): 52% stablecoin + 12% ETH-based (potential loops) The danger: When ETH drops 20%, these loops force-liquidate in waves—amplifying the crash ➢ Why this matters Recent debate: Is DeFi underpricing risk vs TradFi rates? The real issue isn't just pricing—it's hidden leverage That $10.6B in likely loops isn't "low-risk collateral"—it's leverage stacking that amplifies systemic risk TVL metrics hide the fact that most "borrowing" is just users leveraging the same asset ➢ What we should measure instead Start tracking: ✓ Real collateral → stablecoin borrows (actual utility) ✓ Non-circular capital efficiency (real demand) The protocols that thrive long-term will be the ones users actually need—not just farm