Business Intelligence for Web3 and Web3 On-Chain User Insights: Turning Indexed Ethereum Data Into Dashboards

---

Why on‑chain BI looks different in 2026

So, the Dencun upgrade rolled out on March 13, 2024, and it introduced these cool new "blobs" thanks to EIP-4844. It's kind of wild--this whole new fee market and data channel pops up, but it only lasts for about 18 days. This change really helped lower Layer 2 costs and ramped up the use of rollups. It's made a big difference in the world of data analytics! (investopedia.com). So, each blob is about 128 KB, give or take. So, the blocks are set up to aim for 3 blobs at a time, but they can handle up to 6 blobs if needed. We keep an eye on the fees for these blobs through some new header fields, specifically blob_gas_used and excess_blob_gas. Just a heads up: the data stored in the blobs isn’t directly accessible to the EVM, and it gets deleted after about 18 days. So, if your BI team wants to get their hands on that data, they'll need to retrieve it from the archivers. Just something to keep in mind! (eips.ethereum.org). Layer 2 solutions have really become the top choice for retail and mid-frequency activities in DeFi and social platforms these days. Fees have dropped dramatically, by as much as 90 to 99%, especially on the largest rollups. This huge decrease is making it a lot easier for dashboards to break down user data in much more specific ways. (investopedia.com).

So, what this really means is that your BI setup has to be pretty savvy when it comes to handling those “blobs.” You’ll need to keep tabs on those L2 log volumes and make sure you can link identities across various chains and layers, like ERC-4337. It’s all about keeping everything connected and organized!

---

The reference Web3 BI stack

• Data Capture You’ve got a few options here. You can either go for execution clients or managed RPCs like Reth and Erigon, or you could choose providers that offer log indexing. It's really about what fits your needs best! If you want to dive deeper into it, feel free to click here to get more info! When you're digging into event and log retrieval, just remember to pay attention to pagination and those provider-specific limits on ranges. For instance, the eth_getLogs function might have some restrictions based on your plan or the particular blockchain you're working with. Get the details here. If you're trying to check out blob content, you should definitely check out some archivers like Blockscout Blobs and Blobscan. Just a heads up, though: beacon nodes tend to prune data after around 18 days, so it’s a good idea to grab what you need before that happens! If you’re looking for more details, check it out here!
• Indexing Hey, why not give subgraphs a shot on The Graph Network? They’re now up and running on Arbitrum One! If that doesn’t suit your vibe, there are some other cool hosted indexers you might want to check out too. Happy exploring! If you want to dive deeper into the topic, check out this link. It's got all the details you might need!
• Warehousing Check out BigQuery's public crypto datasets, like "crypto_ethereum," along with your own curated warehouses. You might find some really interesting insights! If you want to dive deeper into this, just check it out here. You'll find plenty of info waiting for you!
• Modeling
• Check out community-approved tools like the Dune Spellbook or dbt; they’re great places to kick off your dbt models! Take a look at the resources right over here. You might find some really useful stuff!
• Visualization If you're looking to create some cool visualizations, you've got a few great options! Metabase, Looker Studio, and Tableau are all solid choices. Plus, if you want to embed charts, the Dune API does a fantastic job, too. So, take your pick! Oh, and let’s not overlook the possibility of custom web apps! They're definitely worth considering. If you're curious to learn more, check out all the specifics right here. It's got everything you need!

---

Capture and index: precise 2026 guidance

1) Choose your node/indexer footprint

• Reth 1. Everything's ready for production, and it’s lightning-fast with RPC, indexing, and simulations! Thanks to its staged-sync and revm stack, you can expect super fast reads with minimal delay. If you’re looking to maintain local control over your RPC functions and want to tap into your historical traces, this is definitely a solid option! Take a look at this: (paradigm.xyz). It's worth checking out!

Hey, so Erigon 3 has come up with some handy disk profiles. If you're looking at the mainnet full version, it's roughly 920 GB. On the other hand, the archive version is a bit heftier, coming in at about 1 TB. By September 2025, we’re looking at 77 TB. Make sure you plan out your NVMe and RAM wisely! If you're diving into analytics that don't need historical state proofs, then pruning modes are definitely the way to go! If you want to dive deeper into it, check this out: docs.erigon.tech. Happy reading!

Hey, here's a quick tip! Try to space out your reads by different chains--like mainnet, Base, Arbitrum, and OP Mainnet. It's a good idea to use dedicated endpoints for those big log scans. It'll make things a lot smoother for you! This way, you can avoid any throttling problems.

2) Respect eth_getLogs realities

Just a heads-up: Provider APIs put some limits on block ranges and how much data you can pull at once to keep everything secure. So, when you’re setting things up, you’ll want to create a paginator that organizes the data by block and topic. It’ll make life a lot easier! So, for example, Alchemy sets different limits based on the plan you choose. On the other hand, Chainstack recommends keeping your block windows between 5,000 and 10,000. Take a look at this link: alchemy.com. You'll find some useful info there!

Pseudo-code Pagination (JS):

Let me share a straightforward approach to tackle pagination with some pseudo-code in JavaScript. It’s really easy to get the hang of! This will help you understand the logic without getting caught up in all the complicated details.

Basic Structure

1. Define your data: Kick things off by gathering an array of items that you’d like to paginate.

let items = [...]; // Your array of items

2. Set up pagination variables:.

• currentPage: This just tracks which page you’re on right now.
• itemsPerPage: This setting controls how many items will appear on each page.
• totalPages: Figure out how many pages you’ve got in total based on the items you have.

  let currentPage = 1;
  const itemsPerPage = 10;
  const totalPages = Math.ceil(items.length / itemsPerPage);

3. Function to display items:.

Sure! You’ll want to whip up a function that grabs the current page number and then shows the right items based on that. Here’s a simple way to do it:

def display_items(current_page, items_per_page, all_items):
    # Calculate the start and end index for slicing the items
    start_index = (current_page - 1) * items_per_page
    end_index = start_index + items_per_page

    # Slice the list to get the relevant items
    items_to_display = all_items[start_index:end_index]

    # Show the items
    for item in items_to_display:
        print(item)

# Example usage
all_items = ['item1', 'item2', 'item3', 'item4', 'item5', 'item6']
current_page = 1
items_per_page = 2

display_items(current_page, items_per_page, all_items)

This function first figures out where to start and stop slicing the list of items based on the current page. Then, it collects the right items and prints them out for you. Adjust the current_page and items_per_page values to see how it works with different setups!

function displayItems(page) {
    const startIndex = (page - 1) * itemsPerPage;
    const endIndex = startIndex + itemsPerPage;
    const paginatedItems = items.slice(startIndex, endIndex);
    
    // Display the paginated items
    console.log(paginatedItems);
}

4. Function for navigating between pages:

With this feature, you can easily jump to the next or previous page. You can also throw in some checks to make sure you stay within the limits and don’t go overboard.

function changePage(page) {
    if (page < 1) page = 1;
    if (page > totalPages) page = totalPages;

    currentPage = page;
    displayItems(currentPage);
}

1. Usage example:

Alright, now it’s time to put those functions to work and see them in action!

displayItems(currentPage); // Display the first page

changePage(2); // Moves to page 2

Conclusion

And that’s a wrap! You've successfully created a straightforward pagination system using JavaScript. Nice job! Feel free to make it even more personal by adding features like next and previous buttons! You could also include an option to jump straight to a specific page if that’s what you’re looking for. Happy coding!.

async function* paginatedLogs(provider, baseFilter, from, to, step=5000) {
  for (let start = from; start <= to; start += step) {
    const end = Math.min(start + step - 1, to);
    const logs = await provider.send('eth_getLogs', [{
      ...baseFilter,
      fromBlock: '0x' + start.toString(16),
      toBlock:   '0x' + end.toString(16)
    }]);
    yield logs;
  }
}

3) Handle blob data

So, EIP-4844 is introducing this new opcode called BLOBHASH, and it's also kicking off a fresh blob fee market. Pretty cool stuff! So, the blob contents are tagged along as “sidecars” on the consensus layer, and after roughly 18 days, they’ll get pruned. If you’re looking to keep tabs on long-term analytics, you can easily archive your data using Blockscout (or Blobscout) or Blobscan. It's a straightforward way to make sure you have everything you need for the long haul! Hey, take a look at this: eips.ethereum.org.

---

Subgraphs: faster product KPIs without running ETL

Great news! The Graph Network has officially moved over to Arbitrum One! That means all the new subgraphs and rewards are now happening on Layer 2. Exciting times ahead! Teams can take advantage of 100,000 free queries each month! After that, it's only about $4 for every additional 100,000 queries. Pretty sweet deal, right? Make sure to use the Arbitrum gateway when you're setting things up for production. Trust me, it’s a solid choice! Take a look at this: The Graph. You'll find some really useful info there!

Example GraphQL (Sales by Week from a Marketplace Subgraph):

Check out this super useful GraphQL query that can help you grab sales data from a marketplace subgraph on a weekly basis.

{
  sales(first: 100, orderBy: timestamp, orderDirection: desc) {
    id
    amount
    timestamp
    product {
      id
      name
    }
  }
}

Breakdown of the Query

• Sales: This is our go-to source for data, and we're aiming to grab the first 100 records.
• orderBy: We're putting the records in order based on the timestamp, which means you'll see the latest sales pop up first.
• orderDirection: If you set this to desc, you're telling the system to show things in descending order, which means the newest stuff pops up first.

Fields Returned

• id: This is the special number that sets each sale apart from the others.
• amount: This tells you the total sales figures.
• timestamp: This shows when the sale happened, including the date and time.
• Product: This is a section where you’ll find all the details about the product that was sold.
• ID: This is the unique number that identifies the product.
• Name: This is what we call the product.

Don't hesitate to tweak the first parameter if you want to grab more or fewer records!

{
  sales(first: 1000, orderBy: timestamp, orderDirection: desc) {
    id
    buyer
    seller
    priceETH
    timestamp
  }
}

Operational Notes:

• Consider tossing a little GRT stake into your subgraph. It'll attract some indexers and really help speed up that annoying cold-start latency. If you want to learn more, just click here. It's got all the details you need!
• Think about using version schemas to adjust your KPIs as things change. This way, you won't have to worry about screwing up your dashboards!

---

Warehousing with Google BigQuery

Hey, have you looked into bigquery-public-data.crypto_ethereum yet? It’s got a bunch of cool datasets like blocks, transactions, logs, traces, token transfers, and even balances. Definitely worth checking out! It works through the Blockchain ETL pipeline, which makes it super handy for exploring historical trends and connecting with your off-chain CRM data. If you’re looking for more info, you can check it out right here: (cloud.google.com).

Practical queries you can run today

1) First-Touch vs. Repeat-Use by Contract (Daily)

When we chat about first-touch and repeat-use in the context of contracts, we're really getting into two key ways that people engage with services or products in their everyday lives. Here's a quick breakdown:.

• First-Touch: This is all about that first moment a user interacts with a contract. The first experience really matters--it’s all about how someone first discovers your service or product. It really shapes how future conversations will go.
• Repeat-Use: On the other hand, this looks at how frequently users return to use the same contract again. It keeps track of how engaged they are after that initial contact.

Getting a good grasp of the difference between these two can really help you fine-tune how you keep your users engaged and happy over time.

-- New vs returning addresses interacting with a contract
WITH tx AS (
  SELECT DATE(block_timestamp) d, from_address
  FROM `bigquery-public-data.crypto_ethereum.transactions`
  WHERE to_address = '0xYourAppContract'
),
first_seen AS (
  SELECT from_address, MIN(d) AS first_day
  FROM tx GROUP BY from_address
)
SELECT
  t.d,
  COUNTIF(t.d = f.first_day) AS new_users,
  COUNTIF(t.d > f.first_day) AS returning_users
FROM tx t
JOIN first_seen f USING(from_address)
GROUP BY t.d
ORDER BY t.d DESC;

2) ERC‑20 Holder Tiers for a Token (Whales, Mid, Retail)

When you're diving into ERC-20 tokens, it really helps to know about the different levels of holders out there. Let’s dive into the three main types, shall we? Here’s a quick overview for you!

🐋 Whales

Here are the major contenders in the field. Whales usually have a ton of tokens, and their buying or selling moves can really shake up the market. So, here's the scoop on them:

• Holding Size: Typically, it holds at least 1% or more of the entire token supply.
• Behavior: The way they move can really shake things up in the market, so watching them closely can be super important for your investment game plan.

⚖️ Mid-Tier Holders

Mid-tier holders are kind of like the everyday investors in the crypto world. They’ve got a solid stash of tokens, but they’re not quite in the big leagues like the whales. They strike a balance, holding enough to be meaningful but not at the crazy levels that some of the big players have. They tend to provide a steadier presence in the market.

• Holding Size: Typically, this can hold anywhere from 0. Just 1% of the total supply.
• Behavior: While they can definitely sway the market a bit, their influence typically isn't as intense as what you'd see with whales.

🛒 Retail Investors

Retail investors are basically regular people--those who are just getting their feet wet in the investing world or maybe don’t have a ton of money to throw around. They really help keep the market flowing and can help build a tight-knit community around a token.

• Holding Size: Usually, it holds under 0. Just 1% of the entire token supply.
• Behavior: When they all buy or sell together, it can really sway prices, especially for the smaller projects out there.

Getting a good grasp of these tiers will make it a lot easier for you to navigate the world of ERC-20 tokens. Trust me, it’ll definitely help!

-- Snapshot balances from token_transfers double-entry book
WITH debits AS (
  SELECT to_address AS holder, SAFE_CAST(value AS NUMERIC) AS amt
  FROM `bigquery-public-data.crypto_ethereum.token_transfers`
  WHERE token_address = '0xToken'
), credits AS (
  SELECT from_address AS holder, -SAFE_CAST(value AS NUMERIC) AS amt
  FROM `bigquery-public-data.crypto_ethereum.token_transfers`
  WHERE token_address = '0xToken'
),
balances AS (
  SELECT holder, SUM(amt) AS token_raw
  FROM (SELECT * FROM debits UNION ALL SELECT * FROM credits)
  GROUP BY holder
)
SELECT
  CASE
    WHEN token_raw >= 1e9 THEN 'whale'
    WHEN token_raw >= 1e7 THEN 'mid'
    ELSE 'retail'
  END AS tier,
  COUNT(*) holders,
  SUM(token_raw) total_raw
FROM balances
GROUP BY tier
ORDER BY total_raw DESC;

3) Cohorts by First Week and 8-Week Retention

In this part, we’re going to dive into how various groups are doing with keeping users around, both after their first week and after eight weeks. Let’s see what the numbers tell us! It's really about figuring out who’s in it for the long haul and who decides to bounce!

First Week Retention

The first week is super important for keeping people engaged. Let’s take a look at how our groups did:

Looks like Cohort C is really taking the lead here, while Cohort B definitely has some room for growth.

8-Week Retention

Alright, let’s take a look at how these groups are doing after eight weeks!

Cohort C is still doing great with retention, but it looks like Cohorts A and B are facing some challenges right now. This info really helps us understand how various strategies are playing out for each group.

Keeping an eye on these metrics really helps us spot trends and discover effective ways to keep our users engaged over time!

WITH actions AS (
  SELECT DATE_TRUNC(DATE(block_timestamp), WEEK(MONDAY)) AS week,
         from_address
  FROM `bigquery-public-data.crypto_ethereum.transactions`
  WHERE to_address = '0xYourAppContract'
), cohorts AS (
  SELECT from_address, MIN(week) AS cohort
  FROM actions GROUP BY from_address
), joined AS (
  SELECT a.week, c.cohort, COUNT(DISTINCT a.from_address) AS actives
  FROM actions a JOIN cohorts c USING(from_address)
  WHERE a.week BETWEEN c.cohort AND DATE_ADD(c.cohort, INTERVAL 8 WEEK)
  GROUP BY a.week, c.cohort
)
SELECT cohort, week, actives,
       DATE_DIFF(week, cohort, WEEK) AS wk_num
FROM joined
ORDER BY cohort DESC, week ASC;

Governance:

Make sure to utilize INFORMATION_SCHEMA along with partition filters to help keep your costs in check. It's a smart way to monitor what you're spending! Hey, just a quick reminder that you can score the first 1TB per month for free when using standard BigQuery on-demand pricing! Pretty sweet deal, right? If you want to learn more, take a peek here!

---

Dune for rapid analysis and embedding

If you're looking to get your data sorted out, Dune’s Spellbook (dbt) is the place to be. It's perfect for normalizing all that common data you deal with, like dex.trades, nft.sales, and token transfers. It’s the easiest way to create a dashboard that everyone can get on board with, all without having to stress about the infrastructure. Feel free to use it as a quick reference while you're setting up your own marts. It should come in handy! Take a look at it on GitHub! You might find it really interesting! The Dune API is pretty awesome! It allows you to run your saved queries and easily integrate the results right into your apps or internal sites. You know, like those quarterly KPI decks you put together. It really streamlines the process! For more info, check out the documentation. It's got everything you need to know!

Example Dune‑Style SQL

Let’s break down how you could set up your SQL, kind of like how Dune would do it. Here’s a cool way to think about it! Just keep in mind to adjust it so that it fits your own Dune setup!

WITH blockchain_data AS (
    SELECT 
        block_number,
        transaction_hash,
        timestamp,
        from_address,
        to_address,
        value
    FROM 
        transactions
    WHERE 
        block_number >= 10000000
)

SELECT 
    from_address,
    SUM(value) AS total_sent,
    COUNT(transaction_hash) AS transaction_count
FROM 
    blockchain_data
GROUP BY 
    from_address
ORDER BY 
    total_sent DESC
LIMIT 10;

Key Points to Consider:

Make sure to tweak the table names and fields so they line up with what's in your own Dune schema.

• This example pulls together transaction data to give us a good snapshot of the top senders, based on how much they've sent in total.
• Don’t forget to think about any specific filters you might need, depending on what your data needs are.

Go ahead and play around with it! Feel free to make any changes or try new things.

SELECT
  DATE_TRUNC(block_time, day) AS day,
  COUNT(DISTINCT trader) AS dau_traders,
  SUM(usd_amount) AS volume_usd
FROM dex.trades
WHERE blockchain = 'ethereum' AND project = 'uniswap_v3'
GROUP BY day
ORDER BY day DESC;

---

Analytics for account abstraction (ERC‑4337)

Why this is important: Smart accounts are really starting to take off in wallets and apps these days. It's becoming the standard, and you can see why! It's really crucial to keep an eye on your KPIs, especially when it comes to things like sponsored transactions, failed validations, paymaster usage, and conversion rates. These metrics give you a clear picture of how everything is performing!

• EntryPoint Versions: We're all about that v0 life right now! 6 (0x5FF1…) and v0. 7 (0x000…7032) - you'll discover a ton of support for both options! If you’re starting new deployments, go ahead and use v0.

7. Hey, just a quick heads up! Make sure your event decoders and parsers are all set and updated with the PackedUserOperation fields and the latest changes in v0. It’s important to stay on top of things! 7. Check it out here.

• Important Update: Don’t forget to watch out for the UserOperationEvent! It’s got all the good stuff: sender, userOpHash, paymaster, nonce, whether it was a success, the actual gas cost, and how much gas was actually used. This is your best bet for keeping tabs on gas sponsorship and ensuring that your user experience really nails it! If you're looking for more details, you can check it out right here.
• Bundler RPC (ERC‑7769): With this version, you can use eth_sendUserOperation and eth_estimateUserOperationGas. Pretty handy, right? Don’t forget to jot down any failures (like those AAxx ones) - they really help us figure out what’s going wrong in the funnel. Thanks for keeping an eye on that! If you want to explore more about this, feel free to check out the details here.

For instance, think about calculating the ROI for Paymaster. You'd use BigQuery to analyze the decoded logs you've gathered.

-- Assuming you ETL EntryPoint UserOperationEvent into bq.dataset.aa_events
SELECT
  DATE(block_time) AS day,
  paymaster,
  COUNTIF(success) AS sponsored_succ,
  SUM(actual_gas_cost)/1e18 AS total_eth_sponsored
FROM `your_project.bq.aa_events`
GROUP BY day, paymaster
ORDER BY day DESC, total_eth_sponsored DESC;

Hey, quick tip! If the thought of setting up your own AA ETL feels like a bit too much hassle, why not just whip up a dedicated subgraph for EntryPoint v0? It's a simple solution that can save you a ton of effort! You can easily tap into events using The Graph gateway on Arbitrum. Hey, if you want to dive into the details, just click here. You’ll find all the info you need!

---

L2s after blobs: what to track

• Cost and throughput: Ever since the Dencun update rolled out, Layer 2 (L2) fees have really dropped, and on top of that, usage has skyrocketed! Platforms like Base and Arbitrum have really taken off lately, with a noticeable surge in both transactions and users. Hey, let’s give some serious love to metrics like “L2-native DAUs,” “cross-L2 repeats,” and “unit economics per L2.” I really think we should start considering them as the gold standard when it comes to stats! (investopedia.com).
• A quick tech update for BI: Just a heads-up: Blob fees have their own base-fee curve. So, when you're comparing times with lots of calldata to those packed with blobs, don’t be surprised if you notice some differences in settlement costs. (eips.ethereum.org). So, it turns out that some rollups are starting to share their data on non-Ethereum data availability layers, such as EigenDA. Pretty interesting, right? Make sure to stay on top of your DA provider when you’re checking out costs and SLAs for data availability. Just a heads up--Celo made the jump to Ethereum L2 with EigenDA back in March 2025. So, it’s worth keeping an eye on those moves! (l2beat.com).

---

Enriching user insights beyond transfers

• MEV Telemetry: If you're interested, you can dive into Flashbots' MEV‑Share public data over at BigQuery. Just hop on over to eden-data-public.flashbots.mev_share to check it out! This gives you a clear picture of how much value users are getting back through private flows and backs, along with the number of swaps that are taking advantage of the Protect routes. If you want to get into the nitty-gritty, you can check out all the details here.
• Attestations (EAS): Think of on-chain attestations as a cool way to showcase traits while keeping things private. You can have labels like “KYCed,” “beta-tester,” or “power user” that reflect your status without giving away too much info. With this approach, you can break down data in your dashboards while keeping your focus on the insights, without having to stress about dealing with any personally identifiable information (PII). EAS is up and running on both the mainnet and L2, and guess what? There's an awesome SDK just waiting for you to dive in! Find out more here.

---

Put it on a dashboard (in hours, not weeks)

To link BigQuery with Metabase, you'll need to use the service account JSON file. Just grab that, and you'll be all set! You’ll find it super easy to work with your SQL models thanks to the handy point-and-click features. Plus, you can whip up some awesome embeddable dashboards! Take a look at this link: metabase.com. It's got some great info!

Hey, just a quick reminder--if you’re working on those product-facing widgets, make sure to take advantage of Dune’s API! It's a fantastic way to boost your charts on your marketing site or investor portal while your data warehouse is still getting set up. If you want to dive deeper into the details, check this out: docs.dune.com. It’s got everything you need!

---

Emerging best practices we recommend to clients

1. A longevity model for a blob world. Hey there! Just a quick reminder: when you're working with your fact tables, make sure to save those settlement metrics, like blob_gas_used and excess_blob_gas, whenever you can. And don't forget to archive those blob bodies using a provider like Blockscout Blobs or Blobscan. You never know when you might need to decode the payload down the line! Take a look at this: (blog.blockscout.com). You might find it interesting!
2. Choose the right indexer that suits your needs. Alright, here’s the deal: if you want to keep an eye on your product KPIs, definitely look into using Subgraphs. For those cross-chain joins and diving into historical data, BigQuery is your best bet. And if you're ever in a situation where you need custom traces or just a bit of breathing room with latency, Reth or Erigon are the way to go. (paradigm.xyz).
3. Engineer for Log Limits and Scale. Hey, just a quick reminder to make sure you break up those logs into pages and really dig into filtering those topics. It helps a ton! It’s really smart to cache those decoded ABIs and get those “hot” tables ready in advance, especially things like daily active addresses. Just a heads up, you really want to keep an eye on those provider caps. (alchemy.com).
4. Let’s work on elevating AA to a top-tier funnel!

• Don’t forget to watch out for wallets related to v0! 6 vs v0. Hey there! Just a quick heads-up: keep an eye out for those sponsored operations linked to paymasters. It’s also important to monitor for any sudden jumps in AAxx validation failures. And don’t forget to get comfy with the bundler error taxonomy, specifically ERC-7769. It’ll really help you out! (alchemy.com).

1. Let's get our metrics aligned across all the different L2s.

• Since the same address can show up on different EVM Layer 2s, it's smart to add the chain_id to each dimension key. This way, you can keep things organized and avoid any mix-ups! This approach helps us stay consistent and makes it easier to connect the dots when we’re assigning those multi-chain groups.

1. Privacy by Design

• Consider using attestations and opting for identity methods, like SIWE and EAS, instead of relying on Personally Identifiable Information (PII). This really helps simplify the whole process of following regulations, plus it can seriously speed up those security reviews. If you're curious to learn more, be sure to check out (attest.org). You won't want to miss it!

---

Example: a minimal end‑to‑end pipeline for a DeFi app

• Ingest When choosing a provider, go for one that gives you indexed logs. And don't forget to pull in the last two years of data! You can do this by using paginated eth_getLogs based on specific topics like Transfer and Swap. It'll help you get all the info you need! Feel free to take a look at it here.
• Index
• Go ahead and set up a subgraph for your app's contracts. Just stake a little bit of GRT to ensure your indexer stays online and accessible. Want to dive deeper? Check out this link for more info!
• Warehouse
• Go ahead and load those raw logs and token transfers into BigQuery. Alright, next up, let's create some dbt models that capture the same vibes as the Dune Spellbook. We’re looking to replicate those patterns for tracking trades and token balances. Let’s get to it! Get the code here.
• Enrich Let’s go ahead and combine the EAS attestations to identify those groups that are “verified” or “trusted.” Also, don’t forget to check out the MEV-Share tables. They’re super handy for figuring out how Protect is being used. If you're looking for more info, check out attest.org! You'll find all the details you need there.
• Visualize Hey there! So, I've been working on setting up a few Metabase dashboards to keep an eye on some key metrics. We’re looking at things like Daily Active Users (DAU), retention rates, swap conversion rates, sponsor rates (that's the % of AA ops), and, of course, the L2 mix. It’s gonna help us get a better grip on how everything's performing!

---

30/60/90 with 7Block Labs

• 30 Days: Let's get those RPC and indexers up and running! We'll deploy the subgraphs and ensure we've got the essential tables ready in BigQuery, like transactions, logs, and transfers. Alright, let's go ahead and launch those MVP dashboards so we can keep an eye on our daily active users, retention rates, and revenue.
• 60 Days: It's time to step up our analytics game with AA (EntryPoint v0). Alright, so here's the plan: we need to get those MEV/Protect joins integrated, make sure we’re keeping tabs on the blob cost metrics, and start our expansion into Layer 2, particularly with Base and Arbitrum. Let’s make it happen!
• First 90 Days: Let’s focus on boosting our identity and model security by incorporating EAS traits. We’ll also set up alerts to catch any dips in our key performance indicators (KPIs). Plus, it’d be great to integrate some Dune and Metabase charts for our executive reports to make the data pop! Also, let's set up some guidelines for managing costs in our data warehouse.

---

Key technical references

• EIP‑4844 Blobs: So, here's the scoop on type-3 transactions. These guys come with a blob fee market that lets us have up to 3 target blobs and a maximum of 6 blobs in each block. Plus, there’s this cool ~18-day retention period at the consensus layer, which is pretty neat! Check it out here.
• Dencun Deployment: If you want to know more about how the Dencun update affects Layer 2 fees, check it out here. It’s a great read!
• The Graph on Arbitrum One: Curious about pricing and gateways? You can find all the details you need by checking out this link. Happy exploring!
• BigQuery Public Ethereum Dataset: Check out the setup for the public Ethereum dataset on Google Cloud. It's pretty cool to see how everything's organized!
• Dune Spellbook: If you're into working with dbt models, you definitely want to check out the Dune Spellbook. It’s a great resource you won’t want to pass up!
• **Reth 1. 0 Production Readiness: Hey there! Just wondering about Reth 1.
  So, let's talk about how everything is going with production, especially when it comes to zero and how it measures up. Oh, and don't forget, we've also got Erigon 3 hardware profiles thrown into the conversation! Check it out here.
• Tips for Getting the Most Out of eth_getLogs: If you want to really fine-tune your logs, check out the best practices here. It’s got some great insights that can help you out!
• AA Analytics: If you want the inside scoop on EntryPoint v0, this is the place to check! If you’re looking for info on address events and bundler RPC (ERC‑7769), you’ll definitely want to check out this guide. It’s packed with helpful details!
• Blob Archiving: Dive into the world of Blob archiving with Blockscout Blobs and Blobscan. You can check it all out here. Trust me, it's worth a look!

---

If you’re aiming to turn your protocol’s raw chain data into sleek, polished business intelligence that’s ready for the boardroom in just 4 to 6 weeks, 7Block Labs is here to help! We've got you covered from A to Z! Whether it’s indexers, models, dashboards, or even those high-level executive narratives, we can take care of it all!