As of May 2026, stablecoins have surpassed $305 billion in market capitalization. Tokenized real-world assets across funds, commodities, and equities have grown more than 420% since January 2025, reaching $36 billion. BlackRock’s BUIDL has crossed $2.4 billion in AUM in under two years. These are not projections. They are proofs that institutional capital is actively bridging the gap between traditional and decentralized finance.

Thanks for reading Onchain Curiosity! Subscribe for free to receive new posts and support my work.

Subscribe

This piece walks through how we got here, why blockchain made it possible, and what tokenization looks like in practice today across stablecoins, funds, commodities, and other asset classes.

1. A Brief History of Financial Markets

Markets have always evolved by removing friction. Each cycle of innovation expanded who could participate and how efficiently capital could move.

Each innovation made a genuine attempt at closing the gap between owning an asset and being able to use it: to trade it, borrow against it, fractionalize it, or move it across borders. Tokenization is the first to address all four simultaneously.

2. How Blockchain Laid the Foundation

Before tokenization could be a serious institutional conversation, three things had to be solved: digital scarcity, permissionless settlement, and trustless verification. Blockchain technology solved all three, beginning with Bitcoin in 2009 and generalized through the smart-contract platforms that followed.

The breakthrough was not any single asset. It was the architecture: a globally distributed ledger that could record ownership and settle transfers without a central counterparty. For the first time, a financial instrument could exist natively as data, auditable, transferable, and programmable, without requiring an intermediary to vouch for it.

Blockchain proved that value could move on a network with the same finality as a wire transfer, but with the openness of the internet. Everything tokenized today inherits from that proof.

From digital scarcity to general-purpose programmability

Once any logic could be encoded into a self-executing contract, the question stopped being “can we put assets on a blockchain?” and became “which assets are worth putting there?”

That shift, from monetary experiment to financial infrastructure, is what made tokenization a credible institutional thesis rather than a crypto-native curiosity. The same rails that secured a peer-to-peer cash system can now secure a money-market fund, a Treasury bill, or a private credit position.

3. Tokenization: Merging TradFi and DeFi

Tokenization is the process of issuing a digital representation of an asset on a blockchain. The asset classes are broad: equities, bonds, funds, commodities, real estate, private credit. The token carries the economic rights of the underlying asset but inherits the properties of the network it lives on: 24/7 settlement, programmable transfer rules, fractional ownership, and composability with other on-chain instruments.

A Treasury bill that takes T+1 to settle in traditional rails can settle in seconds on-chain, be posted as collateral in a separate venue minutes later, and accrue yield while doing so. That is not a minor operational improvement. That is a structural change in how capital works.

To be clear: tokenization is not a replacement for TradFi. It is a rebuild of financial infrastructure on blockchain rails. The same asset managers, custodians, and regulated entities are issuing tokenized products. They are simply using a more efficient set of infrastructure underneath.

4. The State of Tokenization Today

The total market capitalization of tokenized assets now sits above $340 billion when you account for stablecoins, tokenized funds, commodities, and equities. The figures below are as of May 2026, sourced primarily from Token Terminal with supplementary data from Dune, RWA.xyz, and DeFiLlama.

4.1 Stablecoins: the on-ramp and base layer

Stablecoins, with a market cap of $305 billion, are the largest tokenized asset category by far. They function as the cash leg of every other on-chain transaction. They have crossed a threshold where they are no longer a crypto product. They are payments and settlement infrastructure.

Dollar-denominated stablecoins now act as a parallel distribution channel for US Treasury demand. Issuers must hold short-duration government paper as reserves, which directly recycles global digital-dollar demand back into US sovereign debt. That is a macro-level feedback loop worth paying attention to.

4.2 Tokenized funds and treasuries

Tokenized US Treasury and money-market products are the fastest-growing institutional segment. They take a familiar yield-bearing instrument and wrap it in a token that can move, be posted as collateral, or integrate with on-chain credit markets.

BUIDL went from launch to $2 billion in under 24 months. It is now used as reserve backing by other on-chain yield products and accepted as collateral by institutional prime brokers. This is composability in action. A money-market fund that doubles as collateral is a structurally more useful instrument than one that does not.

4.3 Tokenized commodities

Gold has emerged as the dominant tokenized commodity. Tether’s XAUT and Paxos’s PAXG together represent roughly 89% of the category, with combined market cap reaching $5.3 billion, up 289% in fifteen months.

More interesting than the supply figure is the velocity: spot trading volume for tokenized gold hit $90.7 billion in Q1 2026 alone, exceeding the entire 2025 annual figure of $84.6 billion. This is gold being used as a tradable, divisible, 24/7 hedge, not gold sitting in a vault.

4.4 Other tokenized real-world assets

Beyond treasuries and commodities, tokenization is expanding across private credit, equities, real estate, and ETFs. Each segment is at a different stage of maturity.

Total tokenized RWAs excluding stablecoins reached $37 billion in May 2026, a 420% increase since January 2025. Including stablecoins, the broader tokenized asset universe sits at roughly $341 billion and growing.

Signing off…

The question is no longer whether tokenization is real. We have witnessed the world’s largest asset manager running a tokenized fund worth $2B, even as the RWA market keeps exploding with $305B in stablecoin, $37B across tokenized funds, commodities and equities.

The more important question is what happens when these tokenized assets stop sitting in isolation and start working together. When a Treasury token earns yield, secures a loan, backs another product, and trades on an open market, all at once. That capability is possible with composability, and it is the subject of the next research piece.

I will leave you with this:

The next decade of finance will not be about TradFi or DeFi, but tokenization to make the existing financial system more accessible and efficient to all.

Sources and Data

RWA.xyz, DeFiLlama, CoinGecko, BlackRock / Securitize, Token Terminal, Dune Analytics. All figures as of May 2026 unless otherwise stated.

Disclaimer: This is research commentary, not investment advice. The author may have positions in assets discussed.

Thanks for reading Onchain Curiosity! Subscribe for free to receive new posts and support my work.

Subscribe

Despite this growing interest, one of the single biggest barriers stopping institutional capital from flowing into digital assets is not regulation, custody, or liquidity. It is the absence of a rigorous, repeatable research process.

Most institutional investors who explore crypto encounter the same problem: the analytical frameworks they use for equities, fixed income, and alternatives do not translate cleanly. Price-to-earnings ratios do not apply. There are no audited financials. Digital assets trade 24 hours a day, seven days a week, on dozens of exchanges simultaneously.

This article is a practical guide to how institutional analysts should approach crypto research and valuation, built on the same frameworks I have developed and delivered for traditional asset managers entering the digital asset space.

Why Standard Equity Research Falls Short

In traditional markets, an analyst evaluates a company through its financial statements, management quality, competitive position, and valuation multiples derived from earnings or revenue.

Crypto assets have analogues to all of these, but the data lives on-chain, not in a 10-K. The equivalent of a financial statement is a Dune Analytics dashboard. The equivalent of a revenue figure is protocol fees. The equivalent of a P/E ratio is a Price-to-Sales or Price-to-Fees multiple. The frameworks exist. They just require translation.

This article is a deep dive into the core pillars that institutional investors should explore when evaluating any digital asset. Each pillar answers a different question. Fundamentals asks: is this a real project with real people building something real? On-chain metrics asks: is anyone actually using it? Tokenomics asks: does the token structure reward long-term holders or punish them? Valuation asks: is it cheap or expensive relative to what it produces? Risk asks: what can go wrong, how likely is it, and does the return justify it?

Let us work through each.

1. Fundamentals- Is This Worth Analysing At All?

Before any quantitative work, an institutional analyst must answer a qualitative question: does this project pass a basic credibility screen? Here are a few pointers to help you answer it clearly.

Product and Technology

The first question is simple: is the product live? A project with a working mainnet deployment and completed security audits is categorically different from one with a whitepaper and a roadmap. Your analysis should focus on assets where the technology is operational, audited by at least two reputable firms, and demonstrably differentiated from competitors.

Roadmap execution matters as much as the roadmap itself. A team that consistently ships on schedule signals operational discipline. A team that repeatedly delays signals the opposite.

Team

Anonymous founders are not automatically disqualifying, some of the most important protocols in crypto were built by pseudonymous teams. But for assets targeting institutional capital, verified identities, relevant professional backgrounds, and demonstrable track records carry significant weight. The question is not just who they are, but whether they have built and shipped something before.

Investors and Backing

The quality of institutional backing matters. A Tier 1 venture capital lead, Paradigm, a16z, Dragonfly Capital, indicates that sophisticated investors with information advantages conducted their own diligence and made a conviction bet. This does not eliminate risk, but it meaningfully reduces the probability of outright fraud.

Tokenomics

Supply dynamics determine whether token holders are structurally advantaged or disadvantaged over time. The key questions: Is there a maximum supply or is issuance uncapped? What is the annual inflation rate? Does the protocol generate revenue that flows back to token holders through buybacks, burns, or fee distribution? Are there active demand drivers beyond speculation?

A token with uncapped supply, no value accrual mechanism, and utility limited to governance is structurally challenging for long-term institutional holding.

Vesting schedules deserve particular attention. An unlock calendar showing significant insider token releases in the near term is a material risk factor that should be explicitly modelled. When insiders can sell at scale, they frequently do.

2. On-Chain Metrics- What the Data Actually Shows

This is where crypto analysis has a genuine advantage over traditional markets. Every transaction on a public blockchain is visible in real time. The equivalent of earnings data is available continuously, not quarterly.

Trading Volume and Liquidity

Raw volume figures are unreliable. Wash trading is endemic on lower-quality exchanges. The relevant metrics are volume trend over 30 and 90 days, the volume-to-market-cap ratio, a healthy range is typically 5 to 20 percent daily, and the quality of exchange listings.

An asset with Tier 1 exchange listings and deep order books is investable at institutional scale. An asset concentrated on low-quality exchanges with thin liquidity is not, regardless of its fundamentals.

For institutional position sizing, market depth analysis is essential: what is the market impact of a $500,000 trade? A $2 million trade? If the answer is material slippage, the position is constrained by liquidity, which will impact profitability.

Active Users and Network Activity

Daily active addresses, monthly active users, and transaction count trends reveal whether a protocol is growing, stable, or declining beneath the surface of its market capitalisation. A common mistake investors make is buying assets with strong price momentum and deteriorating on-chain activity, the divergence is frequently a leading indicator of price correction.

Cross-referencing user metrics against bot activity signals is essential. High address counts that do not correspond to meaningful transaction values often indicate Sybil activity or airdrop farming rather than genuine adoption.

Protocol Revenue

For DeFi protocols, Layer 1 blockchains, and infrastructure tokens, protocol revenue is the closest analogue to operating income. The distinction matters: total fees include payments to liquidity providers; protocol revenue is the portion that accrues to the protocol treasury or token holders specifically.

Revenue trend matters more than the absolute figure. A protocol generating $2 million monthly and growing at 30 percent quarter-on-quarter is a fundamentally different investment from a protocol generating $5 million monthly with revenue in decline.

3. Valuation- Is It Cheap or Expensive?

No single valuation model is sufficient for crypto assets. The institutional standard is to apply multiple models and weight them into a composite view.

Price-to-Fees (P/F)

The crypto equivalent of a price-to-earnings ratio. Calculated as market capitalisation divided by annualised protocol fees.

Comparing P/F ratios across sector peers, DEX versus DEX, lending protocol versus lending protocol, reveals relative valuation. A protocol trading at a significant discount to its sector peers warrants further investigation into why the market is applying a lower multiple.

Price-to-Sales (P/S)

Uses protocol revenue rather than total fees, making it a more conservative measure of value accrual to token holders specifically. Assets with direct fee distribution mechanisms, buybacks, burns, staking rewards funded by protocol revenue, should command a premium P/S relative to assets where fees do not flow to holders.

Network Value to Transactions (NVT)

Calculated as market capitalisation divided by annualised on-chain transaction volume. The crypto equivalent of a price-to-sales ratio for the network itself rather than the protocol layer. This metric applies most meaningfully to Bitcoin, where on-chain transaction volume is a direct expression of network utility and aligns closely to market capitalisation dynamics. For most other assets, particularly DeFi protocols, transaction volume is a poor proxy for value creation, and NVT loses its interpretive clarity.

Elevated NVT relative to historical ranges suggests the market is pricing in significant future growth that on-chain activity does not yet support. NVT near historical lows relative to price has historically correlated with attractive entry points.

Market Value to Realised Value (MVRV)

The MVRV ratio compares current market capitalisation to realised capitalisation, the aggregate cost basis of all tokens at the price they last moved.

An MVRV above 3.0 has historically indicated that the market is in a distribution zone where holders are in significant aggregate profit and incentivised to sell. An MVRV below 1.0 indicates that the average holder is at a loss, historically coinciding with accumulation opportunities.

MVRV is most reliable for Bitcoin and Ethereum, where the data set is long and deep. For newer assets, interpret with appropriate caution and note data limitations explicitly in any research output.

Composite Valuation

A defensible valuation view weights all four models and produces a composite signal: cheap, fair, or expensive relative to peers and history. No single model should drive a recommendation. Disagreement between models is informative, it forces the analyst to understand why the market is pricing the asset the way it is, which is frequently where the real insight lives.

Not every model applies to every asset. NVT and MVRV are most at home in Bitcoin analysis, where the data history is deep and the network’s primary function is value transfer. For DeFi protocols, lending markets, DEXs, yield aggregators, P/F and P/S are the more useful lenses, because these assets generate measurable, recurring revenue that flows to identifiable stakeholders. Applying NVT to a DeFi protocol produces a number, but not a meaningful one.

The crypto valuation toolkit is still being built. As the asset class matures, particularly with the growth of tokenised real-world assets, on-chain fixed income, and institutional fund products, new valuation frameworks will emerge that are purpose-built for those structures. This guide will be updated as the ecosystem evolves.

4. Risk Assessment, What Can Go Wrong?

Every institutional research output must include an explicit risk framework. This is not a disclaimer. It is analysis.

Risk in digital assets falls across four dimensions.

Protocol Risk

The technical risk specific to the asset itself. Smart contract exploits are the most acute form, DeFi protocols have lost billions to code vulnerabilities. The relevant questions: Has the protocol been audited, by how many firms, and how recently? Has it been exploited before, and how did the team respond? Does it rely on oracle inputs that could be manipulated? Is the code open-source and actively reviewed?

Protocol age matters here. A contract that has held $1 billion in assets for two years without incident has survived meaningful adversarial testing. A newly deployed contract has not.

Market Risk

The exposure to broader crypto market cycles. Digital assets exhibit high correlation during risk-off environments, when Bitcoin declines sharply, most assets decline with it regardless of their fundamentals. Understanding where an asset sits in the risk spectrum matters for portfolio construction: is this a beta trade on the overall crypto market, or does it have a credible case for decorrelation?

Position sizing should reflect this. An asset with strong fundamentals but high beta to Bitcoin requires a different sizing approach than a tokenised Treasury product with minimal price volatility.

Liquidity Risk

The gap between theoretical and operational liquidity. An asset may appear liquid based on exchange-reported volume, but that volume may be concentrated in a small number of trading sessions, dominated by a single exchange, or significantly reduced during stress periods when liquidity is most needed.

For institutional investors, the relevant test is exit liquidity, not entry liquidity. Can the full position be unwound within a defined time window without material market impact? If the honest answer requires assumptions about favourable market conditions, the liquidity risk is being underpriced.

Regulatory and Counterparty Risk

The legal and structural risks that sit outside the blockchain. These include: the regulatory classification of the asset in the investor’s jurisdiction; the custody arrangement and the legal protections if the custodian fails; the risk that a key counterparty, an exchange, an issuer, a bridge operator, experiences an operational or financial failure; and the macro regulatory risk that new legislation changes the legal status of the asset itself.

These risks are not hypothetical. FTX was a counterparty risk event. The SEC’s actions against Binance and Coinbase were regulatory risk events. USDC’s temporary depeg in March 2023 was a custody and counterparty risk event for protocols with concentrated USDC exposure. The institutional framework must account for all of them.

Scoring the Risk

A practical approach is to score each dimension on a simple three-point scale: Low, Moderate, or High. The composite risk rating, the average across four dimensions, feeds directly into the investment recommendation. An asset with excellent fundamentals and an attractive valuation but High regulatory risk and High liquidity risk should not receive the same recommendation as an asset with slightly weaker fundamentals but manageable risk across all four dimensions.

Risk is not a section to complete quickly. It is the section that separates a research report from a pitch deck.

5. Writing the Investment Thesis

The output of this framework is not a price target. It is a structured, scored, falsifiable investment view with a clear recommendation, defined risk factors, and explicit conditions under which the thesis changes.

The Scoring Framework

Assign a score to each of the four pillars, weighted by their relevance to the asset type:

Pillar Default Weight

Fundamentals 25%

On-Chain Metrics 30%

Valuation 25%

Risk Assessment 20%

Score each pillar from 0 to 100. The weighted composite produces an overall score. Assets scoring above 70 warrant a constructive recommendation. Assets scoring below 40 do not. The 40-to-70 range requires a judgment call, typically a Watch or Accumulate on weakness.

These weights should be adjusted for asset type. For a Layer 1 blockchain, on-chain metrics carry more weight. For a tokenised real-world asset, fundamentals and risk dominate. The framework is a structure, not a formula.

The Recommendation

A recommendation belongs to one of five categories: Buy, Accumulate, Hold, Reduce, or Watch. Each has a specific meaning:

Buy means the risk-adjusted return profile is sufficiently attractive to initiate a full position at current prices. Accumulate means the thesis is constructive but the entry point or position sizing should be built gradually, typically because liquidity is thin or near-term catalysts are uncertain. Hold means the thesis remains intact for existing holders but the current price does not offer sufficient margin of safety to add. Reduce means one or more key thesis components have deteriorated and the position should be trimmed pending reassessment. Watch means the asset is on the radar but does not yet meet the threshold for allocation, revisit on a specific trigger.

Investment Highlights and Risk Factors

Three to five investment highlights, each specific and falsifiable. Not “strong team” but “team has shipped three audited protocol upgrades in the past 12 months and reduced protocol fee take-rate from 15 to 10 basis points in response to competitive pressure, evidence of market sensitivity and operational execution.”

Three to five risk factors, each with an explicit probability assessment, Low, Moderate, or High, and a corresponding impact if realised. Risk factors without impact assessments are incomplete.

The Bear Case

The bear case is not optional. It states, specifically, what would need to be true for the thesis to fail. Not “the market could decline”, that applies to everything. The bear case for a specific asset might be: “If the upcoming token unlock in Q3 2026 results in net selling pressure that suppresses price below the $0.80 support level for more than 30 days, the thesis on price appreciation is invalidated and the hold becomes a reduce.”

Any research output that presents only the positive case is promotional material, not analysis. Institutional readers know the difference. They dismiss the former without a second look.

The Review Trigger

Every research report should state explicitly what data point, if it changes, would prompt a reassessment before the next scheduled review. This could be a revenue threshold, a regulatory decision, a token unlock event, a smart contract incident, or a TVL inflection. The review trigger operationalises the thesis; it converts an opinion into a monitored position.

Closing Thoughts

The institutional crypto market is not waiting for better assets. It is waiting for better analysis.

The frameworks covered in this guide, fundamentals screening, on-chain metric analysis, multi-model valuation, structured risk assessment, and a scored investment thesis, are not crypto-native inventions. They are the tools that institutional analysts have applied to equities, credit, and alternatives for decades, translated into the language of a market where the data is on-chain, available in real time, and accessible to anyone willing to learn the tools.

Thanks for reading Onchain Curiosity! Subscribe for free to receive new posts and support my work.

Subscribe

The opportunity is specific: institutions need analysts who can move fluently between a Dune dashboard and a Bloomberg terminal, between protocol fee revenue and fixed income yield spreads, between on-chain wallet cohort behaviour and fund flow analysis. That analyst does not yet exist at scale. The gap is open.

This is the first guide in my series simplifying crypto investing for institutional investors. Each issue of Onchain Curiosity will go deeper on one component of this framework, from protocol revenue analysis to RWA valuation methodology to building alpha signals from on-chain data. Follow for weekly research and analysis.

#CryptoResearch #InstitutionalInvesting #DigitalAssets #DeFi #OnChainAnalysis #AssetManagement #Blockchain #RWA

Drift Protocol is one of the few crypto projects that has actually found product-market fit and built a real business model. Revenue grew 193% in 2025. The valuation is at an all-time low. The institutional backing is credible. None of that overrides a $285 million governance exploit attributed to North Korean state actors that remains partially unresolved.

This report is the second in my series applying the institutional crypto research framework. The purpose is twofold: to produce a rigorous investment view on DRIFT, and to demonstrate how the framework surfaces risk that a price-focused or momentum-focused approach would miss entirely.

What Works (Pre-Exploit Thesis)

• Revenue grew 193% in 2025, from $14M to $41M. Q4 2025 was an all-time high across multiple exchange metrics.

• The P/F ratio is approximately 0.87x, the lowest multiple in DRIFT’s history and well below the sector average of 3–8x. The asset is trading below its annual revenue run rate.

• Drift v3, launched in December 2025, delivered 10x faster fills and improved liquidity depth. It is the closest thing to a CEX experience on a DEX.

• A $147.5M recovery package has been secured post-exploit. Tether committed $127.5M, including a $100M credit line. That is not a vote of no confidence.

• Four years of consistent protocol development through bear and bull cycles. One of the few DeFi teams that built a cash-flow-positive business.

What Went Wrong (Post-Exploit Reality)

• $285 million drained in 12 minutes via a governance exploit. Root cause: zero-timelock migration, durable nonce abuse, compromised multisig. Attribution: DPRK-linked actors with medium-high confidence.

• The protocol is suspended. TVL dropped from roughly $550M to roughly $250M. Every metric is currently zero while the protocol is offline.

• Recovery token issuance creates uncertain dilution. Terms are not finalised. Any conversion mechanism to DRIFT creates sell-side pressure during the recovery window.

• Competitors have a window. Pacifica and Jupiter Perps are marketing aggressively to displaced Drift users during the downtime.

• Regulatory scrutiny has accelerated. DPRK attribution draws OFAC attention. Circle’s inaction during the exploit has triggered federal scrutiny that affects DeFi governance reform broadly.

01 · Let’s start from Fundamentals

The first question the framework asks is simple: is this a real project with real people building something real? Before April 1, the answer for Drift was clearly yes. The product is live, differentiated, and revenue-generating. The team has a track record. The backing is credible. What changed is the governance security layer, and that changes the fundamental assessment materially.

Product and Technology

Drift has been live on mainnet since December 2021. The product suite covers perpetual futures, spot trading, lending, staking, and earn products across 40+ supported collateral tokens. Version 3, launched December 4, 2025, delivered gasless trading by default alongside significant improvements in fill speed and liquidity depth.

The differentiation is real. Drift’s hybrid liquidity model combines JIT Auctions, a Decentralised Limit Order Book, and a virtual AMM. This is architecturally distinct from the centralised order books used by competitors. Drift Institutional (launched May 2025) and the Apollo Credit RWA integration via Securitize demonstrate the team’s ability to structure institutional-grade products, not just retail trading tools. That matters to the audience this report is written for.

Team

Co-founders Cindy Leow and David Lu are public, identifiable, and credible within the Solana ecosystem. They built through the 2022 crypto crash and kept shipping. Post-exploit communications have been transparent and timely, with preliminary findings published within four days of the incident, including attribution analysis and a description of the attack vector. That is a higher standard of transparency than most exploited protocols meet.

The governance failure reflects an operational gap, not a character gap. The team was socially engineered by a state-level adversary over several months. That is a different category of failure from negligence, and it matters to how you assess recovery probability.

Investors and Backing

Drift completed a Series B in 2024. Decentralised.co increased its investment in March 2026, one week before the exploit, citing Drift’s long-term positioning in on-chain capital markets and RWAs. Post-exploit, Tether’s $127.5M recovery commitment is the strongest institutional signal of confidence available. Smart money is not running.

Tokenomics

The supply structure is cleaner than most DeFi peers. Hard cap of 1 billion tokens. Approximately 61% is now circulating. Major investor cliffs passed in November 2025, and the remaining unlocks are usage-driven emissions tied to protocol growth, not front-loaded insider distributions. Community allocation exceeds 50% of total supply. Vesting extends to 2029 with linear release, which reduces supply shock risk.

The open question is the recovery token. Drift has announced it will issue a recovery token settled in USDT to compensate affected users. Terms are not finalised. If the recovery token creates any conversion pathway to DRIFT, it introduces sell-side pressure during the recovery window. This must be resolved before tokenomics can score cleanly.

Analyst note: When applying the tokenomics screen, the question is not just whether the supply schedule looks clean on paper. It is whether any near-term event creates forced selling pressure. The recovery token is exactly that kind of event, an unquantified supply overhang that must be monitored closely. Always model the unlock calendar against the near-term price catalyst environment.

02 · On-Chain Metrics

This is where crypto analysis has a genuine advantage over traditional markets. Every transaction on a public blockchain is visible in real time. For Drift, the pre-exploit data told a story of accelerating growth. The exploit froze that story mid-sentence.

Trading Volume and Liquidity

Before the exploit, Drift’s volume trajectory was one of the strongest in the Solana DeFi ecosystem. On July 18, 2025, daily perpetual futures volume briefly surpassed $1 billion, making Drift the second-largest perp DEX globally. Q4 2025 daily average volume of $268 million was more than double the Q2 2024 figure. Current volume is zero.

At $21.8M market cap and thin post-exploit order books, institutional position sizing is severely constrained until the protocol demonstrates recovery volume. For institutional investors, the relevant test is exit liquidity, not entry liquidity. That test cannot be run right now.

Active Users and Network Activity

The FUEL rewards programme ended in 2025 with over 22,000 eligible wallets. DIP 9 passed with 99.3% approval, demonstrating a genuinely engaged governance community. These are signals of real adoption, not bot-inflated metrics.

The post-exploit question is retention: will users return when the protocol reopens, or will the combination of lost funds, downtime, and competitor alternatives permanently impair the active user base? This is the single most important on-chain metric to monitor in the 30 days following reopening. If TVL recovers above $300M within 30 days, the user thesis is intact. If it stalls below $150M, the revenue base that justified the pre-exploit valuation is structurally impaired.

Protocol Revenue

Revenue trend matters more than the absolute figure. Drift’s revenue grew 193% in 2025. Protocol earnings, the portion remaining after incentives, grew 519% in two years. That is the closest thing DeFi has to operating leverage. A protocol generating $41M in annual revenue with a $35.6M FDV is priced below its annual revenue run rate. That does not happen to healthy, growing protocols under normal circumstances.

These circumstances are not normal. Revenue is currently zero. The recovery scenario requires the protocol to reopen, demonstrate user return, and rebuild the revenue run rate, all under competitive pressure from protocols that did not have a $285M outflow event.

Analyst note: A common mistake is buying assets with strong historical metrics and assuming those metrics persist. The divergence between Drift’s strong 2025 revenue trajectory and its post-exploit on-chain state is a case study in why the framework scores the current state, not the last clean reporting period. Always re-score with live data.

03 · Valuation

No single valuation model is sufficient for any crypto asset. For Drift, the models that apply all tell the same story: the asset is trading at an extreme discount to fundamental value. The problem is that a compelling valuation on a suspended protocol is not the same thing as a mispriced asset operating normally.

Price-to-Fees (P/F)

The P/F ratio is the crypto equivalent of a price-to-earnings multiple, calculated as market capitalisation divided by annualised protocol fees. At an FDV of $35.6M against $41M in 2025 annual fees, Drift’s P/F is approximately 0.87x. The sector average for perpetual DEXs sits between 3x and 8x. At its peak in 2024, Drift traded at an 80x P/F multiple. A protocol trading below 1x its annual fees is either fundamentally broken or deeply mispriced. The exploit is what separates those two interpretations.

Price-to-Sales (P/S)

The P/S ratio uses protocol revenue rather than total fees, making it a more conservative measure because it only counts fees that accrue to the protocol treasury or token holders. For Drift, 2025 protocol revenue and total fees are closely aligned because Drift’s revenue structure is largely direct-to-protocol. The P/S comes out at approximately 0.87x, identical to the P/F. Both metrics point to the same conclusion: extreme discount relative to peers and relative to Drift’s own history.

NVT Ratio

NVT, calculated as market cap divided by annualised on-chain transaction volume, is most meaningfully applied to Bitcoin and assets where on-chain transaction volume directly reflects network utility. For a perpetual DEX like Drift, traders using leverage amplify notional volume significantly without generating proportionate value. Applying NVT to Drift produces a number, but not a meaningful one. NVT is excluded from the composite. This is exactly why the framework requires analysts to adjust model application by asset type.

MVRV

MVRV compares current market cap to realised capitalisation, which is the aggregate cost basis of all token holders at the price their tokens last moved. An MVRV below 1.0 historically indicates the average holder is underwater, which has correlated with accumulation opportunities. For DRIFT at $0.036, down over 80% from its highs, the estimated MVRV is approximately 0.3x, deep into the historical accumulation zone. The data set is shorter than Bitcoin or Ethereum, so this reading requires appropriate caution, but the directional signal is consistent with the P/F and P/S conclusions.

Composite

Model Current Benchmark Signal P/F Ratio ~0.87x 3–8x (perp DEX peers) Extreme discount P/S Ratio ~0.87x 5–12x (sector avg) Significant discount NVT Ratio N/A — Excluded MVRV ~0.3x (est.) <1.0 = accumulation Deep accumulation zone

The valuation paradox: Drift is simultaneously the cheapest it has ever been on a fees-based multiple and the most operationally impaired it has ever been. The question is not “what is fair value if the protocol operates normally?” It is “what is the probability-weighted expected value accounting for recovery, competitor displacement, and regulatory risk?” The valuation score of 10/15 reflects the genuine fundamental case, not a buy signal in isolation.

04 · Risk Assessment

Risk is not a section to complete quickly. It is the section that separates a research report from a pitch deck. For Drift, the risk section overrides every other positive signal in this report.

How the Exploit Happened

The attack was not a smart contract bug. Drift had been audited by Trail of Bits in 2022 and ClawSecure in February 2026. Both gave passing grades. Smart contract audits cannot detect months-long social engineering campaigns. That is the first lesson.

The attack began in Fall 2025 when threat actors, identified with medium-high confidence as UNC4736/Citrine Sleet, a North Korean state-affiliated group, began posing as a quantitative trading firm and building relationships with Drift contributors. By March 2026, they had accumulated enough trust to influence governance decisions.

On March 27, 2026, a Security Council migration removed the protocol’s governance timelocks. Using Solana’s durable nonce feature, the attackers had convinced Security Council members to pre-sign transactions that appeared legitimate but contained hidden admin transfer instructions. When the timelock was removed, nothing stood between the attackers and protocol control.

On April 1, 2026 at 16:05 UTC, the attackers activated the pre-signed transactions, gained admin control, whitelisted a fabricated token with infinite borrowing limits, deposited 500 million CVT, and withdrew $285 million in USDC, SOL, ETH, and JLP in approximately twelve minutes.

The critical governance red flag: The zero-timelock migration on March 27 was the exploitable window. Any analyst monitoring Drift’s governance activity on-chain had a five-day detection period before the exploit executed. This is exactly why on-chain governance monitoring is not optional in the risk framework. The biggest risks in mature DeFi protocols no longer live in smart contract code. They live in governance processes, multisig hygiene, and operational security. If you are not monitoring governance as closely as you monitor on-chain metrics, you are not doing risk analysis.

05 · Investment Thesis

Recommendation: WATCH · Score: 59/100 · Rating: C

Drift has three things going for it: a four-year track record of genuine business building, an extreme valuation discount at below 1x revenue, and credible institutional backing for recovery. It has one thing working against it that outweighs all three right now, which is an unresolved $285M governance exploit attributed to state actors.

The recommendation is WATCH because the conditions for allocation have not been met, not because the long-term thesis is broken.

Upgrade to Accumulate requires all of the following:

• Independent post-mortem published and verified by a Tier 1 security firm

• Governance timelocks restored and confirmed on-chain

• Security re-audit completed (Trail of Bits or equivalent)

• Protocol reopened with >$200M TVL within 30 days

• Recovery token terms confirmed as non-dilutive to DRIFT holders

Downgrade to Avoid is triggered by any one of:

• Protocol remains suspended beyond 60 days with no clear reopening timeline

• TVL fails to recover above $100M within 90 days of reopening

• Regulatory action (OFAC or SEC) against the protocol or its operators

• Second security incident during the recovery period

Bear Case

If TVL stabilises below $150M post-reopening, annualised revenue likely falls below $15M. At that run rate, the P/S multiple re-expands above 2x and the valuation advantage narrows significantly. The recovery thesis requires the revenue engine to restart, not just the protocol. If users do not return to the platform in meaningful numbers within 90 days of reopening, the thesis is invalidated.

Review Date: 60 days post-protocol reopening. Monitor: post-mortem verification status, security audit completion, TVL recovery trajectory (the $300M threshold matters), recovery token terms, and any OFAC or SEC action related to the DPRK attribution.

Why This Case Study Matters

Drift is the most instructive asset the ChrisOnchain framework has encountered because it perfectly demonstrates the lesson at the core of institutional research: risk drives the recommendation, not valuation.

Pre-exploit, Drift scored a B+ on every dimension. The risk pillar scores near zero and the recommendation becomes WATCH.

An analyst focused only on the valuation discount would have missed the governance red flag on March 27, the zero-timelock migration that opened the five-day window before the exploit. The framework is not designed to find cheap assets. It is designed to find cheap assets that are also safe to own. That distinction is what separates institutional research from a price chart.

ChrisOnchain Research · DRIFT · April 2026 · For educational purpose only · Not investment advice

Thanks for reading Onchain Curiosity! Subscribe for free to receive new posts and support my work.

Subscribe

For most of its history, using Ethereum meant controlling a private key. A long string of characters that, if you had it, gave you full access to your funds. If you lost it, you lost everything. No recovery, no appeals, no second chances. Transaction rules were rigid, hardcoded, and intentionally minimal.

Today, that model is changing with the introduction of smart accounts.

A smart account is simply an Ethereum account that runs as a programmable smart contract instead of being controlled by a fixed private key. That one shift, from key to contract, is what unlocks everything else.

The technology behind this shift is called Account Abstraction (AA). It’s the infrastructure that makes smart accounts possible, enabling accounts to define their own rules for authorization, gas payment, recovery, delegation, and automation.

Adoption is accelerating. As of March 2026, over 53 million smart accounts have been created, while up to 970 million user operations have been successfully executed. Over 70% of wallets transacting on Worldcoin are already smart accounts, showing that the shift away from traditional accounts is well underway. Momentum increased further after Ethereum’s Pectra upgrade in May 2025, which introduced EIP-7702, bringing smart account capabilities closer to Ethereum’s core design.

This article builds from first principles. No prior deep knowledge assumed. By the end, you’ll understand:

• What Ethereum accounts actually are and why they were built the way they were

• How Account Abstraction works and the three standards powering it: ERC-4337, EIP-7702, ERC-7579.

• What smart accounts are, what they can do, and why they matter

• The ecosystem stack forming around them

• Risks and open questions as adoption accelerates

1. Ethereum Accounts from First Principles

To understand smart accounts, you first need to understand what an Ethereum account actually is under the hood.

Every Ethereum account, whether a wallet or a contract, contains exactly four fields:

• Nonce — counts transactions sent; prevents replay attacks

• Balance — ETH held by the account (in wei)

• Storage Root — reference to contract storage (empty for EOAs)

• Code Hash — hash of deployed bytecode (empty for EOAs)

This structure gives rise to two account types.

Externally Owned Accounts (EOAs)

An EOA:

• Is controlled by a private key

• Can initiate transactions

• Has no executable code

• Cannot customise validation logic

Validation is fixed and simple:

1. Recover signer from signature

2. Verify nonce

3. Check balance

4. Deduct gas

This simplicity was intentional. In 2015, Ethereum prioritised deterministic validation and resistance to denial-of-service attacks. Allowing arbitrary validation logic at the protocol level would have forced validators to execute unpredictable code just to verify transactions, which was an unacceptable security risk.

The tradeoff: EOAs are rigid.

They cannot natively support:

• Multi-signature approval

• Spending limits

• Social recovery

• Alternative authentication (e.g., passkeys)

• Gas abstraction

All rules are baked into the protocol. No exceptions.

Contract Accounts

A contract account:

• Contains bytecode

• Has persistent storage

• Executes custom logic when called

• Cannot initiate transactions on its own

The division of labour is clean:

EOAs initiate. Contracts execute.

This preserved protocol simplicity, but at the cost of user flexibility.

The natural question emerged: Why can’t an account both initiate and execute with programmable rules?

That question led to Account Abstraction.

2. What Account Abstraction Makes Possible

Account Abstraction removes those limits by enabling a new kind of account: a smart account.

Unlike an EOA, a smart account is not controlled by a private key sitting on your device. It is a smart contract that you own and configure. The rules for who can authorise transactions, how gas gets paid, and what happens if you lose access all live in the contract itself, and all of it can be customised.

In practical terms, that means a smart account can support:

• Social recovery — designated guardians can restore access if you lose your key

• Batched transactions — submit multiple actions atomically in one operation

• Spending policies — set limits or require 2FA for large transfers

• Session keys — grant limited, time-bound access for specific dApps

• Alternative signatures — use passkeys, biometrics, or post-quantum schemes instead of ECDSA

Gas payments can be abstracted too. A Paymaster contract can sponsor fees or accept ERC-20 tokens instead of ETH, so users don’t need to hold the chain’s native token just to transact.

The core innovation of Account Abstraction is simple:

Move validation logic from the protocol into user-controlled smart contracts.

Here’s what that means at a glance:

But making this work safely at scale required architectural innovation. That’s where the three standards come in.

3. The Three Standards Powering Account Abstraction

Three standards shape today’s AA landscape, each solving a different layer of the problem:

• ERC-4337 — Application-level abstraction

• EIP-7702 — Protocol-level delegation for EOAs

• ERC-7579 — Modular smart account architecture

Together, they define how smart accounts are built, deployed, and used.

ERC-4337: The Foundation of Smart Accounts

ERC-4337 is the most important of the three. It is the standard that makes smart accounts fully operational, without requiring any changes to Ethereum’s core protocol.

Its core idea: move user transactions into a new parallel infrastructure layer.

Each user intent is encoded in a UserOperation, a structured object containing signatures, gas parameters, paymaster data, and calldata. These go into a dedicated off-chain mempool, not Ethereum’s default transaction pool.

From there, independent nodes called Bundlers collect many UserOperations, simulate each one to confirm it will succeed, pack them into a single Ethereum transaction, and submit it to a standardised EntryPoint smart contract.

The EntryPoint is the trust anchor of the entire system. It calls each smart wallet’s validation logic, checks gas, and executes the bundled calls in sequence. Bundlers earn fees from that single combined transaction.

No consensus-layer changes needed. Users never submit transactions directly to Ethereum; the bundler does. The only participant that still needs an EOA is the bundler itself.

Here are the four key components powering ERC-4337:

1. UserOperation

Not a normal Ethereum transaction. A UserOperation is a structured request containing:

• The account initiating the action

• The intended calldata

• Gas parameters

• A signature

• Optional paymaster data (for sponsored gas)

Think of it as a transaction intent, describing what you want to happen, not how to execute it at the protocol level.

UserOperations go into a separate mempool, not Ethereum’s default transaction pool.

2. Bundlers

A Bundler:

• Collects UserOperations from the off-chain mempool

• Simulates each one to ensure it will validate successfully

• Packages them together

• Submits a single Ethereum transaction to the EntryPoint

Bundlers play a role similar to block builders, but specifically for smart account operations.

3. Paymasters

Paymasters are optional contracts that agree to cover a UserOperation’s gas under custom policies.

They sit between the user and the EntryPoint. When a UserOperation includes paymaster data, the EntryPoint checks with the Paymaster contract first, confirming it’s willing to sponsor the gas before executing anything.

This enables three powerful models:

• Sponsored gas — a dApp pays fees on behalf of its users entirely

• Token-based gas — users pay in stablecoins or other ERC-20 tokens instead of ETH

• Subscription models — flat-fee or prepaid gas arrangements

This is the key unlock for gasless onboarding. New users can interact with a smart account without ever holding ETH, removing one of the biggest friction points for mainstream adoption.

4. EntryPoint Contract

A singleton smart contract, meaning one shared instance for all ERC-4337 smart accounts.

When a bundled transaction arrives:

1. Checks with the Paymaster (if included) to confirm gas sponsorship

2. Calls validateUserOp() on each smart account

3. If validation passes, executes the requested call

4. Handles all gas accounting internally, reimbursing the Bundler

Here’s the full flow:

The crucial design choice: all validation happens inside the EVM and is fully gas-metered. Ethereum’s consensus rules remain unchanged, preserving network safety while enabling fully programmable smart accounts.

EIP-7702: Bringing Smart Account Features to Existing Wallets

ERC-4337 gave smart accounts everything they needed, but it didn’t replace EOAs.

EOAs still exist. They still have special treatment in Ethereum’s core rules. And they’re still the default for most users.

This creates friction. To get the benefits of a smart account, users have to:

• Deploy a new smart account contract

• Fund it separately

• Migrate all their activity

• Manage two mental models at once

EIP-7702, introduced in Ethereum’s Pectra upgrade (May 2025), reduces that barrier significantly.

What it does:

It allows an EOA to temporarily attach executable code to itself for the duration of a single transaction. Once that transaction completes, the account reverts to normal EOA behaviour.

This creates a hybrid model:

• The account remains an EOA

• But it can behave like a smart account when needed

Why it matters:

Instead of forcing users to migrate, EIP-7702 lets existing wallets gradually gain smart account features, enabling:

• Transaction batching

• Sponsored gas flows

• Custom validation logic

• Safer, incremental migrations into full smart accounts

EIP-7702 is also fully compatible with ERC-4337 infrastructure. Wallets using 7702 can still route through ERC-4337 bundlers and paymasters, and users can move at their own pace. Major wallets including MetaMask and Trust Wallet have already shipped EIP-7702 support.

Think of EIP-7702 as the bridge. It lets the billions of existing EOA users begin experiencing smart account features without leaving their current wallet behind.

ERC-7579: Making Smart Accounts Modular and Composable

As smart accounts proliferated, a new problem emerged: fragmentation.

Different wallets implemented incompatible module systems. You couldn’t reuse a validated component across implementations. Security audits couldn’t be shared. The ecosystem was pulling apart just as it was gaining momentum.

ERC-7579 fixes this, not by building another smart account, but by standardising how all smart accounts are structured.

It defines a common modular interface so that any module, whether a signing scheme, a recovery mechanism, or a spending policy, works across any compliant smart account. Build it once, use it everywhere.

Instead of one large wallet contract that does everything, responsibilities are split into plug-and-play components around a minimal account core. Four module types are defined: Validation, Execution, Hooks, and Fallback Handlers.

The modular model:

The smart account becomes a minimal coordination layer. Everything else is installable logic.

Core components:

1. Account Core (Kernel)

Responsible for:

• Holding funds

• Managing nonces

• Installing and removing modules

• Routing calls to the right module

The core stays intentionally small to minimise attack surface. It’s a router, not a feature set.

2. Validation Modules

These define who can authorise transactions on the smart account, under what conditions, and using which signature scheme.

Examples:

• ECDSA validator

• Multi-signature validator

• Guardian-based recovery

• Session key validator

Validation becomes pluggable. Upgrade your signing scheme without redeploying the entire smart account.

3. Execution Modules

These define how the smart account executes calls, whether batching is allowed, whether delegate calls are permitted, and what restrictions apply.

Execution becomes customisable per use case.

4. Hooks

Hooks run pre- and post-transaction logic on the smart account:

• Pre-transaction: enforce spending limits, check policy conditions before a call goes through

• Post-transaction: update internal balances, log activity, enforce policy after execution

This is where a smart account’s rules and guardrails live, not baked into the core, but composable and upgradeable.

5. Fallback Handlers

Fallback handlers define what the smart account does when it receives a call it doesn’t recognise, specifically a function signature no installed module handles.

Rather than reverting by default, a fallback handler lets the account respond gracefully. As new token standards emerge or protocols evolve, the smart account can support them via a new handler, with no full contract upgrade required.

Think of them as the smart account’s catch-all layer. Quietly essential for staying compatible with a living, evolving ecosystem.

Why modularity matters for smart accounts:

Without it:

• Adding features to a smart account increases contract complexity

• Upgrades introduce systemic risk

• Audits become harder and more expensive

• Security boundaries blur

With it:

• Smart account features can be added or removed independently

• Risk is isolated to individual modules

• Signing and recovery logic can evolve without touching the core

• Smart accounts become extensible, auditable platforms

This is more than wallet design. It turns smart accounts into programmable security runtimes, infrastructure you can build on top of, not just use.

How the three standards fit together:

The progression tells a clear story:

• Ethereum (2015) — Fixed EOAs, rigid rules, no programmability

• ERC-4337 — Smart accounts become possible, without consensus changes

• EIP-7702 — Smart account features reach existing wallets

• ERC-7579 — Smart accounts become modular, composable, and interoperable

Ethereum accounts are evolving from static key containers into programmable smart accounts, and the standards to support that are now in place.

4. The Endgame of Smart Accounts

Smart accounts are not just a better wallet. They are the foundation for a fundamentally different relationship between users and on-chain value.

If we follow the trajectory, the destination becomes clear.

Smart accounts become programmable agents. In this world:

• Users authenticate with biometrics, faceID or passkeys, with no seed phrases to lose

• Gas is abstracted away entirely, and users don’t need to know it exists

• Smart accounts enforce your rules automatically: spending limits, approvals, policies built into the account itself

• Permissions are granular and time-bound; grant a dApp $50 of access for 24 hours, then it expires automatically

• Agents transact autonomously on your behalf, within boundaries you define

At that point, the distinction between “wallet” and “smart contract” disappears.

There are only programmable accounts, and they work the way users actually need them to.

5. The Smart Account Ecosystem

Smart accounts are no longer just a standards discussion. A full ecosystem has formed around building, deploying, and scaling them.

Here’s how the layers break down:

Core Standards

ERC-4337, EIP-7702, ERC-7579.

These define how smart accounts function and interact. Everything else builds on top of them.

EntryPoint & Bundler Infrastructure

Bundlers aggregate UserOperations and submit them on-chain. Without a reliable bundler network, smart accounts can’t operate at scale.

Key players: @stackup_fi @pimlicoHQ @Alchemy

Paymasters (Gas Abstraction)

Paymasters sponsor gas or accept ERC-20 tokens instead of ETH, one of the most important unlocks for smart account adoption. They enable:

• Gasless onboarding for new users

• Token-based gas payments

• Subscription-style fee models

Key players: @biconomy, @OpenZeppelin

Smart Account Frameworks

Reusable, audited smart account implementations so developers don’t build from scratch.

Key players: @safe @zerodev_app @rhinestonewtf @candidelabs

Safe is the most battle-tested, securing billions in assets. ZeroDev’s Kernel and Candide are optimised specifically for the ERC-4337 ecosystem, lightweight, modular, and developer-friendly.

Wallet & Consumer Layer

Where smart accounts finally meet end users.

Key players: @baseapp, @ready_co @MetaMask, @phantom, @TrustWallet

Coinbase has made ERC-4337 smart accounts the default for new users. Ready (Argent) pioneered smart account UX long before ERC-4337 existed. MetaMask, Phantom, and Trust Wallet are bringing smart account capabilities to tens of millions of existing users, without asking them to switch wallets.

The stack is maturing fast. What was a fragmented set of experiments two years ago is now a coherent infrastructure layer with clear separation of concerns, competitive markets at each level, and major consumer products driving smart account adoption at scale.

6. Risks and Open Questions

Smart accounts introduce powerful capabilities, but also new tradeoffs worth understanding clearly.

Smart contract risk. Smart accounts are more complex than keypairs. A bug in a validation module can be catastrophic at scale. Complexity invites exploits.

Module trust. A smart account is only as secure as its weakest installed module. Third-party modules require rigorous auditing, and users need to understand what they’re actually installing into their account.

Bundler centralisation. If a handful of bundlers dominate transaction processing, censorship becomes possible. This mirrors the MEV centralisation risk in block building and deserves the same level of scrutiny.

EIP-7702 delegation risk. An EOA that delegates to malicious code, even for a single transaction, can be drained. The security model shifts from don’t lose your key to don’t sign malicious delegation requests. That’s a subtler threat and harder to communicate to everyday users.

UX vs. self-sovereignty. Abstracting key management makes smart accounts easier to use. But if the underlying keys are custodied by a wallet provider, users may be trading self-sovereignty for convenience without fully realising it.

None of these is a dealbreaker. They’re the expected friction of a maturing technology, and the ecosystem is actively working through each of them.

But they’re worth understanding clearly as smart accounts move from early adopters to mainstream defaults.

Ethereum is replacing a rigid, one-size-fits-all EOA model with Smart Accounts. This alternative is programmable, recoverable, and composable, built to match how people actually want to use and manage money.

For developers, Smart Accounts are a new primitive to build on. For users, they are the foundation for a version of crypto that is finally safe and simple enough for everyone.

The shift from EOAs to Smart Accounts may be the most consequential UX change in Ethereum’s history.

And smart account adoption is just getting started.

Thanks for reading Onchain Curiosity! Subscribe for free to receive new posts and support my work.

Subscribe

For most of its history, using Ethereum meant controlling a private key. A long string of characters that, if you had it, gave you full access to your funds. If you lost it, you lost everything. No recovery, no appeals, no second chances. Transaction rules were rigid, hardcoded, and intentionally minimal.

Today, that model is changing with the introduction of smart accounts.

A smart account is simply an Ethereum account that runs as a programmable smart contract instead of being controlled by a fixed private key. That one shift, from key to contract, is what unlocks everything else.

The technology behind this shift is called Account Abstraction (AA). It's the infrastructure that makes smart accounts possible, enabling accounts to define their own rules for authorization, gas payment, recovery, delegation, and automation.

Adoption is accelerating. As of March 2026, over 53 million smart accounts have been created, while up to 970 million user operations have been successfully executed. Over 70% of wallets transacting on Worldcoin are already smart accounts, showing that the shift away from traditional accounts is well underway. Momentum increased further after Ethereum's Pectra upgrade in May 2025, which introduced EIP-7702, bringing smart account capabilities closer to Ethereum's core design.

This article builds from first principles. No prior deep knowledge assumed. By the end, you'll understand:

• What Ethereum accounts actually are and why they were built the way they were

• How Account Abstraction works and the three standards powering it: ERC-4337, EIP-7702, ERC-7579.

• What smart accounts are, what they can do, and why they matter

• The ecosystem stack forming around them

• Risks and open questions as adoption accelerates

1. Ethereum Accounts from First Principles

To understand smart accounts, you first need to understand what an Ethereum account actually is under the hood.

Every Ethereum account, whether a wallet or a contract, contains exactly four fields:

• Nonce — counts transactions sent; prevents replay attacks

• Balance — ETH held by the account (in wei)

• Storage Root — reference to contract storage (empty for EOAs)

• Code Hash — hash of deployed bytecode (empty for EOAs)

This structure gives rise to two account types.

Externally Owned Accounts (EOAs)

An EOA:

• Is controlled by a private key

• Can initiate transactions

• Has no executable code

• Cannot customise validation logic

Validation is fixed and simple:

1. Recover signer from signature

2. Verify nonce

3. Check balance

4. Deduct gas

This simplicity was intentional. In 2015, Ethereum prioritised deterministic validation and resistance to denial-of-service attacks. Allowing arbitrary validation logic at the protocol level would have forced validators to execute unpredictable code just to verify transactions, which was an unacceptable security risk.

The tradeoff: EOAs are rigid.

They cannot natively support:

• Multi-signature approval

• Spending limits

• Social recovery

• Alternative authentication (e.g., passkeys)

• Gas abstraction

All rules are baked into the protocol. No exceptions.

Contract Accounts

A contract account:

• Contains bytecode

• Has persistent storage

• Executes custom logic when called

• Cannot initiate transactions on its own

The division of labour is clean:

EOAs initiate. Contracts execute.

This preserved protocol simplicity, but at the cost of user flexibility.

The natural question emerged: Why can't an account both initiate and execute with programmable rules?

That question led to Account Abstraction.

2. What Account Abstraction Makes Possible

Account Abstraction removes those limits by enabling a new kind of account: a smart account.

Unlike an EOA, a smart account is not controlled by a private key sitting on your device. It is a smart contract that you own and configure. The rules for who can authorise transactions, how gas gets paid, and what happens if you lose access all live in the contract itself, and all of it can be customised.

In practical terms, that means a smart account can support:

• Social recovery — designated guardians can restore access if you lose your key

• Batched transactions — submit multiple actions atomically in one operation

• Spending policies — set limits or require 2FA for large transfers

• Session keys — grant limited, time-bound access for specific dApps

• Alternative signatures — use passkeys, biometrics, or post-quantum schemes instead of ECDSA

Gas payments can be abstracted too. A Paymaster contract can sponsor fees or accept ERC-20 tokens instead of ETH, so users don't need to hold the chain's native token just to transact.

The core innovation of Account Abstraction is simple:

Move validation logic from the protocol into user-controlled smart contracts.

Here's what that means at a glance:

But making this work safely at scale required architectural innovation. That's where the three standards come in.

3. The Three Standards Powering Account Abstraction

Three standards shape today's AA landscape, each solving a different layer of the problem:

• ERC-4337 — Application-level abstraction

• EIP-7702 — Protocol-level delegation for EOAs

• ERC-7579 — Modular smart account architecture

Together, they define how smart accounts are built, deployed, and used.

ERC-4337: The Foundation of Smart Accounts

ERC-4337 is the most important of the three. It is the standard that makes smart accounts fully operational, without requiring any changes to Ethereum's core protocol.

Its core idea: move user transactions into a new parallel infrastructure layer.

Each user intent is encoded in a UserOperation, a structured object containing signatures, gas parameters, paymaster data, and calldata. These go into a dedicated off-chain mempool, not Ethereum's default transaction pool.

From there, independent nodes called Bundlers collect many UserOperations, simulate each one to confirm it will succeed, pack them into a single Ethereum transaction, and submit it to a standardised EntryPoint smart contract.

The EntryPoint is the trust anchor of the entire system. It calls each smart wallet's validation logic, checks gas, and executes the bundled calls in sequence. Bundlers earn fees from that single combined transaction.

No consensus-layer changes needed. Users never submit transactions directly to Ethereum; the bundler does. The only participant that still needs an EOA is the bundler itself.

Here are the four key components powering ERC-4337:

1. UserOperation

Not a normal Ethereum transaction. A UserOperation is a structured request containing:

• The account initiating the action

• The intended calldata

• Gas parameters

• A signature

• Optional paymaster data (for sponsored gas)

Think of it as a transaction intent, describing what you want to happen, not how to execute it at the protocol level.

UserOperations go into a separate mempool, not Ethereum's default transaction pool.

2. Bundlers

A Bundler:

• Collects UserOperations from the off-chain mempool

• Simulates each one to ensure it will validate successfully

• Packages them together

• Submits a single Ethereum transaction to the EntryPoint

Bundlers play a role similar to block builders, but specifically for smart account operations.

3. Paymasters

Paymasters are optional contracts that agree to cover a UserOperation's gas under custom policies.

They sit between the user and the EntryPoint. When a UserOperation includes paymaster data, the EntryPoint checks with the Paymaster contract first, confirming it's willing to sponsor the gas before executing anything.

This enables three powerful models:

• Sponsored gas — a dApp pays fees on behalf of its users entirely

• Token-based gas — users pay in stablecoins or other ERC-20 tokens instead of ETH

• Subscription models — flat-fee or prepaid gas arrangements

This is the key unlock for gasless onboarding. New users can interact with a smart account without ever holding ETH, removing one of the biggest friction points for mainstream adoption.

4. EntryPoint Contract

A singleton smart contract, meaning one shared instance for all ERC-4337 smart accounts.

When a bundled transaction arrives:

1. Checks with the Paymaster (if included) to confirm gas sponsorship

2. Calls validateUserOp() on each smart account

3. If validation passes, executes the requested call

4. Handles all gas accounting internally, reimbursing the Bundler

Here's the full flow:

The crucial design choice: all validation happens inside the EVM and is fully gas-metered. Ethereum's consensus rules remain unchanged, preserving network safety while enabling fully programmable smart accounts.

EIP-7702: Bringing Smart Account Features to Existing Wallets

ERC-4337 gave smart accounts everything they needed, but it didn't replace EOAs.

EOAs still exist. They still have special treatment in Ethereum's core rules. And they're still the default for most users.

This creates friction. To get the benefits of a smart account, users have to:

• Deploy a new smart account contract

• Fund it separately

• Migrate all their activity

• Manage two mental models at once

EIP-7702, introduced in Ethereum's Pectra upgrade (May 2025), reduces that barrier significantly.

What it does:

It allows an EOA to temporarily attach executable code to itself for the duration of a single transaction. Once that transaction completes, the account reverts to normal EOA behaviour.

This creates a hybrid model:

• The account remains an EOA

• But it can behave like a smart account when needed

Why it matters:

Instead of forcing users to migrate, EIP-7702 lets existing wallets gradually gain smart account features, enabling:

• Transaction batching

• Sponsored gas flows

• Custom validation logic

• Safer, incremental migrations into full smart accounts

EIP-7702 is also fully compatible with ERC-4337 infrastructure. Wallets using 7702 can still route through ERC-4337 bundlers and paymasters, and users can move at their own pace. Major wallets including MetaMask and Trust Wallet have already shipped EIP-7702 support.

Think of EIP-7702 as the bridge. It lets the billions of existing EOA users begin experiencing smart account features without leaving their current wallet behind.

ERC-7579: Making Smart Accounts Modular and Composable

As smart accounts proliferated, a new problem emerged: fragmentation.

Different wallets implemented incompatible module systems. You couldn't reuse a validated component across implementations. Security audits couldn't be shared. The ecosystem was pulling apart just as it was gaining momentum.

ERC-7579 fixes this, not by building another smart account, but by standardising how all smart accounts are structured.

It defines a common modular interface so that any module, whether a signing scheme, a recovery mechanism, or a spending policy, works across any compliant smart account. Build it once, use it everywhere.

Instead of one large wallet contract that does everything, responsibilities are split into plug-and-play components around a minimal account core. Four module types are defined: Validation, Execution, Hooks, and Fallback Handlers.

The modular model:

                       Account Core (Kernel)
                   /        |        |        \
          Validation   Execution   Hooks   Fallback
          Modules      Modules             Handlers

The smart account becomes a minimal coordination layer. Everything else is installable logic.

Core components:

1. Account Core (Kernel)

Responsible for:

• Holding funds

• Managing nonces

• Installing and removing modules

• Routing calls to the right module

The core stays intentionally small to minimise attack surface. It's a router, not a feature set.

2. Validation Modules

These define who can authorise transactions on the smart account, under what conditions, and using which signature scheme.

Examples:

• ECDSA validator

• Multi-signature validator

• Guardian-based recovery

• Session key validator

Validation becomes pluggable. Upgrade your signing scheme without redeploying the entire smart account.

3. Execution Modules

These define how the smart account executes calls, whether batching is allowed, whether delegate calls are permitted, and what restrictions apply.

Execution becomes customisable per use case.

4. Hooks

Hooks run pre- and post-transaction logic on the smart account:

• Pre-transaction: enforce spending limits, check policy conditions before a call goes through

• Post-transaction: update internal balances, log activity, enforce policy after execution

This is where a smart account's rules and guardrails live, not baked into the core, but composable and upgradeable.

5. Fallback Handlers

Fallback handlers define what the smart account does when it receives a call it doesn't recognise, specifically a function signature no installed module handles.

Rather than reverting by default, a fallback handler lets the account respond gracefully. As new token standards emerge or protocols evolve, the smart account can support them via a new handler, with no full contract upgrade required.

Think of them as the smart account's catch-all layer. Quietly essential for staying compatible with a living, evolving ecosystem.

Why modularity matters for smart accounts:

Without it:

• Adding features to a smart account increases contract complexity

• Upgrades introduce systemic risk

• Audits become harder and more expensive

• Security boundaries blur

With it:

• Smart account features can be added or removed independently

• Risk is isolated to individual modules

• Signing and recovery logic can evolve without touching the core

• Smart accounts become extensible, auditable platforms

This is more than wallet design. It turns smart accounts into programmable security runtimes, infrastructure you can build on top of, not just use.

How the three standards fit together:

The progression tells a clear story:

• Ethereum (2015) — Fixed EOAs, rigid rules, no programmability

• ERC-4337 — Smart accounts become possible, without consensus changes

• EIP-7702 — Smart account features reach existing wallets

• ERC-7579 — Smart accounts become modular, composable, and interoperable

Ethereum accounts are evolving from static key containers into programmable smart accounts, and the standards to support that are now in place.

4. The Endgame of Smart Accounts

Smart accounts are not just a better wallet. They are the foundation for a fundamentally different relationship between users and on-chain value.

If we follow the trajectory, the destination becomes clear.

Smart accounts become programmable agents. In this world:

• Users authenticate with biometrics, faceID or passkeys, with no seed phrases to lose

• Gas is abstracted away entirely, and users don't need to know it exists

• Smart accounts enforce your rules automatically: spending limits, approvals, policies built into the account itself

• Permissions are granular and time-bound; grant a dApp $50 of access for 24 hours, then it expires automatically

• Agents transact autonomously on your behalf, within boundaries you define

At that point, the distinction between "wallet" and "smart contract" disappears.

There are only programmable accounts, and they work the way users actually need them to.

5. The Smart Account Ecosystem

Smart accounts are no longer just a standards discussion. A full ecosystem has formed around building, deploying, and scaling them.

Here's how the layers break down:

Core Standards

ERC-4337, EIP-7702, ERC-7579.

These define how smart accounts function and interact. Everything else builds on top of them.

EntryPoint & Bundler Infrastructure

Bundlers aggregate UserOperations and submit them on-chain. Without a reliable bundler network, smart accounts can't operate at scale.

Key players: @stackup_fi @pimlicoHQ @Alchemy

Paymasters (Gas Abstraction)

Paymasters sponsor gas or accept ERC-20 tokens instead of ETH, one of the most important unlocks for smart account adoption. They enable:

• Gasless onboarding for new users

• Token-based gas payments

• Subscription-style fee models

Key players: @biconomy, @OpenZeppelin

Smart Account Frameworks

Reusable, audited smart account implementations so developers don't build from scratch.

Key players: @safe @zerodev_app @rhinestonewtf @candidelabs

Safe is the most battle-tested, securing billions in assets. ZeroDev's Kernel and Candide are optimised specifically for the ERC-4337 ecosystem, lightweight, modular, and developer-friendly.

Wallet & Consumer Layer

Where smart accounts finally meet end users.

Key players: @baseapp, @ready_co @MetaMask, @phantom, @TrustWallet

Coinbase has made ERC-4337 smart accounts the default for new users. Ready (Argent) pioneered smart account UX long before ERC-4337 existed. MetaMask, Phantom, and Trust Wallet are bringing smart account capabilities to tens of millions of existing users, without asking them to switch wallets.

The stack is maturing fast. What was a fragmented set of experiments two years ago is now a coherent infrastructure layer with clear separation of concerns, competitive markets at each level, and major consumer products driving smart account adoption at scale.

6. Risks and Open Questions

Smart accounts introduce powerful capabilities, but also new tradeoffs worth understanding clearly.

Smart contract risk. Smart accounts are more complex than keypairs. A bug in a validation module can be catastrophic at scale. Complexity invites exploits.

Module trust. A smart account is only as secure as its weakest installed module. Third-party modules require rigorous auditing, and users need to understand what they're actually installing into their account.

Bundler centralisation. If a handful of bundlers dominate transaction processing, censorship becomes possible. This mirrors the MEV centralisation risk in block building and deserves the same level of scrutiny.

EIP-7702 delegation risk. An EOA that delegates to malicious code, even for a single transaction, can be drained. The security model shifts from don't lose your key to don't sign malicious delegation requests. That's a subtler threat and harder to communicate to everyday users.

UX vs. self-sovereignty. Abstracting key management makes smart accounts easier to use. But if the underlying keys are custodied by a wallet provider, users may be trading self-sovereignty for convenience without fully realising it.

None of these is a dealbreaker. They're the expected friction of a maturing technology, and the ecosystem is actively working through each of them.

But they're worth understanding clearly as smart accounts move from early adopters to mainstream defaults.

Ethereum is replacing a rigid, one-size-fits-all EOA model with Smart Accounts. This alternative is programmable, recoverable, and composable, built to match how people actually want to use and manage money.

For developers, Smart Accounts are a new primitive to build on. For users, they are the foundation for a version of crypto that is finally safe and simple enough for everyone.

The shift from EOAs to Smart Accounts may be the most consequential UX change in Ethereum's history.

And smart account adoption is just getting started.

A Primer on the x402 Protocol

x402 is an open-source, internet-native payment standard that brings the long-unused HTTP 402 “Payment Required” code back to life. The original 1997 specification never gained traction because the web lacked a global, programmable way to move money. x402 closes that gap by wiring crypto payments directly into HTTP requests.

At its core, the protocol allows servers to request, validate, and settle on-chain transactions, typically in stablecoins like USDC in real time. There’s no account setup, no email, and no credential exchange. Human users or AI agents can simply pay as they go.

Coinbase pioneered and open-sourced the standard, but x402 itself is chain-agnostic. Developers can integrate it with minimal overhead, often a single line of code, while benefiting from instant, low-cost settlement. These characteristics make x402 particularly suited for micropayments, pay-per-API access, and machine-to-machine transactional workflows.

The protocol also pairs naturally with ERC-8004, a standard for on-chain agent identities and verification. Together, they enable autonomous agents to authenticate, request resources, and transact without trust assumptions, an essential building block for the emerging machine economy.

x402 Adoption Metrics

Total transaction volume processed by x402 facilitators has now surpassed $26.19M, setting a new all-time high.

Key insights in this report are based on data from my Dune dashboard tracking x402 Payment Adoption metrics.

The surge began in early October after Coinbase announced new partnerships with major infrastructure providers, including Google and Cloudflare. This triggered a sharp rise in usage, pushing monthly volume up by $4.22M, a +10,780% month-over-month increase.

Adoption continued accelerating into November, with monthly volume reaching $20.5M and 52.6M microtransactions. Facilitators recorded a major spike on November 3, when volume reached $3M and 3.2M transactions.

Coinbase remains the dominant facilitator with $17M in cumulative volume (64% share), but a growing share of activity is shifting toward decentralized alternatives. PayAI, DayDreams, Dexter, and x402RS all recorded meaningful increases in usage.

Across the board, November marked the first month where multiple non-Coinbase facilitators showed sustained, organic growth. PayAI and DayDreams, in particular, have emerged as credible execution venues for agent-to-agent transactions. Newer entrants such as Dexter, CodeNut, and OpenX402 also handled high volumes, early signs that the x402 ecosystem is maturing into a multi-facilitator marketplace rather than a single-provider pipeline.

x402 is going multi-chain

Base currently accounts for more than 95% of all x402 activity. Its lead is unsurprising: the protocol was incubated within the Coinbase ecosystem, and Base’s low fees, fast confirmations, and developer-friendly tooling make it the natural home for early adoption.

But November marks the beginning of a genuine multi-chain footprint. Solana captured ~5% of monthly volume, with facilitators like DayDreams, PayAI, and Dexter leveraging Solana’s high-throughput environment to serve API-driven and automation-heavy use cases.

Volume Processed (November)

• Base: $19.5M

• Solana: $1.02M

• Polygon: $2.2k

• BNB Chain: $2k

Transactions (November)

• Base: 46.7M

• Solana: 5.1M

• Polygon: 379.1k

• BNB Chain: 269.3k

Base remains the primary execution hub for now, but the early traction on Solana suggests that chain-specific optimisations—such as throughput, fee structure, and runtime performance- will influence future facilitator behaviour.

What Users Are Actually Doing on x402

Adoption on the user side is accelerating. By November 30, approximately 356k addresses had acted as buyers and 158k as sellers. Monthly active users hit a new high of 93.6k on November 15, reflecting both organic onboarding and the expanding footprint of x402-powered services.

Beyond wallet-level participation, server-side activity shows that x402 is becoming a preferred payment rail for API access. More than 65% of transaction volume in November flowed to API-driven services. Several servers posted meaningful volumes, suggesting strong early demand for pay-per-request infrastructure.

Top Servers in November

• Arvos — $12.09M

• qrbase — $7.0M

• Barvis — $2.5M

• Ainalyst — $2.34M

• Canza — $1.95M

• Badai — $422.8k

• Dexter — $381.37k

• Dexfun — $311.8k

• Space402 — $198.74k

• Lnpay — $183.03k

In terms of category-level spending, users directed:

• $18.5M toward token launch and fair-mint infrastructure

• $4M toward data-as-a-service APIs

• $3.1M toward agent-to-agent services

• $940.5k unlabelled

• $202.7k infrastructure & utilities

• $56.2k AI-generated content

• $2.5k premium content and paywalls

These patterns confirm that x402’s early adoption is not driven by speculative activity, but by real transactional demand—most notably around data access, on-chain automation, and token-related workflows.

Final Thoughts

What began as a small experimental project inside Coinbase has quickly evolved into a meaningful sector powering the next era of micropayments. The facilitator ecosystem is becoming more diverse, usage is broadening across chains, and the categories of paid services are expanding.

If the current trajectory holds, x402 will likely become one of the core payment rails for autonomous agents and machine-to-machine commerce. As more facilitators enter the market and more servers expose x402 endpoints, the protocol’s network effects will deepen, pushing volumes, transactions, and real adoption even higher.

You can view the full Dune dashboard here.

x402 Payment Analytics

Thanks for reading Onchain Curiosity! Subscribe for free to receive new posts and support my work.

Subscribe

Active addresses are useful for showing quantity/scale of adoption, but they miss the point of quality, which is where real adoption lives. That is why Base creator Jesse Pollak has supported the idea of quality metrics like qMTA (quality monthly transacting addresses) which helps teams measure and support genuinely valuable users and builders.

More teams are working to move the industry beyond quantity-focused metrics. For example, Dune introduced the Dune Index as a proxy for real crypto adoption by aggregating metrics like fees, transactions and transfer volume instead of relying only on market capitalization. Flipside’s intelligence-driven growth (IDG) playbook has laid groundwork for measuring onchain growth. Slice Analytics also introduced a Quality Score methodology to help protocols identify and reward users based on the real value they contribute. Addressable built a tool to help advertisers target the right audience with metrics such as cost per wallet rather than only active wallets.

Together, these developments point to a growing consensus: it is time to move beyond metrics like active addresses, transaction counts and total value locked, and to explore quality-driven metrics that better reflect real adoption.

Why quantity metrics are broken

Most protocols have relied on quantity metrics such as active wallets and transaction counts in their reports. That can be useful at a glance, but it creates a risk of false confidence: you may think your user base is growing when in fact much of the activity is driven by airdrop farmers, which leaves the protocol worse off in the end. 

Common shortcomings of quantity metrics include:

• Trading bots and airdrop farmers can create thousands of addresses and generate artificial activity that inflates numbers without representing real users.

• One person can control multiple addresses for security, economic or privacy reasons.

• A $0.01 transaction counts the same as a $10,000 transaction, so there is no distinction between meaningful economic activity and spam.

• Project incentives can encourage low-value transactions that do not reflect meaningful engagement.

Consider Blast as an example. Back in March 2025, average daily transactions were hitting above 600,000. Quality-adjusted metrics, however, suggested that only about 51 percent of transactions and 58 percent of users represented genuine engagement. Spikes in activity were driven by incentive campaigns that rewarded interactions while users farmed airdrops. When incentives dried up, activity fell.

Going beyond vanity metrics

Rather than measuring adoption only by counts, we can track metrics that show user quality and how users actually interact with a protocol. 

I like to analyze protocols using the BVM methodology that involves a three-step process: user quantity, user quality and user behavior.

User quantity — how many are coming in?

Quantity metrics answer whether the user base is growing or shrinking and give a sense of scale:

• Unique active wallets: distinct wallets interacting with the protocol in a given period.

• Active users (DAU, WAU, MAU): daily, weekly and monthly active wallets.

• New versus returning users: cohort split — are you onboarding new users or retaining existing ones?Growth rate: period-over-period change in active users.
  

User quality — are these real and valuable users?

Quality metrics let protocols distinguish low-value activity from meaningful engagement so they can focus resources on high-quality users:

• Spam filters: exclude one-off transactions and obvious airdrop or faucet activity.

• Human versus bot: filter addresses showing high-frequency, repetitive or MEV-like patterns.

• Sybil detection: identify clusters of wallets with mirrored transaction behavior.

• User segmentation: classify wallets by trading volume or behavior into groups such as whales, retail, power users and farmers.

• Holder distribution: track wealth concentration using measures like the Gini coefficient or share of top holders.

For example, Visa dashboard shows $4.51 trillion in stablecoin transactions in September 2025. That number looks large, but when remove bots, HHT addresses, CEX Exchanges, and internal smart contract interactions, you're left with $1.03 trillion, which is approximately the 20% of the headline metrics.

User behavior — how are they engaging?

The final step is to track behavior to understand whether adoption is one-off hype or sustained usage, and which product features actually drive growth:

• Retention and churn: percentage of wallets that stay active versus those that drop off over time.

• Activation rate: percentage of new users who perform a key action (for example, first swap, stake or mint) within a defined period.

• Contract and dApp interaction: which contracts or apps users engage with most — swapping, staking, voting, borrowing or minting.
  

When protocols measure these metrics well, they can more accurately track adoption, improve product decisions, grow their user base and ultimately increase revenue.

This is the first part of my Beyond Vanity Metrics series. In the next post, I will show how we apply these metrics to track stablecoin adoption.

This is where Traces come in…

Traces provide a detailed, step-by-step view of every operation performed during a transaction. They go beyond the surface level of transactions and events, giving you a deep understanding of what's happening inside the smart contract.

In this guide, we'll explore how to use traces to analyze transaction behavior, debug issues, and gain a deeper understanding of smart contract execution.

What Are Traces?

Traces are records of the internal operations executed during a transaction.

In Ethereum, traces are detailed, internal records of all EVM execution steps that occur during a transaction. They capture every internal call, value transfer, and operation—even those that aren’t visible in the standard transaction log.

Instead of just seeing the end result of a transaction (the state changes) and events which are the summary, traces show you the process by which those changes were achieved.

More specifically, traces record every internal operation during a transaction. Every time a function is called, a contract is created, or value is transferred internally, a trace records that action.

Why are traces are valuable in exploring blockchain data?

• Debugging: Pinpoint the exact location of errors in complex smart contract interactions.

• Gas Optimization: Identify gas-intensive operations within your smart contracts.

• Value Tracking: Follow the flow of Ether and tokens through multiple contract calls.

• Root Cause Analysis: Determine the precise cause of transaction failures.

For example, imagine a complex DeFi transaction that fails with a generic error message. Traces let you examine each internal call, identify the point of failure, and understand the specific reason for the revert.

Understanding the Trace Structure

Each trace entry is a JSON object with the following key fields:

{
  "type": "CALL",
  "from": "0x...",
  "to": "0x...",
  "value": "0x...",
  "gas": 2300,
  "gasUsed": 2100,
  "input": "0x...",
  "output": "0x...",
  "time": "2.373ms",
  "calls": [
    // Nested calls (if any)
  ]
}

Let's break down the key fields:

• type: The type of operation performed. This is crucial! Common types include:

  • CALL: A function call.

  • CREATE: A contract creation.

  • DELEGATECALL: Executes code from a target contract in the context of the caller.

  • SELFDESTRUCT: Contract destruction.

• from / to: The sender and receiver addresses of the call.

• value: The amount of Ether (in Wei) transferred.

• gas / gasUsed: The gas limit and the actual gas used.

• input: The input data (calldata) for the call, including the function selector and arguments.

• output: The return data from the call.

• calls: An array of nested trace entries, representing internal calls.

Reading traceAddress

Each trace entry includes a traceAddress—an array of integers—that tells you how deeply nested the call is and its position among sibling calls.

Let's visualize how traceAddress maps to the call structure. Imagine the following scenario, where A initiates a transaction :

A (null)  -- the transaction first input has a trace_address of []
  CALLs B (0)
    CALLs C (0,0)
    CALLs D (1)
      CALLs E (1,0)
        CALLs F (1,0,0)
      CALLs G (1,1)
  CALLs H (2)

• [] (Null/Empty Array): The initial transaction call, initiated by an external account (A).

• [0]: The first call within the initial transaction. In this example, function A calls function B.

• [0, 0]: The first call within call [0]. C is being called by B.

• [1]: The second call within the initial transaction. H is the second top-level trace called by A

• [1, 0]: This show the first function call from within the second internal call from the intial transaction

• [1, 0, 0]: This shows the zero index of the zero index of the second index.

• [1, 1]: A shows there is another index, or second call within the second index which originated.

For instance, this traceAddress tells you:

• How many levels deep a particular function call has gotten, which shows function hierarchies.

• Knowing which function call occured within which function call, can also help you trace the source of the error.

Practical Examples: Reading Traces Data

Let's examine a USDT token transfer with this transaction hash: 0x85d6fa5ba09b882189fb3100c55aae198a6fac963508cbf45b5056a8ee8587d0

Etherscan can be tricky, so we will use Phalcon Blocksec to see a more organized and cleaner way to walk through the decoding process.

At a glance, you'll observe the transaction has a trace address of [0,1]. First, observe the sender, initiating the call. Now we see what input and output by tracing the transaction. Finally the contract emits a transfer event with the [from, to, value].

Now, let’s Decode the Trace Data Manually…

Just like decoding event logs, decoding trace data means transforming the raw data into a human-readable format. We'll use a similar approach to the one in our event logs guide.

For a USDT transfer, we'll identify the transfer function and decode its parameters:

transfer(address,uint256)

Here's how to do it with DuneSQL:

1. Extracting the Function Signature

The first four bytes of the input data are the function signature. We can extract it using the following DuneSQL query:

SELECT
  substring(to_hex("input"), 1, 8) as function_signature
FROM
  ethereum.traces
WHERE
  to = 0xdAC17F958D2ee523a2206206994597C13D831ec7  -- USDT Address
  AND tx_hash = 0x9acba5bef8645d7dd0710f831318089f5424686bc35e2741ebc37d0f307c22bc  -- transaction_hash

Let's break this down:

• substring(to_hex("input"), 1, 8): This extracts the first 8 characters (4 bytes) from the hexadecimal representation of the "input" field.

  • to_hex("input"): This converts the binary "input" data into a hexadecimal string.

• FROM ethereum.traces: Specifies we're querying the ethereum.traces table

• WHERE to = ... AND tx_hash = ...: This narrows the query scope to USDT transfers.

The output will be the function signature as a hexadecimal value:

Finally, concatenate 0x to the start of the signature, resulting in:

transfer_signature = 0xa9059cbb

2. Decoding the address Parameter

The address parameter (the recipient) is located after the function signature in the input data. Ethereum addresses are 20 bytes long, which corresponds to 40 hexadecimal characters.

To extract the address, we'll use the following DuneSQL code:

WITH
  decoded_traces AS (
    SELECT
      regexp_extract_all(substring(to_hex("input"), 9), '.{64}') AS decoded_input
    FROM
      ethereum.traces
    WHERE
      to = 0xdac17f958d2ee523a2206206994597c13d831ec7  -- USDT Address
      AND tx_hash = 0x9acba5bef8645d7dd0710f831318089f5424686bc35e2741ebc37d0f307c22bc  -- transaction_hash
  )
SELECT
  function_signature,
  '0x' || substring(decoded_input[1], 25, 40) AS address
FROM
  decoded_traces

Here's the breakdown:

• WITH decoded_traces AS (...): Defines a common table expression (CTE) to preprocess the data

• regexp_extract_all(substring(to_hex("input"), 9), '.{64}') AS decoded_input: This performs regexp_extract_all function to decode all the inputs from the traces table, making it easy to decode any parameter by calling its index.

  • substring(to_hex("input"),9): The function signature takes up the first 8 characters. To access the arguments, we access everything after. We also perform to_hex, so we can perform string specific operation substring

  • '.{64}': As a rule of thumb, all arguments must be decoded uint256, or has 32 bytes. Therefore, the expression above will split the input after the function into chunks of 64 characters.

• substring(to_hex("input"), 9): Extracts the data past the function signature.

• '0x' || substring(decoded_input[1], 25, 40): Extracts 40 bytes for offset.

3. Decoding the uint256 Value

Following the address, in the input data is the value (amount) being transferred and is of uint256 data type . uint256 values are 32 bytes or 64 hex characters in length. The following DuneSQL code extracts and converts the value to the appropriate type:

WITH
  decoded_traces AS (
    SELECT
      regexp_extract_all(substring(to_hex("input"), 9), '.{64}') AS decoded_input
    FROM
      ethereum.traces
    WHERE
      to = 0xdac17f958d2ee523a2206206994597c13d831ec7  -- USDT Address
      AND tx_hash = 0x9acba5bef8645d7dd0710f831318089f5424686bc35e2741ebc37d0f307c22bc  -- transaction_hash
  )
SELECT
  varbinary_to_uint256(varbinary_substring(from_hex(decoded_input[2]), 1, 32)) AS amount
FROM
  decoded_traces

Deconstructing the query:

• varbinary_to_uint256(...): Converts the hexadecimal value into an unsigned integer.

• varbinary_substring(from_hex(decoded_input[2]), 1, 32): Returns 32 bytes from decoded_input

Putting It All Together (Example Query)

The following example shows a complete DuneSQL query with all previous steps.

WITH
  decoded_traces AS (
    SELECT
      block_time,
      tx_hash,
      substring(to_hex("input"), 1, 8) AS function_signature,
      regexp_extract_all(substring(to_hex("input"), 9), '.{64}') AS decoded_input
    FROM
      ethereum.traces
    WHERE
      to = 0xdac17f958d2ee523a2206206994597c13d831ec7  -- USDT Address
      AND tx_hash = 0x9acba5bef8645d7dd0710f831318089f5424686bc35e2741ebc37d0f307c22bc  -- transaction_hash
  )
SELECT
  function_signature,
  '0x' || substring(decoded_input[1], 25, 40) AS address,
  varbinary_to_uint256(varbinary_substring(from_hex(decoded_input[2]), 1, 32)) AS amount
FROM
  decoded_traces

If you followed up to this point, I congratulate you on taking the first step towards working with traces data. To go beyond a simple USDT transfer case study, you can check out this Dune Query, where we decoded a more complex transaction.

That’s a Wrap!

By understanding the structure of trace data and applying appropriate DuneSQL functions, you can efficiently decode and analyze trace data.

The best way to master this skill is to practice. Start exploring traces for transactions you find interesting, and you'll quickly develop a solid understanding of Ethereum internal workings.

Thanks for reading Onchain Curiosity! Subscribe for free to receive new posts and support my work.

Subscribe

The Goldilocks algorithm is a key component of Optimism’s Retro-Funding Evaluation, designed to reward onchain builders (projects) that demonstrate steady and balanced contributions across multiple metrics, with a strong focus on retention. However, as Optimism Season 7 shifts its priority to driving Total Value Locked (TVL), the current weight configuration reveals a significant limitation: it favors established projects while overlooking "rising stars"—emerging projects with shorter track records but substantial growth potential and impact. This exclusion risks undervaluing innovative contributors critical to achieving Season 7’s TVL objectives. This report examines these shortcomings, proposes refined metric and variant weights, and demonstrates how these adjustments better align with Optimism’s goal of rewarding impact while preserving the algorithm’s foundational strengths.

Thanks for reading Onchain Curiosity! Subscribe for free to receive new posts and support my work.

1. Introduction

Optimism’s Retro-Funding initiative aims to promote growth, adoption, and sustainability within the Superchain ecosystem. The Goldilocks algorithm supports this mission by assessing projects through a combination of metrics and variants, historically emphasizing retention to encourage consistent contributions. With Season 7’s strategic focus on driving Total Value Locked (TVL), however, the algorithm’s current design—featuring equal metric weights and a retention-heavy structure—falls short. A major limitation is its inability to adequately recognize rising stars, whose rapid growth and potential impact are vital to ecosystem expansion. This report details the deficiencies of the existing setup and proposes targeted adjustments to better align the algorithm with Season 7’s TVL-driven priorities, while maintaining its commitment to balanced performance evaluation.

2. Shortcomings of the Current Weight Configuration

The current Goldilocks algorithm employs the following weights:

2.1 Equal Metric Weights Undermine TVL Focus and Exclude Rising Stars

• Issue: All metrics are weighted equally at 0.25, despite total value locked (TVL) being Season 7’s primary target. Metrics like trace_count and monthly_active_farcaster_users, while informative, do not directly contribute to TVL and dilute the focus on value-centric projects. Furthermore, this equal weighting overlooks the unique strengths of rising stars, which often demonstrate strong growth metrics rather than established performance.

• Impact: Established projects with stable but stagnant metrics may outscore rising stars with significant growth potential, misaligning rewards with Season 7’s goal of ecosystem expansion through TVL growth.

2.2 Vulnerability to Artificial Activity

• Issue: The lack of bot-filtered metrics (e.g., transaction_count_bot_filtered) allows unverified or artificial activity to influence scores.

• Impact: Projects with inflated metrics due to bot activity could receive undeserved rewards, compromising fairness and the recognition of genuine value creation.

2.3 Platform Bias Towards Farcaster

• Issue: Relying exclusively on monthly_active_farcaster_users restricts community assessment to a single platform.

• Impact: Projects with robust engagement on alternative platforms (e.g., X, Discord) are undervalued, reducing inclusivity and potentially excluding rising stars that thrive on diverse channels.

3. Proposed Adjustments

The proposed changes recalibrate the algorithm by structuring the metric weights into three key categories—TVL Drivers, Transactions, and User Metrics—following a 50-30-20 weighting approach. This framework reflects Retro-Funding’s methodology of evaluating onchain impact through financial commitment (TVL), transaction activity, and user adoption, while emphasizing growth to spotlight rising stars.

Proposed Metric Weights

Understanding the 50-30-20 Metric Weight Categories

• TVL Drivers (50%):

  • monthly_average_tvl: 0.30

  • amortized_gas_fee: 0.20

• Transaction Drivers (30%):

  • trace_count: 0.20

  • transaction_count_bot_filtered: 0.10

• User Metrics (20%):

  • monthly_active_farcaster_users: 0.10

  • monthly_active_addresses: 0.10

This 50-30-20 split prioritizes financial commitment (TVL) as the primary driver, supported by transaction activity and user adoption metrics. The increased growth weight of 0.30 in the variant weights ensures that rising stars—projects demonstrating strong upward momentum—are adequately recognized.

4. Rationale for Proposed Changes

These adjustments address previous shortcomings, align the algorithm with Season 7’s TVL-focused objectives, and ensure rising stars are rewarded through a clear, impact-driven structure.

4.1 Prioritizing TVL Drivers (50% Weight)

• Change: monthly_average_tvl increases from 0.25 to 0.30.

• Reason: As the primary measure of ecosystem value, TVL is elevated to anchor the 50% TVL Drivers category. This shift ensures projects contributing to Season 7’s core goal are prioritized, particularly rising stars with growing TVL, while amortized_gas_fee (0.20) complements it by capturing sustained economic activity.

4.2 Incentivizing Growth to Recognize Rising Stars

• Change: growth increases from 0.20 to 0.30; adoption decreases from 0.20 to 0.10.

• Reason: Elevating the growth variant rewards projects with upward trajectories, a defining trait of rising stars critical for ecosystem expansion. The strong retention weight (0.60) maintains stability, while the reduced adoption weight shifts focus from current scale to future potential.

4.3 Ensuring Authentic Transaction Activity (30% Weight)

• Change: Introduces transaction_count_bot_filtered at 0.10; reduces trace_count from 0.25 to 0.20.

• Reason: The Transaction Drivers category (30%) now balances raw activity (trace_count) with authentic engagement (transaction_count_bot_filtered). This ensures rewards reflect genuine usage, which is especially important for rising stars that may face early-stage metric inflation.

4.4 Broadening User Metrics (20% Weight)

• Change: Reduces monthly_active_farcaster_users from 0.25 to 0.10; adds monthly_active_addresses at 0.10.

• Reason: Diversifying community metrics mitigates platform bias and captures broader user adoption. This fosters inclusivity, benefiting rising stars active across multiple platforms beyond Farcaster.

4.5 Refining Existing Metrics

• Change: amortized_gas_fee decreases from 0.25 to 0.20; trace_count decreases from 0.25 to 0.20.

• Reason: These reductions free up weight for more strategic metrics like monthly_average_tvl and transaction_count_bot_filtered. This refines the algorithm to focus on meaningful growth indicators, ensuring rising stars are evaluated on impactful contributions rather than less relevant signals.

5. Conclusion

The proposed adjustments to the Goldilocks algorithm offer a strategic overhaul that directly addresses its existing limitations while aligning with the core objectives of Optimism Season 7. These refinements ensure the algorithm not only drives Total Value Locked (TVL) but also fosters a fair, inclusive, and resilient Superchain ecosystem.

Here’s how these changes deliver impactful improvements:

• Prioritizing TVL: By assigning a higher weight to monthly_average_tvl, the algorithm shifts its focus to reward projects that significantly contribute to TVL, a key metric for Optimism Season 7’s success.

• Balancing Retention and Growth: The updated framework enhances the growth variant to incentivize expansion, while still valuing retention, ensuring both rising stars and established projects are fairly rewarded for their contributions.

• Enhancing Authenticity: Introducing bot-filtered metrics mitigates the risk of artificial activity, strengthening the integrity and reliability of the evaluation process.

• Broadening Inclusivity: Expanding community metrics beyond platform-specific biases (e.g., Farcaster) promotes diverse engagement, making the algorithm more equitable and representative of the broader ecosystem.

These adjustments align the Goldilocks algorithm with Optimism Season 7’s mission to drive TVL, while preserving its foundational commitment to rewarding consistent and balanced project performance. By adopting this refined framework, Optimism empowers both established contributors and emerging innovators, laying the groundwork for sustained growth, fairness, and profitability of the Superchain ecosystem.

Thanks for reading Onchain Curiosity! This post is public so feel free to share it.

Share

Each event log record consists of both topics and data. While topics are indexed parameters of an event, data contains the non-indexed parameters.

Understanding Topics and Data

Consider a basic transfer event log:

Transfer(address indexed from, address indexed to, uint256 value)

The first part of an event log consists of an array of topics, which are 32-byte (256-bit) characters used to describe what’s happening in an event. These are essentially indexed parameters, meaning they can be searched for specific values. The topics contain the event name and parameters, which include topic0, topic1, topic2, and topic3.

The first topic is always the signature of the event (a keccak256 hash) of the event's name and its parameter types. There can be up to three additional topics.

For the Transfer event mentioned above, the topics would be:

• Topic 0: The event signature

• Topic 1: The from address

• Topic 2: The to address

Data is the second part of event logs, containing non-indexed parameters that cannot be directly searched. Unlike topics, which are limited to 32 bytes, data can hold any data type, including complex structures like tuples and strings, providing more detailed information about the event.

In the Transfer event, the value would be included in the data section.

Now, put on your Onchain Data Analyst hat, and let's learn how to decode topics and data from event logs manually.

Decoding Event Logs on Ethereum

Decoding event logs involves converting raw data from blockchain transactions into human-readable information. The goal of this process is to map each parameter in the topic and data fields to their corresponding data types.

In this walkthrough, we will decode the event log of an ERC20 transfer event from the PICKLE token.

The PICKLE Transfer event contains the sender, the recipient, and the amount of tokens transferred:

Transfer(address indexed from, address indexed to, uint256 value)

The event logs are identified as follows:

• Topic 0: The event signature

• Topic 1: The from address

• Topic 2: The to address

• Data: the value amount

Now, let me show you how to decode each parameter manually.

Topic 0: The Event Signature

To find the event signature (Topic 0), you need to normalize the event by removing spaces, parameter names, and keywords. Then, apply the Keccak-256 hashing function or use an online hashing tool to calculate the Keccak256 hash.

The normalized signature is:

Transfer(address,address,uint256)

Using this Keccak-256 tool, or Keccak function in Dune, input the normalized signature:

keccak(‘Transfer(address,address,uint256)’)

The output will be the following hash value:

Finally, concatenate it with ‘0x’, and you will have the event signature as

topic0 = 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef

Topic 1: The from Address

The data type for Topic 1 is an address. Therefore, our goal is to decode it from its current hex value into the standard address format.

A standard EVM address has 42 characters, but the hex value of the address below includes 24 additional leading zeros for encoding purposes:

To correctly decode this address, we need to use the substring function to extract characters from the 25th to the 42nd position. We then concatenate the result with `0x` to convert it into the standard Ethereum address format.

Using Dune SQL, the query for decoding Topic 1 will be:

'0x' || lower(substring(to_hex(topic1), 25, 42)) as decoded_topic1

The decoded address should return:

Topic 2: The to Address

Since both Topic 1 and Topic 2 are addresses, we can simply replicate the process explained above.

Using Dune SQL, the query for decoding Topic 2 will be:

Data: The value

The value column in the data logs is of the integer data type. To convert from hexadecimal to integer we use the bytearray function on Dune and apply a substring operation to extract the 32-byte character sequence:

bytearray_to_uint256(bytearray_substring(data, 1, 32)) AS amount

The output will be an integer representing the value of tokens transferred from the sender (Topic 1) to the receiver address (Topic 2).

Our final query for decoding all topics and data in the PICKLE Transfer Event will be:

select 
   keccak(to_utf8('Transfer(address,address,uint256)')) as topic0 
, '0x' || lower (substring(to_hex(topic1),25, 42)) as decoded_topic1
, '0x' || lower (substring(to_hex(topic2),25, 42)) as decoded_topic2
,bytearray_to_uint256(bytearray_substring(data, 1,32)) as amount
from ethereum.logs
where tx_hash =   0x2bb7c8283b782355875fa37d05e4bd962519ea294678a3dcf2fdffbbd0761bc5
and contract_address = 0x429881672B9AE42b8EbA0E26cD9C73711b891Ca5

Now, let’s verify the accuracy of our decoding by switching the view in the Event Logs Explorer from hex to decoded format. The output below matches the results of our manual decoding.

In addition, the PICKLE event logs table is already decoded in Dune, allowing us to query the pickle_finance_ethereum.PickleToken_evt_Transfer table to access the decoded event log.

Next Steps…

The ability to manually decode event logs is crucial for assessing data accuracy, completeness, and consistency before conducting on-chain analysis.

This walkthrough was designed to provide you with a foundational understanding of how the decoding process works for basic data types.

As you continue to query blockchain data, you'll encounter more complex data types like tuples, timestamps, and others. I highly recommend this video walkthrough by Sam-SQL Sunday, which is particularly helpful for learning how to decode complex data types.

On my end, I will keep experimenting with decoding event logs using contract ABIs. If you're interested, I can create guides to share my findings.

The final part of my series on “Working with Raw Data” will focus on decoding Traces. I’ll be sharing that guide in the coming days.

As always, I welcome your feedback on how I can improve and suggestions for future guides to help make your on-chain data career easier.

Thanks for reading Onchain Curiosity! Subscribe for free to receive new posts and support my work.

Reference Tools & Resources to improve your learning

• How to Decode Ethereum Logs Manually by Sam

• How to Read Ethereum Transactions, Traces & Logs by Andrew Hong

• Keccak-256 Tool- https://emn178.github.io/online-tools/keccak_256.html

• Using Varbinary Functions on Dune

Lifecycle of a Blockchain Transaction

Let’s take the example of you transferring USDT to a friend on the Ethereum chain. You sign the transaction to transfer the ERC-20 token from your wallet, triggering the transfer function that specifies the recipient and amount.

Behind the scenes, the blockchain creates two key tables: transactions and traces. These tables record details like transaction hash, sender, recipient, transaction status, gas fees, block number, and timestamp.

The transaction's final stage is marked by the emitTransfer function, which generates the logs table. This table includes contract address, event topics, call data, and block information.

Most tables on Blockchain Analytics platforms like Dune & Flipslide are built upon these three foundational tables. Understanding them is essential for delving into more complex blockchain data exploration.

Part 1- Exploring Transaction Data on Ethereum

Every transaction happening in the cryptoeconomy is, by design, visible to anyone via explorers. The challenge is that the average person usually finds it difficult to read and interpret these transactions due to the jargon and technicalities involved in navigating blockchain explorers like Etherscan.

This section of the guide will be an overview of important terminologies and details you need to understand when looking up any transaction on blockchain explorers.

Let's say you swap USDT for Highstreet (HIGH) tokens on Binance. Since these are ERC-20 tokens, you can find transaction details on Etherscan. After each swap, a transaction hash is generated. Entering the hash into etherscan's search bar will bring you to a page like this:

• Transaction Hash: A unique identifier for each transaction, similar to a receipt number.

• Status: Indicates the current state of the transaction- e.g. success, failed, canceled, or is still pending.

• Block: The block number where the transaction is included. Blocks contain groups of transactions added to the blockchain at specific times.

  Block confirmation means how many blocks have passed since the transaction was included.

• Timestamp: Date and time the transaction was included in a block.

• Transaction Action: The type of action the transaction performs, such as sending tokens, deploying a smart contract, or providing liquidity in a pool.

• From: Address of the sender initiating the transaction.

• Interacted With (To): Address receiving the transaction (this can be an EOA (externally owned address) for token transfers, or contract address for smart contract interactions.

• Tokens Transferred: Specific tokens involved in the transaction.

• Value: Amount of Ether (ETH) sent in the transaction.

• Transaction Fee: Total fee paid for the transaction in ETH.

• Gas Price: Price per unit of gas used by the transaction.

• Gas Limit & Usage by Txn:

  • Gas Limit: Maximum amount of gas the sender is willing to spend on the transaction.

  • Gas Usage: Actual amount of gas used by the transaction.

• Gas Fees: Calculated cost of gas used (Gas Used * Gas Price).

  • Base Fee: the minimum fee to be paid in the block.

  • Max: the maximum fee the user is willing to pay.

  • Max Priority: tip paid to incentivize miner to include transaction.

• Burnt & Savings Fees:

  • Burnt Fees: The base fee is burned (sent to 0x address) to secure the network (burned/destroyed).

  • Savings Fees: A portion of the gas fee that goes to the miner who included the transaction in a block.

    • Where Savings = max- base- priority * gas used.

• Other Attributes: May include additional details specific to the transaction like type, nonce, and position in block.

• Input Data: Data associated with the transaction, often used for smart contract interactions. You can find a decode button if the ABI of the contract is provided.

As you navigate Explorers, it is important to understand if the address being interacted with is a contract address or an EOA-externally owned address (user address). A contract address will usually have an input call data column, which contains additional details about the transaction.

Let’s talk about Input Data

Input data in an Ethereum transaction specifies the function being called and the arguments passed to that function. It's essentially the message telling the smart contract what to do.

Breakdown of Input Data Elements:

The input data for an Ethereum transaction typically includes the following elements:

• Function: The name of the function being called on the smart contract (e.g., swap).

• Address executor: The address of the contract involved in the transaction.

• Tuple desc (tuple description): This defines the data types of the arguments passed to the function. Tuples are collections of data that group related values together. In this context, they specify the expected data types (e.g., address, uint256) for the function's arguments. Tuples are immutable, meaning their values cannot be changed after creation.

• Bytes data: This section contains additional information specific to the function being called. It's encoded in bytes format for the smart contract to interpret.

Decoding Bytes Data:

The decoding process involves understanding how the data is structured within the bytes. Here's a breakdown:

1. Function Signature (Method ID): The first 8 hexadecimal characters (4 bytes) of the input data represent the function signature, also known as the method ID. This value is derived by:

   • Combining the function name and its input data types.

   • Taking the Keccak-256 hash of the combined string.

   • Extracting the first 4 bytes of the hash.

   • Displaying the extracted bytes in hexadecimal format.

2. Decoding Individual Parameters: After identifying the function signature, each remaining byte is decoded based on its position within the tuple desc. This involves interpreting each byte according to its corresponding data type (e.g., address, uint256) and assigned value.

In this Transaction, the methodID is decoded as 07ed2379, while its parameters are specified thus:

Understanding how to decode input data is crucial for extracting deeper insights beyond what blockchain explorers provide. I plan to delve deeper into input data and share more details as I learn along the way.

My next guide will focus on understanding Event Logs. Be sure to follow along as we learn blockchain data together.

Thanks for reading Onchain Curiosity! Subscribe for free to receive new posts and support my work.

Built on Optimism's OP Stack, Base leverages the security of the Ethereum mainnet while offering significantly faster and cheaper transactions. This combination makes Base an attractive platform for developers and users alike.

Base prioritizes building solutions for everyday use cases, with a focus on fiat on-ramps, easy-to-use wallets, and scalable infrastructure. The Base ecosystem has an outspoken focus on consumer and payment applications like Friend.Tech, Fren Pet, and Farcaster and payment with USDC.

Base as a Coinbase Startup

Leading cryptocurrency exchange Coinbase incubated Base, acting as a major catalyst for its success and mass adoption. According to Token Terminal, Base serves as a four-step strategy for Coinbase to rebuild itself on-chain:

1. Develop an on-chain developer platform for internal Coinbase teams.

2. Develop an on-chain developer platform for external teams.

3. Integrate the on-chain developer platform with the Coinbase product suite.

4. Rebuild Coinbase on-chain.

   The included diagram illustrates how Coinbase is building Base as a self-sustaining startup.

Let’s look at Base Onchain Metrics

Leveraging blockchain data from Dune, I created queries and a dashboard to analyze on-chain activity on Base. You can explore the Base dashboard and provide feedback on areas of improvement.

Total value locked (TVL) in Base surpassed $1.5 billion.

With growing interest and adoption on Base, approximately $1.503 billion worth of crypto assets are locked across 50 deployed protocols.

Base TVL has surged significantly since January 2024, driven by major events like the launch of the CUBE NFT collection, Uniswap V2 deployment, and the ongoing "on-chain summer.

Over 600k Daily Active Users on Base

Daily active users on Base reached an all-time high of 855,000 on March 16th following the successful Duncan upgrade, which reduced gas fees on Ethereum. Before the upgrade, average daily active users stood at around 80,000.

Since then, the daily active user count has continued to grow, currently exceeding 606,000 as of July 2nd, 2024.

Daily Transactions on Base surges above 2M

In the days that led to the Duncan upgrade, Base processed an average of 440,000 transactions per day. However, following the upgrade, daily transactions skyrocketed to a record 2 million on March 16th, representing a massive 3,200% increase from the pre-upgrade average.

Since then, Base transactions have continued to grow, reaching an all-time high of 3.4 million on June 4th. Currently, daily transactions hover around 3.15 million, indicating sustained interest and activity on the Base chain.

Base records 269K new addresses in 24H

Nearly half of Base’s active addresses since July are new users. In the last 24 hours alone, about 56.2% (269750) of the 479,580 active addresses were new. This indicates growing interest and adoption of the Base ecosystem.

The recent surge in new addresses could be attributed to users exploring new products launched by developers during the Onchain Summer event, alongside innovations like Coinbase's Smart Wallet.

Base’ profit above $4M despite market downturn

Base has maintained profitability since its launch, reaching a monthly high of $16.8 million in March 2024.

Even with the recent market downturn impacting its financials, Base continues to remain profitable, with a low cost of $28.7k, generating a revenue of $4.42 million and closing June with a profit of $4.39 million.

Final Thoughts

Base performance demonstrates a strong path toward achieving its mission of onboarding the next billion users onchain. Its low-cost transaction and affiliation with Coinbase make it a great choice for developers building consumer-focused products. The onchain metrics analyzed in this research reveal increasing adoption and rising profitability as more users migrate to the Base ecosystem.

Thanks for reading Onchain Curiosity! Subscribe for free to receive new posts and support my work.

Early market innovators and investors drove the events that unfolded between 2009 and 2021. The 2022/23 bear market provided an opportunity to address the gap (chasm) related to regulatory clarity, product-market fit, and user experience and education. Developments in 2024, show the market is poised for mainstream adoption.

For starters, the S-curve is a way to visualize how a new technology or product is adopted by a population over time. It's shaped like the letter S because adoption starts slowly, then accelerates rapidly, and finally plateaus as it reaches saturation. In this context, we will use the Bitcoin S-curve as a proxy for our discussion on crypto adoption.

The story of Bitcoin and cryptocurrencies closely follows the S-curve, with key milestones and events shaping their evolution.

The Age of Innovators (2009-2013)

In its infancy (2009-2013), cryptocurrencies garnered little attention beyond a small group (around 2.5%) of tech enthusiasts and innovators like Satoshi Nakamoto, who saw its potential as a revolutionary technology. At this point, BTC was considered illegal for its role in the Silk Road marketplace.

Early Adopters (2013-2021)

In 2013, Bitcoin's price rose from approximately $13.40 to $754, attracting early investors and leading to the development of cryptocurrency exchanges like Coinbase and Mt. Gox. This period also saw the emergence of altcoins like Ethereum and increased media coverage of the crypto industry, capturing the interest of roughly 13.5% of early adopters.

By the end of 2021, Bitcoin was trading at around $47,000, representing a more than 350x price appreciation for early adopters. This surge attracted the attention of institutional investors (like Tesla and BlackRock) and regulatory agencies like the US SEC.

Crossing the Chasm (2022-2024)

The fall of bad actors like FTX and Luna led the industry into the 2022 bear market and the opportunity to cross the “chasm”—the gap between early adopters and the mainstream majority.

It was a much-needed break that helped builders in the industry achieve product-market fit, and improve user experience and education while working with relevant authorities to establish clear regulations.

Bitcoin investment firm, Unchained, surveyed traditional investors to understand why they would consider buying crypto in 2024.

Considering their responses and recent developments in the crypto industry, it appears we're addressing many of the adoption barriers, and we can expect continued growth.

• The US Securities and Exchange Commission (SEC) approved the trading of 11 spot Bitcoin ETFs on January 10th, 2024. Over $12 billion has already been invested in these products, with traditional institutions like BlackRock, Ark Invest, and Fidelity leading the charge. Notably, Wisconsin became the first US state to invest in a Bitcoin spot ETF, with more states likely to follow.

• In a similar move, the SEC approved all spot Ethereum ETF applications on May 23rd, marking a significant milestone for the crypto industry. While trading hasn't yet begun, the ETF is expected to be a major catalyst for this cycle's bull run.

• Crypto adoption isn't limited to the US. Regulators in Hong Kong also approved the trading of spot Bitcoin and Ethereum ETFs. This international acceptance signifies a growing global shift towards cryptocurrencies.

• Politically, the crypto industry's influence on US politics is undeniable as the November elections approach. Notably, Donald Trump has declared his intention to make the US a pro-crypto nation. While his campaign has received over $32 million in crypto-related support, it's important to consider the broader political landscape and potential policy changes.

All of these developments and more, indicate that crypto builders, regulators, and institutional investors are collaborating to create a safer environment for the mainstream adoption of crypto.

To understand the potential impact of these events on crypto's future, let's consider the Diffusion of Innovations Theory. This theory states that:

“The amount of time it takes for most new tech to get embraced by 10% of the population is roughly the same amount of time it takes to go from 10% to 90% adoption.

This is exemplified in the adoption of computers. Apple invented the personal computer (PC) in 1976. In 1980, about one-tenth of 1% of households owned a PC. By 1990, 10% of households owned PCs. And by 2000, 90% of households had a PC.

Insights from Off the Chain Capital show that it took Bitcoin about 10 years (from 2009 to 2019) to reach 10% of households in the US. As of 2024, 25% of Americans reportedly own Bitcoin. If the Diffusion of Innovations Theory holds, Bitcoin adoption could reach 90% by 2029.

With clearer regulations on the horizon and institutional investors entering the market, it is safe to state that we are in the early phase of adoption by the mainstream market. Soon, everyone from your Cab Driver to Grandma will start asking about crypto. When you see these signs, know that mass adoption is here.

Don't let the price fluctuations deter you. Builders are shipping, regulators are working, institutional investors are buying, and the next billion users are being onboarded. Don’t be a laggard—find your place in the industry and play the long-term game, and crypto will reward you with generational wealth.

Stay curious and I will write to you in the new week.

Chris...

A recent report released by Fintel revealed that about 500 institutional funds in the US now have exposure to crypto through the Bitcoin ETF. The hedge fund giant Millennium Management tops the list with $1.95 billion invested in various Bitcoin ETFs. Other major players, such as Bracebridge Capital ($404 million), Boothbay Fund Management ($303 million), and Morgan Stanley ($269.9 million), have also wagered considerable sums on Bitcoin ETFs. Interestingly, the state of Wisconsin disclosed that it had purchased spot BTC ETFs worth $163 million in the first quarter of 2024, making it one of the first state pension funds to invest in cryptocurrencies.

So far, institutional investors have deployed about $12 billion into Bitcoin ETFs, with more expected in the coming days as an Ethereum ETF is underway.

An eventual approval of the Ethereum ETF will undoubtedly deploy billions of dollars (e.g., GrayScale’s $9 billion Ethereum Trust Fund, will be converted into ETFs) into the crypto market, which could propel the much-anticipated bull run.

In a related development, a coalition of Wall Street investors has gone to Washington to lobby for the reversal of an anti-crypto bill called the "Staff Accounting Bulletin No. 121" (or SAB 121).

The SAB 121 bill was introduced to make it nearly impossible for Wall Street banks to custody crypto assets. For example:

If a bank wants to custody $1 billion of crypto assets, it is mandated to deposit cash worth at least $1 billion in trust. If the price of bitcoin then doubled, it would have to find another $1 billion to keep up. Banks only get to charge a 1% fee on crypto, making it economically inefficient for them to provide custody services.

Earlier in February, a coalition of bank lobbying groups—the Bank Policy Institute, American Bankers Association, Securities Industry and Financial Markets Association, and Financial Services Forum—jointly issued a letter to the SEC opposing SAB 121.

With support from the Democratic Senate Majority Leader Chuck Schumer and 31 other politicians, the SAB 121 rule has been overturned.

In the long term, more US banks will open up their counters to custody of crypto assets, which will in turn increase investors’ confidence and drive crypto adoption.

We have seen the general sentiment around crypto move from a systemic threat stance to an indispensable part of the global economic system. As more Wall Street investors continue to buy up crypto, the government will be lobbied into making regulations that will be favorable for the crypto industry as well.

It's an interesting time to be alive as we watch crypto, the once-rejected asset class, become the chief cornerstone of every investor’s portfolio.

Stay profitable as you play to win in the market...

This trend is particularly strong on the Solana network, where memecoins like WIF, SLERF, and BOME have experienced impressive growth.

Capitalizing on the memecoin trend, more retail investors are turning to the Base ecosystem, with DEGEN emerging as a favorite.

DEGEN on Base

Launched on the Base network in January 2024, DEGEN began as a reward token for Casters (Farcaster users) to tip creators for valuable content. However, DEGEN is working to transcend its memecoin origins.

It currently boasts over 105,273 holders and a recent all-time high of $0.05, reflecting a remarkable 2600% increase in value over the past month. Fueled by the Base network's growth, DEGEN is poised to become the governance token for its own Layer3 ecosystem.

DEGEN’s growth: Let’s look Onchain

I crunched some blockchain data on Dune to get the insights for this section.
You can view the full dashboard here, and share your feedback.

Degen on Base Dashboard

Trading Volume surges over $580m

The total trading volume for DEGEN currently sits at $580.8 million, as of March 31, 2024.

Trading activity began in January with an average daily volume of $5 million. However, a surge started on March 14th due to the success of the Ethereum Duncan upgrade. This resulted in daily volume reaching $10.5 million and maintaining an uptrend, peaking at $142 million on March 31st.

Notably, the average buy-sell ratio of 50% suggests an active market with day traders capitalizing on short-term price fluctuations.

1.37m Transactions and still counting

Further evidence of DEGEN's growing popularity is evident in the analysis of transaction counts. Over 1.37 million transactions have been executed by a substantial community of 105,273 DEGEN holders.

Interestingly, on March 14th, when transaction counts were at 32,000, the average price was $0.0048. However, as daily transactions skyrocketed to a record-breaking 263,519 on March 31, the price climbed above $0.05.

This observed correlation suggests a causal relationship between increased trading activity and rising value of DEGEN.

First-time DEGEN Traders are growing

Currently, there are 105,273 DEGEN holders, with first-time holders growing significantly to reach a cumulative high of 49,800 by March 31st.

However, recurring traders contribute up to 80% of the daily transactions and volume, indicating a strong conviction in DEGEN's potential.

Top DEGEN holders sitting on Profit smiling

The top wallet holds approximately 15.04 billion DEGEN (worth $809.3 million) and sits on an unrealized profit of $30.2 million.

Interestingly, the fifth-largest holder, with 1 billion DEGEN, is sitting on the highest profit of $38.6 million.

My Thesis for DEGEN

DEGEN's growing popularity is fueled by its expanding utility and adoption within the Farcaster ecosystem and the Base network effect.

This momentum coincides with growing support for memecoins with real-world value, as evidenced by influential figures like Vitalik Buterin.

My thesis is that as the social value of memecoins and Farcaster's user base continue to rise, DEGEN is well-positioned to benefit from a network effect within the Base ecosystem. This could ultimately solidify its place as a prominent player in the memecoin meta-game.

Thanks for reading Onchain Curiosity! Subscribe for free to receive new posts and support my work.

Among the 11 Bitcoin ETFs, Grayscale’s ETF (GBTC) has experienced the most substantial net outflow, totaling $5.8 billion. Conversely, BlackRock’s IBIT has attracted approximately $3 billion in net inflows, and Fidelity’s FBTC has gained $2.4 billion over the last 3 weeks.

A good explanation for GBTC’s significant outflow could be its relatively high fee of 1.5%, leading investors to explore more cost-effective options like BlackRock and Fidelity, both offering a lower fee of 0.25%.

Despite the outflows, GBTC maintains its top position among ETF providers, boasting a market share of 73.6%.

Presently, GBTC holds 476k BTC valued at $20.5 billion in its ETF treasury. Following closely are Fidelity and BlackRock, each holding 62k BTC valued at $2.7 billion.

Overall, the total value of all ETF holdings stands at $28.3 billion, representing 3.31% of the current Bitcoin supply.

This analysis is part of my 100 Days of Crypto Data challenge. Many thanks to Hildobby for inspiring this Dashboard. For a more comprehensive view, you can check out my Bitcoin ETFs Overview dashboard on Dune.

Stay Curious...

Thanks for reading Onchain Curiosity! Subscribe for free to receive new posts and support my work.

As a Data Analyst and Crypto Enthusiast, I've delved into Dune Analytics, querying the Bitcoin database to track essential onchain trends that can guide our investment decisions.

In this first part of my Bitcoin data analysis, I'll present key insights from a Dune dashboard that covers fundamental metrics such as price, user activities, hash rate, block rewards, and miner’s lifetime revenue.

For a comprehensive view, you can explore the complete Bitcoin Data Dashboard on Dune.

Bitcoin Data Dashboard

BTC Price pushes above $42k

The approval of spot Bitcoin ETFs appeared to trigger a "sell the news" event, prompting profit-taking by numerous whales as the price touched $49,000. Additionally, the Grayscale Bitcoin Trust (GBTC) experienced outflows of $429 million, leading BTC to reach a low of $39,000 within the last 14 days.

Despite this, insights from the BTC price chart below indicate an uptrend, reaching a high of $42,209 as of the time of writing.

Inflows across all spot Bitcoin ETFs currently stand at $1.13 billion, suggesting more institutional demand for BTC while supply continues to shrink as we approach the next Bitcoin halving.

Users Transactions hits 14 million.

The health of a blockchain network is often gauged by user and developer activities. According to Dune data, transaction counts by users currently stand at 14.74 million, indicating growing momentum despite the sharp decline in the previous month due to price fluctuations.

Bitcoin Hash rate and difficulty continues to rise

Bitcoin's proof-of-work (PoW) network demands robust computational power from miners, directly influencing the hash rate and mining difficulty.

The current hash rate stands at 523.918 EH/s, with mining difficulty at block height 827,468 reaching 70.34 T.

The continuous rise in the mining difficulty and hash rate enhances the security of the Bitcoin network, making it incredibly hard for attacks.

Bitcoin Miners earn $48 million in 24 hours

Miners compete to approve transactions on the Bitcoin network, in exchange for rewards in BTC.

Dune Data reveals that in the past 24 hours, Bitcoin miners generated approximately $48 million, pushing their lifetime revenue above $861.5 billion.

Conclusion

The approval of spot Bitcoin ETFs, along with the surge in user activities and the record-setting hashrate, presents a positive outlook for Bitcoin's future despite short-term market fluctuations.

As we anticipate the 4th cycle of the halving, BTC supply will continue to shrink, and the price is expected to rise. The big question today is, how high can BTC soar from here?

-

Until next week, remember that…

Fortune Favours the Bold

Thanks for reading Onchain Curiosity! Subscribe for free to receive new posts and support my work.

Pooly Together is a savings protocol designed to help people save money, built on the premise of Prize Savings:

A savings account that offers chances to win large prizes. The prizes are derived from the interest that accrues on deposits and therefore is “no loss”.

The Pooly NFT collection is a set of NFTs owned by people supporting Pool Together in defending itself against legal battles.

Purchasing the Pooly NFT is a way to support PoolTogether Inc. in its legal class action lawsuit.

Onchain Findings

Our analysis of the NFT mint event on the Pooly NFT collection revealed the following key insights:

• Pool Together successfully raised approximately 1028 ETH through the sale of its NFT collections.

• The Pooly Collection raised a total of $2.5 million, surpassing its funding goal of $1.9 million.

• A total of 6327 unique supporters actively participated in the NFT minting event.

• The NFT collection achieved a 64% sell-through rate, with 6706 Supporters, 297 Lawyers, and 1 Judge NFTs being purchased.

• Notably, the highest amount paid for a single NFT in the Judge collection was 75 ETH.

Dive into the Dune Dashboard

Conclusion

The success of the Pooly NFT collection in raising over $2.5 million underscores the strong support Pool Together has garnered from a substantial community. This serves not only as a testament to the commitment of the community but also as a unique and impactful way for individuals to actively contribute to Pool Together's legal defense efforts.

I’m so happy to see that you read this far. Thank you so much for your support. I would appreciate your kind feedback to help me improve and get my next best work done.

Let’s connect via Twitter

Thanks for reading Onchain Curiosity! Subscribe for free to receive new posts and support my work.