🪐
Evmos
dataset: numia-data.evmos
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.
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.
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.
There are the following tables:
Like all other chains, Evmos follows the same data schema for the transactional data we index.
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.
- 1.
blocks
event_attributes
message_event_attributes
transactions
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.Field | Type |
|---|---|
block_height | INTEGER |
block_timestamp | TIMESTAMP |
chain_id | STRING |
proposer_address | STRING |
validators_hash | STRING |
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.Field | Type |
|---|---|
block_height | INTEGER |
chain_id | STRING |
tx_id | STRING |
event_index | INTEGER |
event_type | STRING |
attribute_key | STRING |
attribute_value | STRING |
attribute_index | INTEGER |
ingestion_timestamp | TIMESTAMP |
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.Field | Type |
|---|---|
block_height | STRING |
chain_id | STRING |
tx_id | STRING |
message_index | INTEGER |
event_index | INTEGER |
event_type | STRING |
attribute_key | STRING |
attribute_value | STRING |
attribute_index | INTEGER |
ingestion_timestamp | TIMESTAMP |
Contains relevant data associated with a transaction.
Field | Type |
|---|---|
block_height | STRING |
chain_id | STRING |
tx_id | STRING |
tx_status | STRING |
fee | STRING |
tx_code | INTEGER |
tx_index | INTEGER |
gas_used | INTEGER |
gas_wanted | INTEGER |
ingestion_timestamp | TIMESTAMP |
validators
message_types_transactions
Purpose: This table maps validator addresses to moniker & other metadata.
Field | Type |
|---|---|
account_address | STRING |
operator_address | STRING |
consensus_pubkey | STRING |
status | FLOAT |
moniker | STRING |
identity | STRING |
rate | STRING |
max_rate | FLOAT |
min_self_delegation | FLOAT |
Network | STRING |
Snapshot_date | TIMESTAMP |
Each record is a single message triggered within the chain. We include it's type, sender and the corresponding
tx_id.
ibc_transfer_inbound
ibc_transfer_outbound
Each record records an incoming ibc_transfer.
Each record records an outgoing ibc_transfer
delegate
redelegate
Each record is a delegation from a unique address.
Each record is a redelagation from a unique address from one validator to another.
Voting
Each record represents a governance vote and the corresponding outcome.
evm_blocks
evm_transactions
evm_logs
Evm Blocks
Field | Description |
|---|---|
height | block height (Integer) |
timestamp | block timestamp (timestamp) |
hash | block hash (string) |
ingestion_timestamp | time record was ingested (timestamp) |
A table containing high-level data about the evm transactions.
Field | Description |
|---|---|
block_height | block of the txn |
hash_evm | hash of the evm txn |
evm_index | index of txn within evm block |
gas_used | amount of gas used in aevmos |
amount | amount of evmos value in txn |
sender | bech32 address of the sender |
evm_sender | HEX address of the sender |
recipient | HEX address of recipient |
code | txn status code, 0 = success. |
data | data of the txn is nullified and put into evm_logs |
index | index of the txn in Cosmso block |
gas_limit | gas limit |
tx_json | json of the txn - nullified and put in evm_logs |
ingestion_timestamp | ingestion timestamp in Numia |
MsgEthereumTx | Txn data if txn of type MsgEthereumTx |
LegacyTx | Txn data if txn of type LegacyTx |
AccessListTx | Txn data if txn of type AccessListTx |
DynamicFeeTx | Txn data if txn of type DynamicFeeTx |
raw_data | encoded raw logs |
TxRaw | encoded raw bytes |
gas_price | gas price at time of txn |
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.
Field | Description |
|---|---|
address | smart contract that emitted events |
topics | The first part of a log record consists of an array of topics. These topics are used to describe the event. |
data | The second part of a log record consists of additional data. |
block_hash | hash of the block of the txn |
log_index | index of the log within txn |
tranasction_hash_evm | hash of the evm txn |
ingestion_timestamp | time ingested into Numia |
Additional tables have data that is not event-based but relevant when working with event-based data.
token_sales
transfer_event
uniswap_v2_dex_swaps
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.
Last modified 24d ago