Querying core blockchain tables is good for understanding the chain as a whole, however, very often Web3 projects already have smart contracts deployed onchain, and are looking for data exclusive to their contracts.

To simplify this use-case, Dreamspace includes the Smart Contract Indexing (SCI) utility, which accepts a smart contract address, pulls the ABI to structure new tables that map to each event in that smart contract, builds those tables, and keeps them populated with new event data in near real-time.

Finding SCI Data

There are several places to find the SCI data, but the easiest way to browse is using the "Datasets" view. Let's look at the Chainlink SCI tables in Ethereum:

Click on the top tab "Datasets"
Click on Ethereum
On the right, you'll see a checkbox where you can view/hide schemas - Core will be the only one enabled by default
Open up "Popular Protocol Contracts" and look for Chainlink (alphabetically)
This is a short-list of the most common contracts, maintained by MakeInfinite labs directly Click on the checkbox to display the event tables alongside Core tables
If you didn't see it there, check in "Community Requested Contracts"

In this case, we can see Chainlink in the "Popular Protocol Contracts" list. From here you can view the table names, column structures, and data size. To query, jump over to the "Queries" tab.

Requesting a SCI Table

This almost couldn't be more easy! You only need two pieces of information:

Smart Contract address
The chain where the Smart Contract resides
With that information, click on "Smart Contracts" in the top level tab, and select "Get data from chain":

Across the bottom you'll see a visual workflow, which explains the process fairly well:

"Select Chain" from the dropdown and paste in your "Contract Address" and hit "Submit"
The engine will retrieve the ABI (metadata for the smart contract) and build a table for each event it finds, providing a preview for you to look at (including a bit of sample data):

If the contract has already been indexed, you'll see a note in the upper right:
"Full Event History Indexing: Completed Successfully" Also, the Schema is filled in and not editable - for example above, SUSHISWAPV2_ETHEREUM If this is the case - nothing left to do! You should be able to query the tables shown immediately!
If the contract has NOT been indexed, you'll still see the event table preview and sample data, however the schema / "project name" will be blank:

"Type in project name for this smart contract" and enter the name of the project! For example, in the above picture, a good project name would be either BAYC or BORED_APE_YACHT_CLUB.

Whatever you select will be the database schema for these new tables , with the name of the chain appended to the end. Again for example, if we named the above BAYC, the final database schema name would be BAYC_ETHEREUM (since many contracts exist on many chains).

Click button "Send Request for Indexing" in the upper-right, and you're done!

The SCI engine will perform several more steps in parallel:

Create the schema per above, and all tables it previewed
Begin back-populating the tables with historic event data from the LOGS table
Set up the real-time indexing process to keep the tables up-to-date going forward

For small contracts, these steps can take a few minutes, where larger contracts can take a few hours. There will be a status provided in the upper-right corner, letting you know when it's complete.

🚧
Trial users cannot submit SCI requests, since it becomes an ongoing part of the network.

📘
Not all chains have been added to the SCI program yet, but stay tuned! We are updating frequently!

Why Not Use The Core.LOGS Table?

This is entirely possible to do using the LOGS table, which holds EVERY smart contract event for ALL smart contract executions, throughout the history of the chain. For example, the query below shows matching results when querying the "WITHDRAW" event from Sushiswap V2 contract on Ethereum - the top querying from the SCI table, the second when querying from the ETHEREUM.LOGS table directly:

One difference is structure: the SCI table contains smart contract event data that is decoded, with all data split into columns for easy querying. The LOGS table by contrast is structured more like the original blockchain source, where contract data is either part of the Topic_0 thru Topic_3 fields, or stored in JSON in the generic column data_ (or raw_data if you want binary).

Another difference is size: the Ethereum.LOGS core table is around 750GB in size, whereas the targeted SCI table is only around 140MB - that's 5000 times smaller! Obviously this smaller and better structured table will have much faster response time!

Querying SCI data

Once indexed, querying the data is as easy as querying any other table! Open up the "Query Editor" and try this sample query, which compares the Flashloan value of wETH and wstETH on Ethereum:

SELECT cast(time\_stamp as date) as Loan\_Date\
, case when substr(Asset,1,6)='0xc02a' then 'wETH' else 'wstETH' end as Asset\_Name
, sum(amount)/1e18 as Amt\_Total
from AAVE\_V3\_ETHEREUM.POOL\_EVT\_FLASHLOAN
where time\_stamp between current\_date-30 and current\_date
and asset in( lower('0x7f39c581f595b53c5cb19bd0b3f8da6c935e2ca0')  /\* wstETH */
,lower('0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2')) /* wETH \*/
group by cast(time\_stamp as date), asset
order by 1

Because the SCI structures the data, the logic is built on business ideas like "Asset" and "Amount" rather than "topic_3" and parsing semi-structured data for amounts.