In this document, a section of the database utilized by the Routescan team is presented. This initiative aims to foster collaboration among industry stakeholders, promoting the exchange of ideas and the sharing of best practices to accelerate innovation and growth in the DeFi sector.

The primary purpose of an EVM-compatible block explorer is to display the history and relationships involving a specific address. This information can be sourced both on-chain, such as interactions with other addresses or contracts, and off-chain, like the identity of the address owner or the deployer of a particular contract. While on-chain data is readily accessible by querying the blockchain node, off-chain data needs to be stored in a database since it isn't available from a single source.

Although block explorers typically focus on individual addresses, Routescan takes a broader approach by tracking entities instead. As a multichain, EVM-compatible explorer, Routescan addresses the need for flexibility in identifying objects within a blockchain. For example, on the Avalanche blockchain platform, an entity might have an EVM address, as well as AVM and PVM addresses.

To achieve this, Routescan's database is structured around three core tables:

1. Entities

2. Blockchains

3. Dapps

Entities represent the primary objects of analysis. Each entity is related to a blockchain and might also be associated with a dapp. This relationship is established through ownership: if an entity is owned by a group or team, it is linked to a dapp. However, if the owner is an individual, no dapp association is made.

Additionally, three more tables are necessary:

• SocialProfiles: This table aggregates the social profiles associated with both entities and dapps.

• Alerts: It stores any notes to be displayed for both entities and dapps.

• Uploads: Used to track the icons that characterize entities, blockchains, and dapps.

These tables relate to both entities and dapps. They store social profiles (e.g., Twitter, Telegram), images (in the Uploads table), and alerts (to display warnings in the block explorer, such as in cases of contract exploits).

For more detailed information, you can access the database structure in the form of a DBML script at the following link.

In the following section, we delve into a detailed analysis of the "entities" table. As mentioned previously, this table aims to track all potential entities existing within EVM-compatible blockchains.

The fields comprising the table are as follows:

• Address: Represents the unique address of the entity.

• Type: Indicates the type of entity, such as EVM address, AVM address, PVM address, or AVM asset.

• Alias: Provides an alias or alternate name for the entity.

• Tags: Presents a list of tags that identify the entity, such as ERC20, bridge, honeypot, etc.

• Verified: Specifies whether the origin of the entity has been verified.

• Reputation: Defines the reputation level of the entity, categorized as high, medium, low, unknown, scam, or probable scam.

• Description: Offers a description of the entity.

• URL: Contains the associated link or URL of the entity.

• onChainSimilarEntities_id: Identifies the relationship with other addresses that have similar naming or conceptual value, linking other objects in the ‘entities’ table..

• Owner: Establishes the relationship with the "Dapps" table.

• socialProfile: Indicates the relationship with the "socialProfiles" table.

• Alert: Identifies the relationship with the "alerts" table.

• Icon: Establishes the relationship with the "uploads" table.

Considering the address 0xB31f66AA3C1e785363F0875A1B74E27b85FD66c7, which represents the WAVAX entity on the C-chain, the following data would be applicable:

{
 "address": "0xB31f66AA3C1e785363F0875A1B74E27b85FD66c7",
 "type": "evmAddress",
 "alias": "Wrapped Avax",
 "blockchain": "Avalanche c-chain",
 "description": "Avalanche is the fastest smart contracts platform in the blockchain industry, as measured by time-to-finality, and has the most validators securing its activity of any proof-of-stake protocol.",
 "icon": "wavax.png",
 "owner": "Ava Labs Dapp",
 "socialProfile": "wavax socialProfile",
 "tags": [
   "erc20",
 ],
 "url": "https://www.avax.network/",
 "onChainSimilarEntities": [
   "aAvaWAVAX",
   "avWAVAX",
   "..."
 ],
 "reputation": "high",
 "alert": ""
}

A prospective enhancement that will be considered for the future involves the utilization of a supporting table for tags instead of relying on enums. This adjustment is proposed due to the potential benefits of including additional information for each tag, such as descriptive details.

In the following section, a detailed analysis of the "blockchains" table is presented. This table aims to record information regarding the various blockchains utilized within the project's scope. The fields comprising the table are as follows:

• name: Name of the blockchain.

• vm: (EVM, AVM, PVM)

• alias: Alias or nickname of the blockchain.

• url: URL associated with the blockchain.

• description: Description of the blockchain.

• evmChainId: Identifier of the EVM (Ethereum Virtual Machine) chain associated.

• alert: Identifies the relationship with the "alert" table.

• icon: Identifies the relationship with the "uploads" table.

Considering the example of the WAVAX entity, the corresponding data will be as follows:

{
 "_id": "625a14bda3bd1849c9a669c0",
 "alias": "C",
 "environment": "mainnet",
 "evmChainId": "43114",
 "gasToken": "avax",
 "icon": "c.png",
 "name": "Avalanche C-Chain",
 "url": "https://support.avax.network/en/articles/4058262-what-is-the-contract-chain-c-chain",
 "vm": "evm",
 "alert": "",
 "description": "Build anything you want, any way you want on the lightning fast, scalable blockchain that won’t let you down. Choosing the wrong blockchain can kill your dApp before it ever has a chance to succeed, but it doesn’t have to be this way. Launch with confidence on Avalanche."
}

In this chapter, the "Dapps" table is examined in detail, aiming to track the various Dapps present across blockchains. This table is designed to include the following information:

• alias: The alias that identifies the Dapp.

• url: The URL associated with the Dapp.

• description: Description of the Dapp.

• socialProfile: Identifier of the relationship with the "socialProfiles" table, which contains the social profiles associated with the Dapp.

• alert: Identifier of the relationship with the "alerts" table, which contains alerts related to the Dapp.

• icon: Identifies the relationship with the "uploads" table.

Considering the WAVAX entity, it will have a relationship with the Dapp "Ava Labs," defined by the following data:

{
"alias": "Ava Labs",
"url": "https://www.avalabs.org/",
"description": "Avalanche is the fastest smart contracts platform in the blockchain industry, as measured by time-to-finality, and has the most validators securing its activity of any proof-of-stake protocol.",
"icon": "ava labs.png",
"owner": "Ava Labs Dapp",
"socialProfile": "ava Labs socialProfile",
"alert": ""
 "blockchain": ["Avalanche c-chain", "Avalanche x-chain", "Avalanche p-chain"],
 "tags": ["Foundation"]
}

Furthermore, regarding the "dapps" table, tags have also been utilized as Enums. However, in the future, there will be a reassessment of the possibility of using an additional table to enhance the data quality associated with the tags.

It is also noted that the tags related to "entities" and the tags related to "dapps" may diverge, as in the following case: the WAVAX token is identified by an "ERC20" tag, while the associated Dapp presents the "foundation" tag.

Another point to consider is that a Dapp has a multiple relationship with the "blockchains" table, unlike "entities" which possess a single relationship. This is because an entity is a unique object for each blockchain, whereas a Dapp can exist across multiple chains, as in the case of "Ava Labs," which is associated with both C, X, and P chains.

In the following chapter, the "socialProfiles" table is comprehensively examined. This table is dedicated to the recording and management of the social profiles associated with the entities and Dapps present in the system. The fields comprising the table are as follows:

• name: Name of the social profile.

• email: Email address associated with the profile.

• whitepaperUrl: URL of the associated whitepaper, if available.

• coingecko: Profile name on CoinGecko.

• coinmarketcap: Profile name on CoinMarketCap.

• geckoterminal: Profile name on GeckoTerminal.

• facebook: Profile name on Facebook.

• reddit: Profile name on Reddit.

• telegram: Profile name on Telegram.

• twitter: Profile name on Twitter.

• discord: Profile name on Discord.

• medium: Profile name on Medium.

• slack: Profile name on Slack.

• linkedin: Profile name on LinkedIn.

• bitcoinTalk: Profile name on BitcoinTalk.

• ticketSupporterUrl: Support ticket URL.

• weChat: Profile name on WeChat.

Taking into account the WAVAX entity, it will have a relationship with the socialProfiles table, defined by the following data:

{
 "avalancheSupport": null,
 "coingecko": "https://www.coingecko.com/en/coins/avalanche-2/",
 "coinmarketcap": "https://coinmarketcap.com/currencies/avalanche/",
 "discord": "https://chat.avax.network/",
 "email": null,
 "facebook": "https://www.facebook.com/avalabsofficial/",
 "geckoterminal": "https://www.geckoterminal.com/avax/pools/0xd446eb1660f766d533beceef890df7a69d26f7d1",
 "medium": null,
 "name": "Wrapped AVAX",
 "reddit": "https://www.reddit.com/r/avax",
 "telegram": "https://t.me/avalancheavax",
 "twitter": "https://twitter.com/avalancheavax",
 "whitepaperUrl": "https://www.avalabs.org/whitepapers",
 "blog": "https://medium.com/avalancheavax",
 "github": "https://github.com/ava-labs",
 "linkedin": "https://www.linkedin.com/company/avalabsofficial/",
 "ticketSupporterUrl": "https://support.avax.network/",
}

It is noteworthy that Dapps and entities are associated with two different social profiles. For example, the "WAVAX" token will have a social profile that differs from that of its Dapp, namely "Ava Labs".

In the following chapter, we delve into the detailed analysis of the "alerts" table. This table is dedicated to recording and managing alerts within the system, which can be used to monitor specific events or conditions related to entities or Dapps for a defined period.

The fields comprising the table are as follows:

• activeFrom: The date and time when the alert is activated.

• activeUntil: The date and time when the alert is deactivated.

• description: Description of the alert, providing detailed information about the monitored event or condition.

As an example, we present the alert associated with the aforementioned Dapp "Ava Labs", where the company's legal notes are reported for an infinite duration.

{
 "description": "Unless specified otherwise, Ava Labs makes no representation, warranty, guarantee, or undertaking in respect of the Avalanche public blockchain ...",
 "activeFrom": null,
 "activeUntil": null
}

It is worth noting that in the following scenario, alerts associated with "Dapps" and alerts associated with "entities" may diverge.

Routescan's database structure is a powerful tool for managing off-chain data and enhancing the transparency of blockchain interactions. By effectively integrating on-chain and off-chain data, Routescan provides a robust framework for labeling and tracking blockchain activities. This comprehensive approach not only simplifies the complexities of blockchain networks but also promotes innovation and collaboration within the DeFi sector. As Routescan continues to refine and expand its capabilities, we are committed to supporting developers, investors, and blockchain enthusiasts in achieving their goals.

Follow us on X:

https://x.com/routescan_io