Evmos is the team behind the leading EVM Module Ethermint, and they were the first EVM-based chain in Cosmos. Because of its nature, Evmos consists of two layers when it comes to consensus and transactions, 1) the EVM layer runs the Ethereum virtual machine, and 2) the Cosmos layer which runs on the Cosmos-SDK and Tendermint. They both have different data models and it's important that you understand both data models so that you know what data to query to extract the data you need.
Cosmos Data Model
The Cosmos layer tracks every single transaction of the chain, including all Cosmos-SDK modules like DElegations, Governance, Banks,s and others. It also contains the wrapped EVM transactions, but these need to be decoded in order for them to be consumable.
Evmos EVM Data Model
In essence, EVM transactions take place and then get wrapped and passed to the Cosmos layer so these get validated there too. However not all EVM data is passed or if it is, it's still encoded.
Numia is the only indexer that provides indexing solutions for both layers at the time. You will be able to run queries to not only understand what's happening at the Cosmos layer but also at the EVM layer. Keep in mind we are gradually expanding to more and more tables in the coming weeks.
Evmos Message Types
Before you start querying the data you need to know what data you want to extract. Remember the whole data schema for Cosmos is based on different message types. We have created this extensive overview for all evmos message types that will allow you to know what events and what attributes correspond to different messages. Click here to access the document.
Raw Tables (Cosmos)
Contains each validated block in the Cosmos Layer of Evmos. block_timestamp. is only available in this table, so you need to do an inner join on block_height to get block_timestamp to the other tables.
Contains all events and their corresponding attributes partitioned by tx_id. Events and their corresponding event_index are relative to the parent transaction , not the message. Events are identified by the event_type column and attributes by the attribute_key. Events are linked to transactions via column tx_id.
Contains all events and their corresponding attributes partitioned by message_index. Events and their corresponding event_index are relative to the parent message_index which is relative to the tx_id. Events are identified by the event_type column and attributes by the attribute_key. Events are linked to transactions via column tx_id.
Contains relevant data associated with a transaction.
Filtered Event-Based Tables (Cosmos)
Beyond the raw tables, we have sub-tables for different relevant types of events, such as delegations, redelegations, swaps & voting. You can find them in their respective area (delegations in staking, swaps in liquidity pools, etc.)
Staking Tables
IBC Tables
Liquidity Pools Tables
Governance Tables
Distribution Tables
Additional Data Tables (Cosmos)
Additional tables have data that is not event based but relevant when working with event based data.
Purpose: This table maps validator addresses to moniker & other metadata.
Each record is a single message triggered within the chain. We include it's type, sender and the corresponding tx_id.
Raw Tables (EVM)
Evm Blocks
A table containing high-level data about the evm transactions.
This table contains the raw event logs that we encode to build most of the aggregated tables for the EVM. Each log record consists of both topics and data. Topics are 32-byte (256 bit) “words” that are used to describe what’s going on in an event.
Additional tables have data that is not event-based but relevant when working with event-based data.
Aggregated Tables (EVM)
Records erc1155 or erc720 token sales from specific contracts (marketplaces).
Records individual token transfers that happen every time an ERC20 or ERC721 token standard smart contract registers one of these transfers. Multiple transfers can happen on the same txn.
Records individual trades of the swapExactTokensForTokens method of all Uniswap V2 forks. Each record corresponds to a swap of each individual pair that was hopped during the trade. If the swapExactTokensForTokensac generated a multi-hop trade, then you will see multiple records for the same tx_hash.
