And it’s dawned on me that querying lending and borrowing markets on Morpho via Dune can be daunting, a little frustrating, and also quite exciting.

The Analysis on the LevelUSD protocol was to look at the utilisation of lvlUSD and slvlUSD alongside other insights across Defi use cases like Pendle, Morpho, Curve, and Spectra.

You can find the complete dashboard here: https://dune.com/0nchainlabs/level-lvlusd-dashboard

While working on the utilisation of lvlUSD and slvlUSD on Morpho, my first scope was to analyse the lvlUSD and slvlUSD associated vaults: M11C Level lvUSD vault and Steakhouse Level USDC vault, and then query the Total Value Locked (TVL) or Total Deposits in both vaults.

Morpho, for those unfamiliar, is a permissionless lending protocol on Ethereum that allows curators to create optimized vaults for lending assets like lvUSD (a synthetic stablecoin from Level Finance) and USDC.

So I began with a common approach, calculating net flows from deposit and withdrawal events, but ran into issues when the figures didn’t match the vault’s displayed stats on the Morpho app on the Steakhouse Vault.

It was strange, the same query was working great with near-matched results on M11C Vaults; however, the Steakhouse vault was showing something I’d never seen before, which is Idle Liquidity.

Since these are new waters for me, I started reading up on them, and Andrew Wong’s resources were invaluable in understanding what this means, as well as the right logs to decode and query to achieve my desired result.

And in this article, I’ll walk you through both methods I used, how I applied them, and I’ll include exact SQL queries I used on Dune Analytics and the data outputs from my runs at the time.

Let’s Understand What Idle Liquidity Means from a Data POV

Press enter or click to view the image in full size

In the context of Morpho vaults (like the USDC shown in the screenshot, which appears to be on Steakhouse Vault on Morpho Blue), “Idle Liquidity” refers to the portion of the vault’s total deposited assets that is not currently allocated or lent out to any active markets or external protocols.

Instead, these assets are held directly in the main vault contract as a readily available buffer. This ensures quick access for user withdrawals and provides flexibility for the vault’s curator or allocator to deploy capital strategically without immediate risk exposure. Why is this important?

• Separation of Assets: Morpho Vaults v2 explicitly distinguishes between idle liquidity (unallocated capital) and allocated capital (assets supplied to yield-generating markets via adapters).
  All user deposits start as idle liquidity in the vault contract. The vault’s allocator can then move portions of it to specific markets (e.g., the PT-lvlUSD-25SEP2025/USDC in the screenshot, which has a 3.07% allocation).

• Conservative risk management: The vault’s curator sets caps (absolute or relative) on allocations to limit exposure to certain collaterals or markets, leaving more assets idle to avoid volatility or potential bad debt.

• Liquidity prioritization: To handle potential withdrawals without needing to pull funds from illiquid positions.

• Market conditions: If yields in available markets are low or risky, the allocator might hold back deployment.

In USDC Markets specifically, here, USDC is the loan token (the asset being lent). Idle liquidity in these markets represents USDC deposits not yet supplied to borrowers against collaterals like PT-lvlUSD, IvUSD, or slvUSD.

Which means it’s essentially “parked” USDC, earning no yield, contrasting with allocated portions that generate interest from borrowers.

No doubt this is really normal with Defi Lending and Borrowing. But from a Data POV, it completely changes how you approach analysing this vault because this changes the whole outlook of your results. Here’s what I mean.

The Setup: My Querying Experience

I was analyzing the M11C Level lvUSD vault and the Steakhouse Level USDC vault. Where, at the time I was writing this, the Morpho app showed TVL values of about $395.50k for M11C and $20.43k for Steakhouse.

These are ERC-4626-compatible vaults, meaning they emit standard events for deposits, withdrawals, and state updates, making them queryable via Ethereum logs.

I started with Method 1: Summing all historical deposits minus withdrawals to reconstruct the TVL. This seemed logical, like tallying a bank ledger.

I wrote a SQL query to pull Deposit and Withdraw events, extract the asset amounts (scaled by 1e6 for USDC/lvUSD decimals), and compute the net.

Here’s the exact query I ran for the Steakhouse vault:

But wait, these results didn’t match the Morpho app’s $20.43k!

Press enter or click to view the image in full size

Snapshot from a Morpho Steakhouse Vault

Was the query wrong? No. What about the logic? Also No. So why? Why is this result negative?

Well vaults like these accrue interest, take fees, and rebalance assets internally (e.g., lending out to Morpho markets), which aren’t captured in simple deposit/withdraw events.

Also, remember the Idle Liquidity? Yeah, at this point, that liquidity is in the vault, but there’s been no deposit/withdrawal events to account for it because it is Idle.

Hence, the query and logic of method one would work. Thanks to some resources (actually, Andrew Wong's resources), I noticed recurring UpdateLastTotalAssets events in the log on all transaction receipts.

And found out that these events are emitted whenever the vault’s total assets change, not just from user actions but also from internal updates like interest accrual or reallocations.

This event directly logs the absolute current total, like a bank’s official balance statement. Switching to this (Method Two) fixed everything.

All I did was leave the deposit/withdrawal event. Decode the UpdateLastTotalAssets events instead (as shown below). And decoding the data column using varbinary_to_uint256 to find the total_deposits. Doing this is simply you querying the state snapshot.

The Two Methods: Net Flows vs. State Snapshot

There are two primary ways to query TVL in a Morpho vault using Ethereum logs, as I have shown above:

1. Method 1: Net Flows (Sum Deposits Minus Withdrawals)

• How to Do It: Aggregate all Deposit and Withdraw events from the vault’s inception. Extract the assets field from the data blob (first 32 bytes), scale by decimals (1e6 for USDC/lvUSD in this case), and compute the net.

• Differences from Method 2: This reconstructs TVL historically, treating the vault like a flow-based ledger. It ignores internal adjustments (e.g., interest from lending in Morpho markets or curator fees).

1. Method 2: State Snapshot (Latest UpdateLastTotalAssets Event)

• How to Do It: Query the most recent UpdateLastTotalAssets event. The data field is the raw totalAssets uint256, divided by 1e6 for a readable value.

• Differences from Method 1: This uses the vault’s internal state update, which is emitted on every change (user actions, accruals, rebalances). It’s an absolute value, not a reconstruction.

Which is Better? Pros and Cons

In my experience, at least from this experience, which has cost me literally the whole day. Method 2 (State Snapshot) is far superior for current TVL queries.

It’s what I will now use exclusively for dashboards and monitoring. Here’s why:

Pros of Method 1 (Net Flows):

• Great for historical analysis or auditing flows over time (e.g., track user behavior or net inflows monthly).

• Transparent: You see every transaction contributing to the total.

• Useful for understanding patterns, like in my 30-day activity query, where I saw deposits of ~$52.8k outweighing withdrawals.

• Also very great for seeing granular data,

Cons of Method 1:

• Error-prone: Misses non-user changes like interest (via AccrueInterest events) or reallocations, leading to mismatches (e.g., my negative TVL issue).

• Computationally heavy: Summing thousands of events can hit query limits on platforms like Dune.

• Inaccurate for live monitoring: Vault balances “suddenly” change without new deposits/withdrawals, making the figures wrong quickly.

Pros of Method 2 (State Snapshot):

• Reliable and accurate: It’s the vault’s own accounting — includes everything (deposits, withdrawals, interest, fees, rebalances).

• Efficient: Just one event to query, fast for real-time use.

• Matches official sources: Aligned perfectly with the Morpho app stats in my tests.

Cons of Method 2:

• Less granular: Doesn’t show historical breakdowns without querying multiple events.

• Relies on event emission: If the vault stops updating (rare, but possible in bugs), it’s stale, although Morpho vaults are updated regularly.

Overall, Method 2 is better for 90% of use cases, especially current TVL, where you need to also account for vaults with Idle Liquidity, which you could miss using Method 1.

Still, Method 1 shines for forensics or trends, but requires supplementing with AccrueInterest to account for yields, which is also very important

Level Protocol's fundamental premise was compelling: to create a stablecoin that generates a sustainable yield from real economic activity, rather than relying on token emissions. Users could stake lvlUSD into slvlUSD to capture returns from borrowing demand across integrated lending markets.

The protocol's design centers on delivering sustainable, low-risk yield from blue-chip DeFi lending protocols. Users can hold lvlUSD as a stable asset or stake it into slvlUSD to earn automated yield while maintaining composability across DeFi applications. And the same time, $2.4 million in cumulative yield has been distributed.

As of October 2025, Level Protocol had a total lvlUSD supply of $3.37 million with slvlUSD at $1.95 million, representing a combined $5.32 million in circulating tokens. The staking ratio sits at 0.5444, indicating that 54% of lvlUSD holders have chosen to stake their tokens into the yield-bearing slvlUSD variant.

The weekly supply chart traces the protocol's trajectory from its October 2024 launch through October 2025. Starting from near-zero, the supply peaked in May 2025 at approximately $184 million before declining to current levels.

This analysis examines on-chain data across Level Protocol's primary liquidity venues, Pendle, Curve, Morpho, and Spectra, tracking adoption patterns, liquidity distribution, and usage trends from launch through October 2025.

Access the Dashboard here: https://dune.com/0nchainlabs/level-lvlusd-dashboard

lvlUSD & slvlUSD Utilisation and Distribution

Examining the distribution across all venues reveals how Level Protocol's liquidity was allocated throughout the DeFi ecosystem.

At peak capacity in May-July 2025, Pendle held approximately $30 million, Curve held roughly $16 million across both pools, Morpho reached $10 million, and Spectra achieved $20,000. This accounts for approximately $46 million across the four tracked venues.

With a peak total supply of $184 million, the tracked venues represent roughly 26% of total protocol supply. The remaining 74% was probably distributed across direct holdings, other DeFi integrations, wallets, or applications not captured in this analysis.

Pendle: Principal Yield Tokenization

Pendle tokenizes yield-bearing assets, allowing users to split assets into ownership and yield components for separate trading. Level Protocol achieved significant traction on this platform, making it one of the protocol's largest liquidity venues.

The platform showed near-zero activity in April 2025, growing rapidly to approximately $30 million in total value locked by early July 2025. This $36 million peak represented the protocol's strongest single-venue performance across the entire ecosystem.

Current TVL stands at $816,704 as of October 2025.

The composition of assets on Pendle evolved notably over time. During the growth phase, slvlUSD dominated liquidity pools, reaching roughly $29 million, while lvlUSD held around $8 million.

By September 2025, this distribution shifted toward approximate parity.

Curve: Stablecoin Exchange Dynamics

Curve Finance operates as a decentralized exchange optimized for stablecoin swaps with minimal slippage. Level Protocol deployed two distinct pool types on Curve: lvlUSD/USDC and slvlUSD/lvlUSD, each serving different user preferences.

The lvlUSD/USDC pool currently holds $492,225 in TVL, while the slvlUSD/lvlUSD pool holds $185,538. This creates a 2.65x size ratio favoring the USDC-paired pool.

However, both pools grew steadily from April 2024 through July 2025, with the monthly TVL chart showing a consistent upward trajectory during this period.

The larger size of the lvlUSD/USDC pool probably demonstrates user preference for trading against established stablecoins rather than swapping between lvlUSD variants.

Morpho: Lending Market Performance

Level Protocol deployed two lending markets on Morpho: the M11C vault and the Steakhouse vault, each attracting different levels of user engagement.

The M11C vault currently holds $168,779 in TVL, representing 95% of total Morpho lvlUSD activity. The Steakhouse vault holds $1,852, accounting for the remaining 5%. This 20x difference in size indicates strong user preference for the M11C vault, likely due to earlier launch timing, greater visibility, or more attractive yield parameters, or it could be any factor really.

• The M11C vault's activity timeline shows distinctive patterns. The vault experienced rapid growth to approximately $2 million in early June 2025. This was followed by significant volatility through July, with TVL declining to near-zero before partially recovering to current levels.

• The Steakhouse vault experienced rapid growth to approximately $14 million in early June, launching after M11C, and has since flattened out to current levels.

Morpho's lending markets captured meaningful protocol usage, with the Steakhouse vault achieving eight-figure TVL during its peak performance period.

Spectra: Enhanced Yield Pools

Level Protocol's presence on Spectra represents the smallest of the four major venues analyzed, but provides insights into user behavior around higher-yield opportunities.

Current TVL on Spectra stands at $1,439. The pool's history shows it launched around July 20, 2025, experiencing rapid initial growth to approximately $20,000 by July 27, a 14x increase in the first week of operation.

This represented the fastest relative growth rate across any Level Protocol venue.

Interestingly, the pool's composition has consistently favored lvlUSD, which comprised roughly 60-70% of the pool during its peak and continues to dominate the current distribution.

Level Protocol Data Observations

The Level Protocol Dashboard was something that I had been working on for some months at @0nchainlab to capture the complete cycle of Level Protocols stablecoin and its utilisation. The subsequent months through October 2025 show the protocol operating at reduced but stable levels around $5 million in combined Supply.

Maybe that's due to the announcement that the Level team is getting acquired by a leading DeFi protocol and the team would be joining them, thereby sunsetting both the lvlUSD and slvlUSD.

Users have no idea they’re interacting with Web3. That invisibility is the product’s genius, but it also means the blockchain holds insights Amex isn’t publishing.

I built a Dune dashboard to decode it. Here’s how.

The Architecture Worth Understanding

Before writing queries, you need to grasp what Amex built:

• Account Abstraction (ERC-4337) gives each user a smart contract wallet instead of a standard EOA. Amex’s backend controls minting, no seed phrases, no user action required.

• Paymaster contracts cover all gas fees. Users pay nothing. Amex funds a contract that validates legitimate mints and reimburses costs through the EntryPoint.

• Soulbound tokens have disabled transfers. Stamps can’t be sold,  purely commemorative. No speculation, no secondary market noise.

The Contracts

Three addresses matter:

• NFT Contract: 0x96cebb59b00109dc8c4de1a9a94d9fad658fee46

• EntryPoint (v0.7.0): 0x0000000071727de22e5e9d8baf0edac6f37da032

• Paymaster: 0x5fa66dfe8a3983e55071e8c4631ab43b5f33a4ab

Query 1: Daily Mints and Unique Wallets

The Transfer event (0xddf252ad...) fires on every mint. Key filter: topic1 equals the zero address, that's a mint, not a transfer.

SELECT
  varbinary_ltrim(topic2) AS minted_to,
  varbinary_to_uint256(topic3) AS token_id
FROM base.logs
WHERE contract_address = 0x96cebb59b00109dc8c4de1a9a94d9fad658fee46
  AND topic0 = 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef
  AND topic1 = 0x0000000000000000000000000000000000000000000000000000000000000000

varbinary_ltrim() strips left-padding from addresses. varbinary_to_uint256() converts the token ID. I join this with the TokensMinted event (0x9d89e36e...) to pull IPFS URIs when needed.

The full query aggregates daily mints, unique wallets, cumulative totals, and a 7-day moving average to smooth noise.

Query 2: Wallet Distribution

Are stamps concentrated in whales or spread across users?

WITH wallet_mint_counts AS (
  SELECT
    varbinary_ltrim(topic2) AS wallet,
    COUNT(*) AS stamps_per_wallet
  FROM base.logs
  WHERE contract_address = 0x96cebb59b00109dc8c4de1a9a94d9fad658fee46
    AND topic0 = 0xddf252ad...
    AND topic1 = 0x0000...
  GROUP BY varbinary_ltrim(topic2)
)
SELECT
  stamps_per_wallet,
  COUNT(*) AS wallets_with_this_count
FROM wallet_mint_counts
GROUP BY stamps_per_wallet

I bucket wallets by stamp count and calculate the percentage of total wallets and stamps per bucket. The data shows remarkably even distribution, no whale dominance, indicating organic adoption across diverse cardholders.

Query 3: Gas Economics

This reveals Amex’s actual infrastructure costs. The UserOperationEvent from EntryPoint contains everything:

SELECT
  varbinary_to_uint256(varbinary_substring(data, 1, 32)) AS nonce,
  varbinary_to_uint256(varbinary_substring(data, 33, 32)) > 0 AS success,
  varbinary_to_uint256(varbinary_substring(data, 65, 32)) AS actual_gas_cost_wei,
  varbinary_to_uint256(varbinary_substring(data, 97, 32)) AS actual_gas_used
FROM base.logs
WHERE contract_address = 0x0000000071727de22e5e9d8baf0edac6f37da032
  AND topic0 = 0x49628fd1471006c1482da88028e9ce4dbb080b815c9b0344d39e5a8e6ec1419f

The data field packs non-indexed parameters sequentially in 32-byte chunks. I filter for operations that paymaster_used match Amex's Paymaster address, then join with it prices.usd to convert ETH costs to USD at the minute-level.

The final output: daily sponsored operations, gas costs in ETH and USD, cost-per-stamp, and cumulative spend over time.

Technical Notes

• Use DuneSQL’s varbinary functions: varbinary_ltrim(), varbinary_to_uint256(), and varbinary_substring() handle hex data cleanly. Don't fight with string casting.

• Always filter for mints: Transfer events fire for both mints and transfers. Without the zero-address filter, you’ll miscount.

• Verify byte offsets: The UserOperationEvent packs data at specific positions (1–32 for nonce, 33–64 for success, etc.). Get these wrong, and you’ll extract garbage. Cross-reference with the contract ABI on BaseScan; this helps too.

• Join prices at minute granularity: The prices.usd table on Dune provides minute-level pricing. Match on date_trunc('minute', block_time) for accurate USD conversion.

What the Data Shows

The dashboard reveals what Amex won’t publish: real adoption curves, cost efficiency trends, and wallet concentration metrics. And to be honest, they dont need to. Public blockchains create accountability, even when the company abstracts the technology completely.

View the full dashboard →

And stablecoins can be the bridge connecting these transactions across traditional and decentralized finance.

That’s why Aptos is well-positioned to support the growing stablecoin ecosystem, with its capacity to scale high-volume cross-border transactions while processing over 160,000 transactions per second. According to an article by @SashaSpiegelman and @rgelash, @Aptos achieves this high throughput using a multi-threaded, in-memory parallel execution engine that leverages Software Transactional Memory (STM).

TLDR: Transactions are faaast. These transactions confirm quickly and also cost mere fractions of a cent—roughly $0.00002 per transaction.

The edge Aptos brings is quite competitive for stablecoins that aim to beat the effectiveness of fiat alternatives on payment rails like Visa or Mastercard. And as @moshaikhs noted on Chain Reaction:

There is a need for a new way to share information digitally, one that allows users to exchange both information and economic value more efficiently and fairly, Aptos.

Aptos is the new way, and the emphasis here is on how efficient the blockchain is across multiple use cases, especially payments.

Currently, Stablecoin's supply on Aptos is peaking at $729.8m, and the strong growth trend from January to now is easily visible. Thanks to the launch of both USDT and USDC back-to-back this quarter.

Stablecoins are fast, cheap, and scalable on @Aptos.

With transactions and payments, the conversation between users or businesses usually revolves around Fees, Time to settle, and Convenience (ease of use).

Solutions that offer a competitive advantage across these factors tend to have an uncanny edge in the market. Aptos offers that advantage; here's how:

Fees

If Aptos is that fast, does it increasingly outperform other alternatives like MoneyGram, Western Union, Mastercard, etc.? Yes, it does.

Traditional rails, which you use daily, can take hours/days to settle cross-border transactions or charge 2–3% of each transaction, hitting small businesses especially hard.

So, if a coffee shop only nets a dollar of profit for every two-dollar latte sold, losing an extra 15 cents to payment fees significantly hurts margins.

Utilizing stablecoins via Aptos, by contrast, can lower these fees almost to zero.

According to the @ournetwork__ report, Aptos is the cheapest chain for USDT transfers, costing about $0.0002 in fees.

From a business perspective, having a steep drop in transaction fees could offer business owners more operational opportunities and better margins, amongst other perks.

Settlement Period

The settlement period for a transaction is another focus for users, especially with cross-border payments.

Services like MoneyGram and Western Union can take up to 4 days to finalize transactions outside the European Economic Area.

In contrast, Aptos achieves settlement in approximately 6.5 seconds, outside the European Economic Area, regardless of the location.

This 6.5-second block time ensures fast and efficient transaction confirmations, making Aptos a competitive solution for financial applications and real-time use cases.

The speed also impacts the ease of remittances, where you can send USDT (on Aptos) to someone back home, pay about $0.0002 in fees, and it arrives in about 6.5 seconds or less.

That’s a game-changer, not just for individuals, but also for small businesses in emerging markets in West Africa that suffer from slow wire transfers and high exchange markups.

Now, someone in the UK can send money back home to Senegal quickly and cheaply, 0.00002$, removing multiple intermediaries and the associated risk of payment failure.

An alternative for this same transaction is to use Ria Money Transfer. To send 100 GBP, there's almost 700 XOF lost in exchange compared to other rates.

You'd also have to pay about 4 GBP in fees for this transaction to be processed within a couple of minutes or hours.

When it comes down to preference, I agree with @SamBroner comments on stablecoins being the cheapest way to send a dollar, with profitability unlock & a new platform.

Ease of Use

Convenience is the crux of it all.

What's the point of fast transactions, cheap fees, and an impressive permissionless composable infrastructure if users can't use it within real-world use cases like remittances and cross-border payments?

That's why I believe the Aptos Card, thanks to @thisisarculus and @AptosLabs collaboration, can unlock an interesting opportunity for users paying with real-world assets.

Similar to how I use @wirexapp card and now recently @KAST_official cards for real-world transactions.

More than that, thanks to the recent partnership with @stripe and @circle, there could be exciting on-ramp support for USDC on Aptos via Stripe.

This would make transactions easier and more convenient for the real-world use case.

Stablecoins Move Better on Aptos

Stablecoins have already proven they can move billions of dollars across borders faster and more cheaply than traditional rails and also accrue rewards for users.

Over-collateralized, yield-bearing stablecoin like MOD (Move Dollar) is specifically designed with reward mechanisms.

With over $2.3 B in traded volume, users can also stake MOD in the Thala Stability Pool (TSP) to earn rewards easily.

My thoughts are that as adoption grows, we could have an efficient way for users to exchange both information and economic value more efficiently and fairly.

For businesses, the bottom-line impact is profound: stablecoins can save billions in fees and expand cross-border trade. For users, stablecoins offer a simple, low-cost way to send value globally, cutting out an underbrush of banking intermediaries.

For developers, Aptos’ parallel execution engine and the Move programming language provide exciting ground for building next-gen DeFi applications, orchestrating stablecoin solutions, and bridging Web2 to Web3.

Ultimately, stablecoins move better on Aptos

Data Reference:

1. Aptos: Layer 1 Engineered To Evolve

2. $MOD Stablecoin Performance Analysis

3. ON–298: Stablecoins

4. Aptos || Stable Coin Supply

You see, I thought I could query a smart contract like a database. Pull up a wallet, check its balance at any point in time, done. But I quickly found out that is not how it works. With Flipside and Dune feeling really daunting to use at inception, I had to learn that the gap was in my understanding of smart contract fundamentals.

Once I understood how contracts actually work, what creates on-chain records versus what doesn't, everything clicked. This is what I wish someone had told me earlier when it came to data. Okay, here’s what I mean:

A smart contract is a program on a blockchain. Unlike server software, it runs on thousands of computers simultaneously and can't be modified once deployed. Think of it as a vending machine:

• The machine is the contract

• The buttons are functions

• The receipt is an event

• The product is the state change (tokens moving, balances updating)

The receipt is what we query as data analysts and engineers. However, the machine's internal state is harder to access directly.

My first real task was simple

Find the balance of a wallet at a specific block height from six months ago. I wrote what I thought was a straightforward query, looking for some kind of balance history table. Nothing came back.

I spent an hour thinking my SQL was wrong before I realized the data I was looking for did not exist. Not because it was deleted or hidden, but because it was never recorded in the first place.

Smart contracts have a function called balanceOf() that returns the current balance of any address. But here is the thing: calling that function does not create a transaction. It does not write anything to the blockchain. It just reads the current state and returns it. There is no log, no receipt, no record that the call ever happened.

That was my first real lesson. Read functions are invisible. They answer questions in the moment but leave no trace for analysts to find later.

Why Some Data Exists, and Some Doesn't

This confused me initially. The answer lies in understanding functions.

• Write functions that modify the blockchain. When called, they create a transaction with a hash, block number, timestamp, and gas cost. This is queryable data.

• Read functions only retrieve the current state. They're free to call, create no transaction, and leave no on-chain trace.

This is why you can't directly query "what was wallet X's balance at block Y" in Dune. That's a read function result. But you can reconstruct it by aggregating Transfer events; every balance change leaves a receipt. That’s the trick.

To understand this better, think of it like a Vending Machine

Someone gave me an analogy that made everything fall into place.

Think of a smart contract like a vending machine. You walk up, put in money, press a button, and get a snack. The machine has rules built into it. If you pay the right amount and press a valid button, you get your product. No negotiation, no human intervention.

Now think about what gets recorded:

• Pressing a button that dispenses a snack? That is a write function. Something changed. The machine's inventory went down, your money went in, and there is a receipt.

• Looking at the display to see what is available? That is a read function. You got information, but nothing changed. No receipt.

As a data analyst, you only have access to the receipts. This reframed everything for me. I stopped looking for data that was never written and started focusing on what was: the events.

Events: The Analyst's Primary Data Source

Events are the primary data source for blockchain analytics. They are structured logs that contracts emit when something happens.

The standard ERC-20 Transfer event looks like this:

Plain Text

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

Every time tokens move, this event fires. It records who sent, who received, and how much. This is what I query in Dune.

The word "indexed" matters. Indexed parameters become "topics" that I can filter on efficiently. The Transfer event has from and to indexed, which means I can quickly find all transfers to or from a specific address.

In Ethereum logs:

• topic0 is the event signature (identifies which event type)

• topic1 is the first indexed parameter (from)

• topic2 is the second indexed parameter (to)

• data contains everything else (value)

When I write a query to find all transfers to a specific wallet, I am filtering on topic2.

Function Selectors and Event Signatures

Every function and event has a unique identifier. These are hashes that look like 0xa9059cbb for functions or 0xddf252ad... for events. For the transfer(address,uint256) function:

• Take the function signature: transfer(address,uint256)

• Hash it with keccak256

• Take the first 4 bytes: 0xa9059cbb

This selector is included in every transaction that calls this function. So if I want to find all transfer calls (not just the events, but the actual function calls), I can filter transactions by this selector.

For events, it is similar but uses the full 32-byte hash as topic0.

[Updating what I do now]: Now, I do not calculate these by hand. Tools like Herd.eco show them for every function and event, which saves time. Previously, when this article was written, you’d need to do it manually.

Another Thing I Learned About Addresses

Ethereum addresses are case-insensitive, but SQL comparisons might not be. I ran into issues early on where queries returned nothing because of case mismatches.

Now I always normalize addresses to lowercase or use the native bytea format in DuneSQL:

-- This works in DuneSQL WHERE contract_address = 0x7e2ac793f3E692f388e66c7DC28F739d13B0B71A

Another thing: addresses in topics are padded to 32 bytes. So a 20-byte address gets 12 bytes of zeros in front. This matters when working with raw logs. I assumed that a contract address always meant the same code. That is not true for upgradeable contracts.

Many contracts use a proxy pattern. There are two contracts:

1. The proxy holds the state (balances, etc.) and has the address everyone uses

2. The implementation holds the logic and can be swapped out

When the team upgrades the contract, they deploy new logic and point the proxy to it. The address stays the same, but the code changes.

For data analysis, this means historical data might have been generated by different code than what exists today. If I am analyzing a contract that has been upgraded, I need to check when the upgrades happened and whether they changed anything relevant to my analysis.

The Upgraded event tells me when implementation changes occurred. Now, when I use Herd.eco to analyze a contract, I see emission counts for each event. Some show zero. At first, I thought this meant the event was not implemented. That is wrong. It means the event exists in the code but has never been triggered.

The zero-emission events are still important. They tell me what the contract can do, even if it has not done it yet.

For risk analysis, knowing that a contract has blacklisting capability matters even if no one has been blacklisted.

How I Approach a New Contract Now

When I need to analyze a new contract, here is my process:

Step 1: Identify the basics

• Is it upgradeable? (Check for proxy patterns)

• What standard does it follow? (ERC-20, ERC-721, custom)

• When was it deployed?

Step 2: Map the functions

• What write functions exist?

• Which ones have actually been called?

• What access control is in place?

Step 3: Map the events

• What events does it emit?

• Which ones have emissions?

• What data do they contain?

Step 4: Build queries from events

• Start with the high-emission events

• Reconstruct state from event history

• Add filters for specific analysis

Tools like Herd.eco make steps 2 and 3 fast. I can see all functions and events with their call counts and signatures in one view.

Reconstructing Historical State

Since I cannot query historical read function results directly, I reconstruct the state from events.

For token balances:

WITH transfers AS ( SELECT "to" as address, CAST(value AS DECIMAL(38,0)) as amount FROM erc20_ethereum.evt_Transfer WHERE contract_address = 0x7e2ac793f3E692f388e66c7DC28F739d13B0B71A UNION ALL SELECT "from" as address, -CAST(value AS DECIMAL(38,0)) as amount FROM erc20_ethereum.evt_Transfer WHERE contract_address = 0x7e2ac793f3E692f388e66c7DC28F739d13B0B71A ) SELECT address, SUM(amount) / 1e18 as balance FROM transfers WHERE address != 0x0000000000000000000000000000000000000000 GROUP BY address HAVING SUM(amount) > 0 ORDER BY balance DESC

This gives me current balances. To get historical balances at a specific block, I add a block number filter:

Mints and Burns Are Just Special Transfers

This was a small realization, but it simplified my thinking.

A mint is a Transfer event where the from address is the zero address (0x000...000). Tokens are created from nothing.

A burn is a Transfer event where the to address is the zero address. Tokens are destroyed.

So I do not need separate mint and burn queries. I just filtered Transfer events:

-- Mints
WHERE "from" = 0x0000000000000000000000000000000000000000 -- Burns WHERE "to" = 0x0000000000000000000000000000000000000000

Some contracts emit custom TokensMinted or TokensBurned events with additional data, but the Transfer event is always there.

What I Wish I Knew Earlier

1. Read functions leave no trace. Do not look for data that does not exist.

2. Events are the data source. Learn to work with them.

3. Indexed parameters are filterable. Check which parameters are indexed before writing queries.

4. Upgradeable contracts change over time. Check for proxy patterns and upgrade history.

5. Zero emissions means unused, not missing. The capability exists even if it has not been used.

6. Addresses need normalization. Be defensive about the case and formatting.

7. Tools exist to speed this up. Herd.eco, Etherscan, and others show contract structure without reading code.

8. Historical state is reconstructed, not queried. Build it from events.

Resources That Helped Me

• Dune Analytics Documentation - Query patterns and table schemas

• Etherscan - Contract verification and basic analysis

• Herd.eco - Function and event mapping with call counts

• OpenZeppelin Docs - Standard contract patterns

• EIP-20 - The ERC-20 token standard