Unlock the full potential of blockchain analytics with Dune’s Datashare on Snowflake. Gain access to Dune’s full data catalog with over 1.5 million tables, featuring raw blockchain data, human-readable smart contracts, detailed insights into protocols, dex/nft trades, and comprehensive cross-chain data. All are directly available on the Snowflake Marketplace, making it the most extensive and rich resource for blockchain data in the crypto universe.

Key Features

  • Extensive Data Catalog: The largest assembly of blockchain data in the crypto space, at your fingertips.
  • Cross-Chain Insights: Abstracted and harmonized data from more than 15 blockchains, providing a panoramic view of the blockchain ecosystem.
  • Human-Readable Smart Contracts: Simplifying the complexity of smart contracts, making them accessible and understandable.
  • Direct Access via Snowflake Marketplace: Seamless integration and access through the Snowflake data marketplace, ensuring optimal performance and reduced query costs.
  • Cross Region Replication: Data is available in multiple regions to ensure data proximity and help keep your query costs low.
  • Precision and Accuracy: Data is meticulously curated and maintained, ensuring the highest quality and reliability.

Datashare 101’s

To start leveraging Dune’s Datashare on Snowflake for your blockchain analytics needs, visit the Dune profile on the Snowflake Marketplace. There are trial tables available. If interested in participating in the trial please refer to our trial guide under getting started.

Dune vs. Datashare

The data we provide on the Snowflake Marketplace is the same data that powers our analytics platform. However, since the data is in a different environment, there are slight differences in the way we need to store the data.

Datatypes

On Snowflake, the way we store data is different, since there is no native support for common blockchain data types in Snowflake. This affects the way we store addresses, hashes, call data and other varbinary data. Furthermore, high-precisions integers like uint256 and int256 are also affected.

Varbinary Data

For columns that have the datatype varbinary in Dune, there are two columns in Snowflake named “column_name” and “column_name_hex” (e.g., hash and hash_hex). “Column_name” is of type varbinary, “column_name_hex” is of type string and contains the 0x-prefixed lowercase hex representation of the binary data for convenience. For complex queries, it is recommended to use the “column_name” column, as it is more efficient. Snowflake does not support storing varbinary data with a 0x prefix, so we store the data as varbinary and provide a string column with the hex representation for convenience. Queries using “hash_hex” will be much slower than queries using “hash” due to the data type.

DatabaseColumn NameData TypeData Display Sample
Dunehashvarbinary0xefb2e2c26974f72d9f3f04c693db73ecc679dd60
SnowflakehashvarbinaryEFB2E2C26974F72D9F3F04C693DB73ECC679DD60
Snowflakehash_hexstring’0xEfB2E2c26974F72D9f3f04C693DB73eCc679dd60’
--Using hash:
select * from ethereum.transactions where hash = X'efb2e2c26974f72d9f3f04c693db73ecc679dd60'
--Using hash_hex:
select * from ethereum.transactions where hash_hex = LOWER('0xEfB2E2c26974F72D9f3f04C693DB73eCc679dd60') -- Not recommended
Varbinary data in Snowflake is displayed as ABCDEF but needs to be queried via X'abcdef'. There is a difference between the representation and the actual data.

High Precision Integers

For most columns with type INT256 or UINT256 in Dune, there are two columns in Snowflake, one of type DOUBLE, and one of type VARBINARY. The VARBINARY column contains the 32-byte, big-endian, 2s complement representation of the INT256 or UINT256 number. The DOUBLE column is named “column_name” while the VARBINARY column is usually named “column_name_binary” or “column_name_raw”. For most use cases, the DOUBLE column is sufficient, but for queries that require exact precision, it is recommended to use the Dune query engine, as it has native support for these data types.

The VARBINARY datatype columns are useful when exact precision is needed, but calculations are not required. For example, if you want to join on token_id for erc1155 transfers, you can use the VARBINARY column token_id_binary. Using double for this would not work, as the precision is not sufficient.

DatabaseColumn NameData TypeData Display Sample
Dunecolumn_nameINT256123456789012345678901234567890123456789
Snowflakecolumn_nameDOUBLE3.4567890123456788e+16
Snowflakecolumn_name_binaryVARBINARYX’5ce0e9a56015fec5aadfa328ae398115’
Snowflakecolumn_name_rawVARBINARYX’5ce0e9a56015fec5aadfa328ae398115’
Varbinary data in Snowflake is displayed as ABCDEF but needs to be queried via X'abcdef'. There is a difference between the representation and the actual data.