# Introduction Blocktorch is an end-to-end observability platform designed specifically for web3 services and products. We aim at taking away the complexity of web3 data and enabling you to take action. Blocktorch offers a comprehensive solution for developing, monitoring, troubleshooting, and optimizing decentralized services and applications end-2-end, making it easier for engineering teams to ship and maintain high-quality dApps. Key features of Blocktorch include: * **Real-time monitoring** of smart contract events, state variables and transaction data * **Alerting and notification** systems for proactive issue detection * **Log analysis and search functionality** for efficient troubleshooting * **Customizable dashboards** and visualizations for data-driven decision-making * **Collaboration** on Smart Contract development and dApp monitoring

Blocktorch's architecture with supported sources and functionalities

> #### *"Blocktorch is the best in class observability platform in web3. The hollistic approach to the platform makes it a single source of truth for the engineering team"* *** ### Introducing observability best practices has multiple advantages * **Boosting engineering productivity with observability** Blocktorch's end-to-end observability platform enables you and your engineering team to be more productive by streamlining the monitoring and management of dApps. With Blocktorch, you can: 1. Quickly identify and resolve issues, minimizing downtime and ensuring a consistent user experience 2. Focus on core development tasks, rather than spending time on custom monitoring and troubleshooting solutions 3. Collaborate more effectively, using data-driven insights to drive decision-making and prioritize improvements * **Taking data-driven product & engineering decisions** Blocktorch helps you and your engineering team to make data-driven decisions by providing a comprehensive view of your dApp's performance and health. You can leverage Blocktorch's insights to: 1. Optimize application and smart contract performance and resource usage 2. Identify and address performance bottlenecks 3. Allocate resources more effectively, based on real-time data and trends * **Scaling dApps and ensuring great user experience** As dApps scale and attract more users, maintaining a high level of performance and user experience becomes increasingly important. Blocktorch enables you to: 1. Monitor and maintain performance standards, even as user load increases 2. Proactively detect and resolve issues before they impact users 3. Ensure consistent user experience across different platforms and devices By offering a comprehensive observability solution tailored to the unique challenges of web3, Blocktorch empowers you and your engineering team to build and maintain high-quality decentralized applications that delight users and stand the test of time. {% hint style="info" %} **The challenge of observability in Web3**\ Decentralized applications (dApps) operate on distributed networks, relying on smart contracts and blockchain technology, with no single entity in control. These unique features present new challenges when it comes to observability:
* **Data Fragmentation**: Data generated by dApps is often dispersed across multiple nodes and platforms, making it difficult to collect, analyze, and understand the overall system state. * **Error Handling**: Identifying and diagnosing errors in smart contracts can be time-consuming, as the immutability of blockchain technology prevents traditional debugging techniques. * **Performance Monitoring**: Ensuring optimal performance and user experience in dApps is crucial, but the decentralized nature of these systems complicates the process of monitoring and optimizing them. ```markup "A truly decentralized system is one where no single entity has control." Vitalik BUterin ``` {% endhint %} # Install/Setup ### Sign-up to blocktorch {% embed url="" %} {% endembed %} We support sign-up via eMail, SSO through Google & GitHub and sign-up through your Web3 Wallet
### Creating your first project When you initially [sign-up](https://beta.blocktorch.xyz/register) to Blocktorch a default project is automatically created for you. The project is filled with demo data from Uniswap V3 for the time until you add your first data source. 1. Log in to your Blocktorch account 2. Walk through the onboarding guide 3. Navigate to the "Settings" page. 4. See & change your project's details and invite team members

blocktorch settings page

{% hint style="success" %} That's it 👏 you are ready for making observability a standard practice in your organization {% endhint %} {% hint style="info" %} You need more than one project? [Please contact us](mailto:contact@blocktorch.xyz) {% endhint %} # Quickstart The fastet way to start observing your dApp and gain valuable insights. No credit card required.No code required. **1. Log in to blocktorch** [**here**](https://beta.blocktorch.xyz) **(no credit card required)** * Sign in via eMail, SSO through Google & GitHub or your Web3 Wallet * If you sign in by email you will receive a Magic Link in your inbox
Sign-in screen for Blocktorch, supporting sign-in through email and wallet

Blocktorch sign in screen

* At your first log we are asking you about some info about you to get to know each other better

Blocktorch wants to get to know you

#### Your project will be set up with a demo of Uniswap V3 and you can start exploring the data

Blocktorch home with Uniswap V3 data as demo

#### 3. Add your first smart contract, the demo data will automatically be replaced * Search for the smart contract of your choice in "Contracts" >> "Add Contract"

Blocktorch contract overview

* We will detect which chain the contract address is deployed on, choose the one you want to start gaining insights from by clicking on the name with the chain logo next to it

Blocktorch adding a contract

* We automatically fetch the ABI if the contract is verified and published on a block explorer. In case the contract is not published and verified please provide the contract ABI by uploading the json, which will stay private * Feel free to rename the contract * Click "Save" on the top right Start exporing the data and gain inisights by clicking to Blocktorch logo to go back to the home screen. Dive into global KPIs about performance, efficiency and health.

Blocktorch home

4. **Build your first custom monitor** * To build your own custom monitors or investigate the data navigate to "explore"

Explore building monitors in Blocktorch

* Build a query of your choice you want to set the monitor on. For example monitor the gas used by transactions that have not succeeded, thus "wasted gas" by users * Build your query. * *Example:* * *Smart contract: Universal Router Uniswap V3 on ethereum* * *Metric: Transaction Gas Used* * *Filter: where Transaction Status != SUCCEEDED* * *Operator: SUM* * Choose a time window for monitoring this query on a rolling basis. * *Example: 1 hour. This means the monitor sums up the amount of gas used by failed and revereted transactions each hour* * Choose a target you want to achieve. If the target is breached the monitor will trigger an alert. * *Example: 1200000000* * Give the monitor a descriptive title as well as some more description. * Save your monitor on the top right of your window.

Creating the first monitor

5. **Dive into the logs to find all details about single transactions** * Navigate to "search" * Build a query you want to search specific logs from. * For example to investigate why transactions from our monitor above surpassed our target treshold look for failed transactions in the Uniswap Universal Router V3 contract on ethereum in the time window of the breach.

Searching for transaction logs in blocktorch

* Click on any transaction to open full details about the transaction including stack traces and analytics about the method
* Bonus: feel free to share your exact query and results with others by sharing the URL ℹ️ sharing search results with others will invite them to your project

Share your blocktorch search result by sharing the URL

{% hint style="success" %} Congrats you have successfully explored blocktorch to gain the fastest insights into web3 you can get 🥳 Now have fun digging deep to explore the full power of the platform! {% endhint %} {% hint style="info" %} [Here are videos](/ressources/demo-videos) showcases all of the features of the blocktorch platform {% endhint %} # Data Sources At Blocktorch we believe a hollistic approach to DevOps in web3 is necessary, so instead of pure smart contract observability we are integrating with multiple layers of the architecture of web3
### Backend Infrastructure aka Nodes {% content-ref url="/pages/OhqF5pvsFvor3fqpabun" %} [EVM Chains](/concepts/data-sources/evm-chains) {% endcontent-ref %} {% content-ref url="/pages/37eWvCCvknEkIhxP3bpT" %} [Roll-ups](/concepts/data-sources/roll-ups) {% endcontent-ref %} {% content-ref url="/pages/2dZHwzvwPNczH9cV81QO" %} [Local forks](/concepts/data-sources/local-forks) {% endcontent-ref %} {% content-ref url="/pages/fw0AZZu3P3bgZ7ZaiZg8" %} [Custom Event Data](/concepts/data-sources/custom-event-data) {% endcontent-ref %} ### Functions & Logic {% content-ref url="/pages/g0KJGfUIdRqgqjbmJSLO" %} [Smart Contracts](/concepts/data-sources/smart-contracts) {% endcontent-ref %} ### Datafeeds {% content-ref url="/pages/gzX3mzhfANVvXm9fUOPy" %} [Oracles](/concepts/data-sources/oracles) {% endcontent-ref %} ### Storage {% content-ref url="/pages/7BlbyD66mibIPZEUXE0G" %} [Decentralized Datastorage](/concepts/data-sources/decentralized-datastorage) {% endcontent-ref %} ### Authentication & Signing {% content-ref url="/pages/7E9WIODDSBI8dUnAOE5t" %} [Account Abstraction modules](/concepts/data-sources/account-abstraction-modules) {% endcontent-ref %} ### Frontends {% content-ref url="/pages/eTpiE9dlBqJB5jjMLfXP" %} [React Frontends](/concepts/data-sources/react-frontends) {% endcontent-ref %} # EVM Chains We are supporting 7 EVM (ethereum virtual machine) blockchains out of the box. That means, we are indexing all data in real-time for these chains for all contracts added on the blocktorch platform. For all of these chains we auto-detect whether a smart contract with the address you want to add is deployed or not. On top we auto-fetch the ABI if the contracts are publicly verified on a block explorer. If you are using the same contract address on multiple chains, you can add the contract on multiple chains in once.
### Bring your own RPC On top of natively supported chains you can bring your own RPC for EVM chains that blocktorch does not natively support. This feature is currently in closed beta to ensure all variaties of EVM compatible chains run smoothly, so please [reach out to us](mailto:contact@blocktorch.xyz) to add your own rpc. {% hint style="info" %} All data for these chains is stored for 7 days on a rolling basis in our free plan. If you need more that 7 days of historic data please [reach out to us](mailto:contact@blocktorch.xyz) so we can agree on a suitable [priced plan](https://www.blocktorch.xyz/pricing) for your needs. {% endhint %} # Roll-ups Blocktorch supports all roll-ups built on the OPStack and on Arbitrum Orbit. Once the roll-up is added to your blocktorch project, we start indexing the data. All features of blocktorch can be fully leveraged for your specific roll-up. You can also enable developers building on your roll-up ecosystem to make use of all features like step-debugging, monitoring and searching.
### Adding your roll-up to blocktorch #### Step 1: Navigate to "Nodes" >> "Roll-ups"
#### Step 2: Click "Add RPC"
#### Step 3: Add your roll-up by choosing Optimism or Arbitrum, give the Roll-up a name & add the RPC as well as a block explorer URL that your roll-up as a service provider supplies to you
{% hint style="success" %} Congratulations, you have successfully added your roll-up to blocktorch 🥳\ If you now try to [add a smart contract](/concepts/data-sources/smart-contracts) to blocktorch that has been deployed on your roll-up you can see your roll-up in the list of available chains {% endhint %} #### Bonus step: Click your roll-up in the node overview to see the status of your roll-up
{% hint style="info" %} #### Never heard about roll-ups? Roll-ups are a secondary layer solution designed to boost the scalability and efficiency of blockchain networks. They operate on top of a base layer blockchain (Layer 1), such as Ethereum, and process transactions outside the main chain. This approach allows roll-ups to significantly reduce congestion and fees, while still maintaining security through the underlying blockchain. There are two main types of roll-ups: * **Zero-Knowledge Roll-ups (ZK-Roll-ups):** These compile multiple transactions into a single proof, called a SNARK (Succinct Non-Interactive Argument of Knowledge), which is then posted to the Layer 1. They offer increased privacy and reduce the amount of data that needs to be stored on the main chain. * **Optimistic Roll-ups:** These assume transactions are valid by default and only perform computational checks if a transaction is challenged. This model favors speed and efficiency, making it useful for applications requiring high transaction throughput. By delegating the transaction processing to a second layer, roll-ups play a crucial role in enhancing the scalability and performance of blockchain technologies. \ Today multiple Roll-up-as-a-Service providers exist like QuickNode, Gelato, Condiut or Zeeve. {% endhint %} # Local forks Blocktorch supports local [Hardhat](https://hardhat.org/) forks either from your machine or you can choose to use a managed hardhat solution from blocktorch. Once the fork is added to your blocktorch project, we start indexing the data. All features of blocktorch can be fully leveraged for your specific fork. You can also enable other developers from your team or for example security auditors you work together with to access your local fork data to make use of all features like step-debugging, monitoring and searching. The data like logs from your local fork persists in your blocktorch project, even if you let your hardhat instance die. You can leverage this data as you develop and test your smart contracts.
### Adding your local fork to blocktorch #### Step 1: Navigate to "Nodes" >> "Hardhat forks"
#### Step 2: Click "Add RPC"
#### Step 3: Add your fork by choosing[ "Hardhat Fork"](/concepts/data-sources/local-forks/setup-hardhat-fork) if you run Hardhat yourself for example locally on your machine or "[Managed Hardhat Fork](/concepts/data-sources/local-forks/setup-managed-hardhat-fork)" if you want to make use of our service to spin the Hardhat fork in the cloud for you. {% content-ref url="/pages/UigMHpfNweJbByMKbWzA" %} [Setup Hardhat fork](/concepts/data-sources/local-forks/setup-hardhat-fork) {% endcontent-ref %} {% content-ref url="/pages/BuOiiSyhgljRAMSTTFKd" %} [Setup managed Hardhat Fork](/concepts/data-sources/local-forks/setup-managed-hardhat-fork) {% endcontent-ref %} {% hint style="info" %} #### New to Hardhat? Hardhat forks are a powerful feature used in blockchain development that allow developers to simulate a local copy of an existing blockchain, such as the Ethereum mainnet, for development and testing purposes. This enables developers to test their smart contracts under real network conditions without the risk of losing real assets or impacting the live blockchain.
#### Why Use Hardhat Forks? * **Testing in Real Conditions:** Replicate the current state of the Ethereum mainnet (or any other network) to test how contracts interact with existing contracts and conditions. * **Cost-Efficient:** Experiment and debug without spending real Ether or tokens. * **Speed and Convenience:** Accelerate development cycles by running tests locally and avoiding network congestion and delays.
#### Alternatives to Hardhat? [Anvil from Foundry](https://book.getfoundry.sh/reference/anvil/) {% endhint %} # Setup Hardhat fork #### Prerequisite: Install Docker for your platform: * [Mac](https://docs.docker.com/desktop/install/mac-install/) * [Linux](https://docs.docker.com/desktop/install/windows-install/) * [Windows](https://docs.docker.com/desktop/install/linux-install/) #### Step 1: Select "Hardhat fork", give your fork a name, and press "Save" {% hint style="info" %} Give your fork a recognizable name to make your life easier later on, e.g. when looking for the fork in the list of chains to add contracts deployed on this fork. Especially if you deploy multiple forks, they should have distinguishable names {% endhint %}
#### Step 2: Click on "Setup Agent" to open your setup info guide
#### Step 3: Get an API Key by clicking on "Create Key" in your setup agent guide
#### Step 4: Run the following command as prompted in the setup guide in your project, as your guide will include all the relevant variables as for example your API Key. Example here: ``` docker run \ -e HARDHAT = true \ -e SOURCE_NODE=https://eth-mainnet.g.alchemy.com/v2/URADvEwKh-zXgTuUQ \ -e BLOCKTORCH_API_KEY=undefined \ -e BLOCKTORCH_CHAIN_ID=c642d08d-ca7e-696-9477-0f9429dcf045 \ -e BLOCKTORCH_PORJECT_ID=e19f3c34-1217-4df0-b2d6-6084411c0dd \ -p=8000:8000 -p=8545:8545 \ ghcr.io/blocktorch-xyz/blocktorch-agent:latest ``` #### Step 5: Add the fork to your project on your machine ``` { networks: { blocktorch: { url: http://127.0.0.1:8545/, accounts: [ example_private_key ] } } } ``` {% hint style="success" %} Congratulations, you have successfully added your local hardhat fork to blocktorch 🥳\ If you now try to [add a smart contract](/concepts/data-sources/smart-contracts) to blocktorch that has been deployed on your local hardhat fork you can see your local hardhat fork in the list of available chains {% endhint %} # Setup managed Hardhat Fork {% hint style="info" %} #### What is a managed Hardhat Fork by blocktorch? Blocktorch managed Hardhat Forks are a zero-setup, private environment for developing and testing smart contracts against production data. With managed Hardhat Forks, you get a private replica of 9 supported EVM mainnets and testnets, with all the developer tooling of the blocktorch platform privately, the latest states, and no performance delays. {% endhint %} #### Step 1: Select "Managed Hardhat Fork", give your fork a name, choose which Chain you'd like to fork, optionally choose the server region you want the fork to run on, and press "Save" {% hint style="info" %} Give your fork a recognizable name to make your life easier later on, e.g. when looking for the fork in the list of chains to add contracts deployed on this fork. Especially if you deploy multiple forks, they should have distinguishable names {% endhint %}
#### Step 2: Copy the RPC URL to start using it in testing your smart contracts and application
{% hint style="success" %} Congratulations, you have successfully added your managed hardhat fork to blocktorch 🥳\ If you now try to [add a smart contract](/concepts/data-sources/smart-contracts) to blocktorch that has been deployed on your managed hardhat fork you can see your managed hardhat fork in the list of available chains {% endhint %} # Hardhat forking API Through this API, users can manage Hardhat instances dynamically, providing a seamless integration for continuous development and testing. ## Authentication All API requests require the use of an API key. You must include your API key in the header of each request. Your API key authenticates your account with the service. ``` x-api-key: {{API_KEY}} ``` Replace `{{API_KEY}}` with your actual API key provided upon account registration. ### Creating a new API key 1. Navigate to the `Settings` page in your project 2. Scroll down to API Setting and create a new API key
3. Give your API key a name and store the secret. Ensure to keep your API key confidential for your Account's security.
### API Base URL ``` https://c6yaznpyf4.execute-api.us-east-1.amazonaws.com/prod/api ``` All endpoints referenced in this documentation start with the above base URL ## Endpoints ### Creating Hardhat Instance `POST` `/hardhat/`{{PROJECT\_ID}} Creates a new Hardhat instance for a given project. **Headers** | Name | Value | | ------------ | ------------------ | | Content-Type | `application/json` | | x-api-key | {{API\_KEY}} | **Data Parameters** | Name | Type | Description | | ----------- | ------ | --------------------------------------------------------------------- | | providerUrl | string | The URL of the Ethereum provider the Hardhat instance will connect to | **Sample call** * Replace `{{PROJECT_ID}}` with the appropriate project ID * Replace `{{PROVIDER_URL}}` with the URL of your Ethereum provider * Ensure that the `API_KEY` is kept secure and not exposed in shared or public environments ``` curl --location 'https://c6yaznpyf4.execute-api.us-east-1.amazonaws.com/prod/api/hardhat/{{PROJECT_ID}}' \ --header 'x-api-key: {{API_KEY}}' \ --header 'Content-Type: application/json' \ --data '{ "providerUrl": "{{PROVIDER_URL}}" }' ``` **Sample Response** {% tabs %} {% tab title="200" %} ```json { "message": "Hardhat instance created successfully", "instanceId": 420 } ``` {% endtab %} {% tab title="400" %} ```json { "error": "Invalid request" } ``` {% endtab %} {% endtabs %} ### Deleting Hardhat instance `DELETE` `/hardhat/{{PROJECT_ID}}/{{CHAIN_ID}}` Deletes an existing Hardhat instance from a specific project and chain. **Headers** | Name | Value | | --------- | ------------ | | x-api-key | {{API\_KEY}} | **Sample Call** * Replace `{{PROJECT_ID}}` and `{{CHAIN_ID}}` with the appropriate project and chain IDs * Ensure that the `API_KEY` is kept secure and not exposed in shared or public environments. ``` curl --location --request DELETE 'https://c6yaznpyf4.execute-api.us-east-1.amazonaws.com/prod/api/hardhat/{{PROJECT_ID}}/{{CHAIN_ID}}' \ --header 'x-api-key: {{API_KEY}}' ``` **Sample Response** {% tabs %} {% tab title="200" %} ```json { "message": "Hardhat instance deleted successfully" } ``` {% endtab %} {% tab title="400" %} ```json { "error": "Invalid request" } ``` {% endtab %} {% endtabs %} # Smart Contracts Blocktorch can be used for smart contracts deployed on * any [EVM blockchain](/concepts/data-sources/evm-chains) natively supported * any custom EVM chain added through [your own rpc](https://app.gitbook.com/o/ON0xQpSk4zb6ZKG9umbE/s/5vTnL6SrT2qX7rXjH96E/~/changes/27/concepts/data-sources/evm-chains#bring-your-own-rpc) * any [roll-ups](/concepts/data-sources/roll-ups) added to your blocktorch project * any [local or managed hardhat fork](/concepts/data-sources/local-forks) added to your blocktorch project Once you add a smart contract to blocktorch, our engine starts indexing the data of that smart contract. For all smart contracts we collect and index: * transaction receipts * logs * events * errors * traces * state changes * balance changes {% hint style="info" %} Blocktorch also handles your contract correctly when using proxy contracts {% endhint %} {% content-ref url="/pages/skpjhG3vuKAVPlDUOkcx" %} [Adding smart contracts](/concepts/data-sources/smart-contracts/adding-smart-contracts) {% endcontent-ref %} ### Smart contract details Once a smart contract has been added it can be clicked in the contract overview page to access all detailed information about his smart contract.
The details page includes * Status of monitors set for the smart contract * General information like name, address and deployed blockchain of the smart contract * Out of the box metrics about the smart contract
* The ABI of the smart contract
* The source code of the smart contract
* All log information related to this smart contract
# Adding smart contracts #### Step 1: Navigate to "Contracts" page
#### Step 2: Click the "Add Contract" button on the top left next to the navigation {% hint style="info" %} As long as you have no contracts added, there are Uniswap V3 contracts as demo data visible in your project. As soon as you add your first contract the Uniswap contracts and data disappear {% endhint %}
#### Step 3: Use the smart contract address in the input field and look for the chain you want to add the contract on
{% hint style="info" %} If you have deployed your smart contract with the same address on multiple chains, you need to choose one of these chains as an initial step, and can add all other chains in a second step to add the contract on all your chains simultaneously. {% endhint %}
#### Step 4: If necessary add the ABI of the contract. If the contract is published & verified on a block explorer the Name and ABI is automatically fetched.
Otherwise upload the ABI as a .json file or paste it into the input field. Your ABI will stay 100% private.
#### Step 5: Change/Add a descriptive contract title. and click "Save"
{% hint style="info" %} Currently contracts can only be added through the UI. If adding contracts through e.g. the CLI, IDE or Hardhat plugin is important for you [please let us know](mailto:contact@blocktorch.xyz) so we can prioritize your feedback in our roadmap. {% endhint %} # Custom Event Data Blocktorch is also supporting the possibility to add custom smart contract data from for example forks that mirror the mainnet state. We started to work with partners that provide you the possibilities of enriching contract data, to integrate them seemlessly into Blocktorch. In addition Blocktorch has been built with interoperability of [Open Telemetry Data](/concepts/telemetry) in mind. That means, in general we are able, to ingest also other custom data into your blocktorch Project. {% hint style="info" %} If you have a custom event data source you would like us to add please [reach out to us](mailto:contact@blocktorch.xyz). {% endhint %} The first partner we have integrated is [Shadow](https://www.shadow.xyz/).
Our frens at [Shadow](https://www.shadow.xyz/) enable you to modify a deployed contract's source code to add gasless custom event logs and view functions on a shadow fork that is instrumented to mirror mainnet state in realtime. If you want to learn more about how to get started with Shadow please check in [their docs](https://docs.shadow.xyz/). ### Adding your Shadow fork to blocktorch #### Step 1: Navigate to "Nodes" >> "Shadow Fork"
#### Step 2: Click "Add RPC"
#### Step 3: Add your fork by choosing Shadow, give the shadow fork a name & add the RPC
{% hint style="success" %} Congratulations, you have successfully added your shadow fork to blocktorch 🥳\ If you now try to [add a smart contract](/concepts/data-sources/smart-contracts) to blocktorch that has been deployed on your shadow fork you can see your fork in the list of available chains {% endhint %} # Oracles In blocktorch there are 6 of the most adopted Oracles supported out of the box. That means if your dApp utilizes any of these 6 Oracles, you can start accessing its data for example for [monitoring](broken://pages/truZ7Fx9rjjFobyAIwf5) without any additional setup. Blocktorch has full support for these oracles no matter the exact technical specifications of these oracles, for example if they work with state variables or event emittance.
{% hint style="info" %} Using another oracle than the natively supported ones? You can monitor it by [adding it to your smart contracts](/concepts/data-sources/smart-contracts/adding-smart-contracts). In case you would like us to support this oracle natively as well, please [reach out to us](mailto:contact@blocktorch.xyz). {% endhint %} ### Accessing out of the box oracle data #### 1. Navigate to "TPM" >> "Oracles
#### 2. Click the Oracle provider you would like to access
#### 3. Navigate between "Performance", "Efficiency", "Health" and "Storage explorer" to access different ready made KPIs and dashboards
### Using the Storage Explorer Depending on the technical implementation of the oracle, storage might be utilized for important oracle feed data. In blocktorch's oracle storage explorer, this data can be accessed and visualized efficiently. #### 1. Once the Oracle has been accessed, navigate to the "Storage explorer" as [explained above](https://app.gitbook.com/o/ON0xQpSk4zb6ZKG9umbE/s/5vTnL6SrT2qX7rXjH96E/~/changes/27/concepts/data-sources/oracles#id-3.-navigate-between-performance-efficiency-health-and-storage-explorer-to-access-different-ready-mad) #### 2. Choose the chain or specific data feed contract you'd like to access data from. On our example we are using [Pyth](https://pyth.network/)'s ETH Sepolia Oracle.
#### 3. Blocktorch auto-detects all state variables that can be accessed from storage in the respective contract. Either type what variable exactly you are looking for or choose from the list. In our example we are using Pyth's Crypto.MATIC/USD price feed to look up how the price has changed.
#### 4. The graph shows the change within the last 12 hours
{% hint style="info" %} #### New to Oracles? Oracles are third-party services that provide smart contracts with external information. They serve as bridges between blockchains and the outside world. Smart contracts, by their nature, cannot access or interact with external data. Oracles play a crucial role in enabling smart contracts to execute based on real-world events and data, such as temperature readings, stock prices, and payment confirmations. There are two main types of oracles: * **Pull Oracles:** These oracles send external data to smart contracts upon request. * **Push Oracles:** These oracles provide data to smart contracts automatically when certain conditions are met, without waiting for a request. Oracles are vital for the functionality of many decentralized applications (DApps), enabling them to interact dynamically with real-world information. However, reliance on oracles introduces a level of trust into otherwise trustless systems, highlighting the importance of choosing reliable and secure oracles. {% endhint %} # Account Abstraction modules In general account abstraction modules (AA modules) or also called smart accounts are a specific EIP implementation ([EIP-4337](https://www.erc4337.io/)), so also smart contracts. That means, all tools and features in Blocktorch that support smart contracts can simply used for these contracts as well. Due to AA's unique role in how dApps are utilizing them today, we decided that better data insights into account abstraction modules deserve a dedicated blocktorch product, and have built an [Account Abstraction Explorer](https://explorer.blocktorch.xyz/). We integrated different AA providers natively, to mark transactions with the respective module providers automatically.
Blocktorch supports account abstraction modules on all [natively supported EVM Chains](/concepts/data-sources/evm-chains). {% hint style="info" %} #### New to Account Abstraction? Account abstraction modules refer to the mechanisms that simplify user interactions with blockchain accounts, making them more flexible and accessible. In decentralized applications (dApps), these modules play a critical role in enhancing user experience and security. Here’s how: * **Simplifying User Experience**: They abstract away the complexities of blockchain interactions, allowing users to engage with DApps through familiar concepts like usernames and passwords, instead of cryptographic keys. * **Enabling Advanced Features**: Account abstraction can enable features like account recovery and multi-signature transactions, which are otherwise challenging to implement directly on the blockchain. * **Increasing Security**: By abstracting account management, these modules can implement additional security layers, such as transaction monitoring and fraud detection, reducing the risk of asset loss. * **Fostering Innovation**: By making it easier for users to interact with DApps, account abstraction modules encourage broader adoption and development of new applications and services on the blockchain. {% endhint %} # Navigating the AA Explorer #### 1. Have a transaction hash at hand to search for, or click on one of the auto detected transactions. Blocktorch's Account Abstraction is a multichain explorer.
#### 2. General transaction information For each transaction the general transaction information include the Status, Timestamp, Gas Used, Gas Price, Fee and the Blunder Size indicating how many UserOps were bundled into this transaction 2.1 Successful Transaction
2.2 Successful Transaction with internal failures
2.3 Reverted Transaction
#### 3. User Operation (UserOp) information includes Bundler Compensation, whether or not a new smart contract has been created in this transaction, if a paymaster was used, the amount processed by the paymaster and the user intent
Simply hover over the ℹ to learn more about each section.
#### 4. The Anatomy of the full Account Abstraction transaction is visualized with the integrated providers of the modules tagged
#### 5. Function invocation call trace can be expanded to see the detailed invocation tree of the full trasnaction. The blue strips on the right side show the gas profiling, indicating which step used the most gas
#### 6. Interactive interaction flow can be accessed by elapsing on the arrow on the right to see the full flow. The strength of the lines indicate the gas used on the transaction. The flow let's you follow were exactly the transaction failed. Clicking on the branches can elapse and expand the flow tree. 6.1 Successful Transaction
6.2 Successful Transaction with internal failures
6.3 Reverted Transaction
#### 6. Metrics are shown where available with KPIs about the Bundler, the Paymaster and the Smart Accounts used in the transaction {% hint style="info" %} Want to learn more about account abstraction and see blocktorch's AA explorer live in action? Check out this Workshop Series by [Alchemy](https://www.alchemy.com/) and [Offchain Labs](https://www.offchainlabs.com/) (Arbitrum):\ \ \[blocktorch's explorer live in action from minute 42:00] {% endhint %} # Decentralized Datastorage Writing to blockchains can quickly get expensive in terms of gas if tried to store large blobs of data like images or videos. Thus you might be considering decentralized datastorage providers in your dApp architecture. Unlike traditional cloud storage solutions that rely on centralized servers, decentralized storage systems utilize a network of peers to store and manage data. This approach enhances data security, privacy, and availability. Currently in closed beta, blocktorch supports [IPFS](https://ipfs.tech/) natively. To get access to IPFS data in your blocktorch project please [reach out to us](mailto:contact@blocktorch.xyz).
{% hint style="info" %} ### IPFS - InterPlanetary File System IPFS (InterPlanetary File System) is a protocol and peer-to-peer network for storing and sharing data in a distributed file system. IPFS uses content-addressing to uniquely identify each file in a global namespace, connecting all computing devices with the same system of files. #### Key Features of IPFS: * **Decentralization**: Eliminates reliance on centralized servers. * **Content Addressing**: Files are accessed by their content, not location. * **Efficiency**: Reduces duplicate files and speeds up the web. * **Resilience**: Enables websites and applications to remain accessible in the event of node failures. ### Use Cases for IPFS * **Decentralized Websites**: Hosting websites on IPFS makes them resistant to censorship and ensures they remain accessible even if parts of the network go down. * **Data Storage**: IPFS provides secure, decentralized storage solutions for data, reducing reliance on centralized cloud providers. * **Digital Content Distribution**: Content creators can distribute media directly to consumers without intermediaries, improving speed and reducing costs. * **Archiving**: Offers a robust solution for preserving information over long periods, protecting it from loss due to centralized failures. Decentralized data storage, particularly through IPFS, offers a more secure, efficient, and resilient way of managing digital information in the modern internet age. {% endhint %} # React Frontends Transactions that fail in the client/frontend cannot be found in a block explorer as the transaction never makes it into the mempool and subsequently on chain. For that reason, the Blocktorch team developed [Dragon](https://www.npmjs.com/package/@blocktorch/0xdragon), an SDK that can easily be added to dApp frontends utilizing [React](https://react.dev/). With Dragon you can track failing and successful web3 client transactions for [debugging](/use-cases/debugging) as well as [analytics](broken://pages/N9ZEqoGw7aCfFJcWnAso). ### Why consider using Dragon? * json RPC responses, especially error messages, in the UI are cryptic * to understand whether errors impacting users are a bug in the frontend or the smart contract * to get better analytics about the wallets interacting with your dApp * to understand if wallets are interacting with your smart contracts through your dApp frontend or through their own scripts, which can especially be helpful for security ### Installation ``` npm install @blocktorch/0xdragon ``` or if you prefer yarn ``` yarn add @blocktorch/0xdragon ``` ### Usage #### SDK initialization ``` import { Dragon } from '@blocktorch/0xdragon' const dragon = new Dragon({ projectId: , apiKey: }) ``` You can get your project ID and api key from the [Blocktorch app](https://beta.blocktorch.xyz) on the "Settings" page
In the constructor you can also specify additional options: * `contractName` (*string*) - default identifier for what the transactions are interacting with. Default is "unknown" * `chainId` (*number*) - chain ID of the application * `http` (*object*): * `maxRetries` (*number*) - number of times failed SDK requests are retried * `delay` (*number*) - number of times failed SDK requests are retried * `exponentialBackoff` (*boolean*) - Whether to allow exponential backoff or not #### init(options?) Initialize the tracking of a single transaction ``` const id = dragon.init() ``` You can override options per transaction. * `contract` (*string*) - identifier for what the transaction is interacting with * `chainId` (*number*) - id of the blockchain #### success(id, transaction) Track the transaction as a success. Should be done after the transaction is accepted on chain. ``` await dragon.success(id, transaction) ``` #### error(id, error) Track the transaction as an error ``` await dragon.error(id, error) ``` #### wrap(fn, options?) If you are using ethers\@5 or any other compatible libraries you can use a helper function to wrap your whole transaction and it will detect success or failure itself. It will wait until the transaction receipt is received to mark it as a success. ``` await dragon.wrap( contract.doSmth({ value: ethers.utils.parseEther("0.1") }) ) ``` You can also specify the following options: * `contract` (*string*) - identifier for what the transaction is interacting with * `chainId` (*number*) - id of the blockchain ### Accessing data collected by Dragon All dragon data can be queried for [monitoring](/use-cases/monitoring) as well as when [searching](/use-cases/searching) logs. For successful transactions we automatically contextualize your transaction logs with dragon data to show the full [end-2-end trace](/use-cases/tracing) # Querying data Blocktorch's query engine is responsible for processing and analyzing the collected data to provide insights and support decision-making. Data provided in blocktorch is close to real-time, the status and uptime of our query engine can be checked any time on our [status page](https://blocktorch.instatus.com/). dApps introduce complexity to the querying process, including: * Querying data across multiple chains and platforms. * Handling the unique data structures and formats associated with web3 data. Blocktorch's query engine is designed to tackle these challenges by: * Consolidating and contextualizing data from multiple sources, providing a unified view for analysis. * Supporting complex queries and aggregations on web3-specific data structures, such as smart contract events, function calls, and transaction logs. You can create rich queries through the blocktorch UI. You can start gaining fast and unique insights without having to push a single line of code. ### Querying data through blocktorch's no-code query chips For [monitoring](/use-cases/monitoring) purposes all data can be queried through blocktorch's unique query chips, no code required. The query chips automatically suggest all possible [data sources](/concepts/data-sources) added to your projects that monitors can be built on. Navigate to "Explore" to start building queries, if the query result is a valid one the graph will show data. More details can be found in the section[ building monitors](/use-cases/monitoring/building-monitors).
### Querying data through fuzzy search and search facets In Blocktorch's [search](/use-cases/searching), log data can be queried through fuzzy search. Fuzzy search in Blocktorch allows users to find log data across data sources and across chains even if the search terms are not exact matches to the data. This feature enhances the flexibility and efficiency of searching, making it easier for users to locate the information they need without knowing the precise terms used in the data. For example not knowing the full contract name and searching for "Universal" will query all data of the contract "UniversalRouter". You can also utilize popular search facets if you query the same data often for e.g. the same contracts in different time ranges, same function calls in different chains, etc.
Fine tuning your search Your search query can be fine tuned by updating, removing or adding single chips to the query. To update a chip simply click its value and change it

Fine tuning and updating search in blocktorch search

### Sharing the search results ### Querying data programmatically Querying data through blocktorch's API is currently only open to our enterprise customers. If you need access to our API please [contact us ](mailto:contact@blocktorch.xyz)to discuss your specific requirements and a suitable enterprise contract with you. {% hint style="info" %} In blocktorch's free tier everyone can create as many data queries as you wish for a timeframe of up to 7 days in the past. To get access to a wider time frame please [contact us ](mailto:contact@blocktorch.xyz)to discuss a suitable [pricing tier](https://www.blocktorch.xyz/pricing) with you. {% endhint %} #### # Telemetry Open Telemetry is an observability framework for cloud-native software developed by the [Cloud Native Computing Foundation](https://www.cncf.io/), offering a comprehensive toolkit for gathering, processing, and exporting telemetry data such as metrics, logs, and traces in a vendor-neutral manner. Telemetry, at its core, is the automated process of collecting measurements or data from remote or inaccessible points and transmitting them to receiving equipment for monitoring. In the landscape of web3 and blockchain technologies, adhering to the Open Telemetry standard is not trivial due to the complexity and decentralized nature of these networks. Blocktorch uniquely navigates this landscape by implementing the Open Telemetry standard, ensuring that developers and organizations can monitor and troubleshoot their decentralized applications (dApps) with the same rigor and precision as traditional cloud-native applications. This adherence underscores Blocktorch's commitment to enhancing the observability and reliability of web3 and blockchain ecosystems, setting a new benchmark in the space. ### Why open telemetry interoperability matters in web3 Open Telemetry’s role in the evolving landscape of web apps—transitioning from web2 to web3—is critical for ensuring that monitoring and observability practices keep pace with technological advancements. Most web3 applications today are, in essence, web2.5 applications. This hybrid status means that while they incorporate decentralized technologies, they still heavily rely on traditional cloud services and infrastructure to perform various functions. It’s a blend of the old and the new, where the decentralized components of web3 are augmented by the reliability and scalability of established web2 cloud services. Blocktorch seamlessly bridges the gap between these two worlds. It ensures that telemetry data from web3 components is fully interoperable with the telemetry data derived from cloud services. This means that developers can use Blocktorch to monitor their decentralized components and, simultaneously, integrate this data with traditional observability tools like [Datadog](https://www.datadoghq.com/). This integration is seamless, providing a comprehensive view of an application’s performance and health, regardless of whether components are hosted on decentralized networks or traditional cloud platforms. This capability is invaluable for developers seeking to maintain high standards of reliability, performance, and user experience in their web3 applications, ensuring a smooth and efficient monitoring process that leverages the best of both worlds. # Searching ### General searching in blocktorch Blocktorch's search capabilities are a powerful tool designed to help users search, analyze, and explore logs and metrics generated by your dApp and services utilized by your dApp (e.g. Oracles) in the fastet possible way. In the monitors as well as the search page, there is a search input field on the very top of the page to quickly find the data points you are looking for

Search input field for finding specific monitors based on e.g. monitor names, or data sources involved

Search input field for finding logs, transactions and traces

### Blocktorch's Search page In web3 the name "explorer" has been established for finding transaction and block related data. However, blocktorch's search is way more than a blockexplorer when it comes to system logs, and less when it comes to actual block related information. Therefore we have named blocktorch's search simply "Search". Blocktorch's Search is multichain, multi data source, and multi datatype. **One stop to find all your dApp's logs.**
To search for logs, transactions and traces in the Search page, build your [search query](/concepts/querying-data#querying-data-through-fuzzy-search-and-search-facets). The search query can be one or multiple keywords or facet. Advanced search capabilities, including fuzzy search and faceted search, allow you to quickly find the information you need. The Search will return a list of matching log entries based on your query. For fuzzy search try for example search for the data source the log should originate from, wallets, contracts, status (Success/Fail), nonces, and many more. Fuzzy search can be combined with the query chips. ### Fine tuning your search Your search query can be fine tuned by updating, removing or adding single chips to the query. To update a chip simply click its value and change it

Fine tuning and updating search in blocktorch search

# Logs Logs in blocktorch are all the records of events and transactions and that occur within a decentralized application and its utilized services. The logs play a critical role in monitoring the service's health, troubleshooting issues, and understanding user activities. The result of your logs query always include: * **`Status`**: Logs are categorized by status levels such as EVENT, SUCCESS, REVERTED, FAILED. This helps in filtering logs based on relevance for your query. * **`Timestamp`**: Each log entry includes a timestamp, indicating when the event occurred. This is crucial for tracking the order of events. In Blocktorch's free version everyone can access logs up to 7 days in the past. You can filter for specific time windows or also look at the logs as they are streamed live. * **`Type`**: There are 4 types of logs blocktorch captures: * **`TRANSACTION`**: a transaction call is produced with any invoked transaction, and can result in logs of the other 3 types being produced * **`CALL`**: a call log is produced when a smart contract function is called * **`DELEGATE`**: a delegate log is produced when a caller contract executes code from another smart contract, that is especially the case when using proxy architecture * **`STATIC`**: a static call log is produced when a read function is invoked so there is no change to state * **`Service/Contract`**: The contract message provides details about the smart contract / service that produced the log and which chain it has been triggered on * **`Content`**: Additional context is given through information like the function name invoked, its transaction hash or the error message, if the smart contract ABI is unknown the signature will be `anonymous`
{% hint style="info" %} The pre-filtered logs for a specific smart contract can be found on the detail page of a smart contract by clicking your contract in the smart contract overview page {% endhint %} # Log Details Click on a log to expand log details Every single log includes a vast array of detailed information. Blocktorch log details provide information about * `Log type`
* `Transaction hash`
* `Status`
* `Decoded function signature` - if the smart contract ABI is unknown the signature will be `anonymous`
* `Chain` - you can click the chain name to get redirected to the chain detail page, which can be especially useful in case of [roll-ups](/concepts/data-sources/roll-ups) and [local forks](/concepts/data-sources/local-forks) to e.g. understand if it is synced with the head of the chain
* `From address` - if this is a contract added in your project the name will be displayed, and you can navigate to the contract details page by clicking it
* `To address` - if this is a contract added in your project the name will be displayed, and you can navigate to the contract details page by clicking it
* `Timestamp` - the format of the timestamp is the time zone of your browser/machine
* `Metrics` - out of the box KPIs for this specific function call with a reference to which datapoint this specific transaction is
* `Transaction Data` - the full decoded transaction data
* `Stack trace` - the complete decoded stack trace including gas profiling
* `Interaction flow` - the full decoded function invocation flow
* `L1/L2 tracing` - available in the case of roll-up transactions the full trace across L2 and L1 * `Emitted Events` - available in case events have been emitted in the transaction an array of emitted events From the log details you can also navigate to the [blocktorch transaction step debugger](/use-cases/debugging/step-debugger) by clicking the button on the top right, to analyze and debug the specific transaction closely
# Sharing search results To share search results, simply copy the URL from the address bar and send it to the desired recipient. The recipient will be able to view the same search results by visiting the shared URL. {% hint style="danger" %} If you share this link with anyone not part of your project organization by sharing your result the recipient will join your project as if you [invite the person](/use-cases/collaborating/inviting-others). this means the recipient will also be able to access all other data of your project. Only people who you can trust should be invited your project! {% endhint %}
# Monitoring Monitoring in Blocktorch plays an important role in enhancing the observability of your dApp and becoming data driven. By leveraging continuous monitoring, blocktorch enables you to detect anomalies, understand transaction flows, and ensure the integrity and reliability of your dApp. ### Blocktorch's Monitoring Capabilities * **Cross-chain & source:** Blocktorch allows monitoring metrics across chains, across smart contracts, across functions * **Real-time Monitoring**: Blocktorch provides real-time insights into all the supported [data sources](/concepts/data-sources) and its metadata like transactions, state changes, block spaces, etc, enabling immediate detection of issues. * **Custom Alerts**: Blocktorch allows setting up customized alerts for specific events or anomalies, facilitating prompt response to critical incidents. * **Dashboarding:** All your monitors come with a [custom graph](/use-cases/dashboarding/custom-graphs) of the data you want to monitor to visualize the data. * **Performance Analysis**: Users of our closed beta feature can access detailed reports and analytics on a weekly basis to optimize the efficiency and speed of their DApps. If you are interested in receiving weekly performance reports on your stack please [request access to the feature](mailto:contact@blocktorch.xyz). * **Automated Actions**: Users of our closed beta feature can unlock automated actions that get triggered off-chain or on-chain based on specific events being fired or monitor alerts being tiggered. If you are interested in utilizing automated actions [request access to the feature](mailto:contact@blocktorch.xyz). ### Monitor overview To see the overview of all your monitors navigate to Monitors. You can [search for specific monitors ](/use-cases/searching#general-searching-in-blocktorch)with the search bar on top. The timeframe the monitors are visualized on are by default `1 hour.` You can change the timeframe with the date picker to `15 minutes` or `1 day`. The red horizontal line always indicates your set target of the monitor.
# Building monitors In your project you can currently build as many monitors as you like, there is no restriction to the number of monitors in the free plan. ## How to build a monitor To navigate to the page for building the monitor you can either open `Explore` from the side navigation or on your monitors overview page click the `Add Monitor` button on the top right
### 1. Building the monitor query 1.1. Selecting the data source(s) * The available data sources to build a monitor data query on are shown in a drop down. The `chain logo` indicates which chain this smart contract has been deployed on, folowed by the `Name` of the smart contract given by you when you added the smart contract
* You can choose one or multiple of them * Chosen smart contracts can be deployed on different chains to build a cross-chain query
1.2. Selecting the metric to monitor from the drop down list
1.3. Selecting specific events or state variables if the metric to monitors is `Transaction Event` or `Transaction State Variables.` All events or state variables detected that are avaiable to monitor are showin in the drop down. In case of a long list simply start writing the name of the variable the the list will update
1.4. Setting conditionional filters. Setting filters is optional and can be dismissed. Based on the condition you choose the operator list differs. Multiple conditions can be concatenated * `Transaction Status` * Type: `string` * Available operators: `=` (equal) and `!=` (not equal) * Values: `SUCCEEDED` or `REVERTED` * `Transaction Gas Used`, `Transaction Count`, `Transaction Index`, `Transaction Value`, `Transaction Gas Price` and `Max Fee Per Gas` * Type: `integer` * Available operators:`=` (equal), `!=` (not equal), `>` (larger than), `<` (smaller than), `>=` (larger and equal than) and `<=` (smaller and equal than) * Values: integers from 0 to bignumber
1.5. Grouping by is set to `None` by default, and can also be set to `Address`, `Blockchain`, `Signature` or `Event`
1.6. Choosing the mathematical operation to be performed on the query. The possible options are `AVG` (average), `COUNT`, `SUM`, `MIN` (minimum), `MAX` (maximum)
{% hint style="success" %} Once you have fully set the query you will see the data visualized in the chart above. In our example query we are comparing the accumulated (=`SUM` as math operation) number of transactions (= Transaction `Count` as metric) on the Uniswap SwapRouter on Ethereum and Arbitrum (= `Data Sources`) by grouping by `Blockchain` {% endhint %}
### 2. Setting the monitor time window The time window of the monitor specifies the period the metric shall be calculated on on a roll basis. In our example above we calculate the amount of transactions on a 1 hour rolling basis.
### 3. Setting the monitor target The target of the monitor has an important implication for the [alerting](/use-cases/monitoring/alerting) functionality. As soon as the target is hit by the metric a notification will be triggered. The target is visualized in your monitor chart as a horizontal red line, any datapoint crossing the target is also visualized in red in your chart. Type of the target is always an `integer.` If you are unsure where to set your target it makes sense to (1) analyze the chart of your query above and look into the range of y-axis values your data usualy moves in. A certain area outside of this norm range might be a suitable target (2) once you have set the monitor make sure to revisit regularly and adjust the target accordingly
{% hint style="success" %} Once you have set the time window to compute the metric and the target your graph will be updated accordingly {% endhint %}
### 4. Adding context with a title For the purpose of context and also for searchability later on, add a descriptive Title to your monitor
### 5. Saving the monitor To finish the setup of your monitor hit the save button on the top right corner.
{% hint style="success" %} The new monitor will now show up in your monitors overview page. The chains you grouped by show up as the chain IDs. When clicking the pencil on the top right you can update your monitor {% endhint %}
# Alerting Alerting and notification are vital components of blocktorch's observability platform, helping teams to react promptly to potential issues. By setting the right thresholds for alerts and ensuring they are delivered through preferred channels to the relevant stakeholders, you can significantly reduce the Mean Time to Recovery (MTTR). This not only helps in minimizing downtime but also safeguards the customer experience and maintains operational efficiency. The key is to strike a balance between alert sensitivity and notification fatigue to ensure that every alert prompts a timely and effective response. ### Alert trigger The alert trigger is [the target you set when building a monitor](https://docs.blocktorch.xyz/use-cases/monitoring/pages/Twhl5L8vDcNCiEsYqKoM#id-3.-setting-the-monitor-target) The alert is getting triggered every time the target is hit ### Alert destination Alerts are currently set via email. In case you would like to receive alerts via Slack, Discord, Telegram, PagerDuty or on-chain via Push Protocol [please reach out to us](mailto:contact@blocktorch.xyz). ### Who receives the alerts Alerts to sent to all members of your project. That means everyone who [you invited to your project](/use-cases/collaborating/inviting-others) and has accept this invite will receive all alerts as well. In case you would like to have triaging of alerts based on e.g. role or creator of the alert [please reach out to us](mailto:contact@blocktorch.xyz). # Tracing ### Tracing Overview Tracing is a technique used in software development to monitor and record specific information about a program's execution. It's a crucial part of debugging and performance analysis, allowing developers to understand how a program behaves at runtime, and identify any potential issues or bottlenecks. #### Key Aspects of Tracing * **Visibility**: Tracing provides visibility into the transaction flow and its interaction with different functions, making it easier to pinpoint errors or inefficiencies. * **Performance Analysis**: By analyzing trace logs, developers can identify slow operations and optimize them to improve overall performance. * **Debugging**: Tracing allows developers to examine the state of a program at various points in execution, facilitating easier debugging of complex issues. * **Monitoring**: In production environments, tracing can be used to monitor the health and performance of applications, aiding in proactive maintenance. #### Blocktorch's Tracing capabilities * [**Stack traces**](/use-cases/tracing/stack-traces) for smart contract transactions * [**Invocation flows**](broken://pages/vqW6eom34J5WqcORSIXn) to follow through the tree of function invocations visually * [**End-2-End Traces**](/use-cases/tracing/end-2-end-traces) across different systems by creating a full span starting from the user action in your application's [User Interface](/concepts/data-sources/react-frontends) # Stack traces Stack traces in blocktorch are provided as call trace as well as interaction flow visualization. They are accessible in the [log details](/use-cases/searching/logs/log-details), the [account abstraction explorer](/concepts/data-sources/account-abstraction-modules) and the [step debugger](/use-cases/debugging/step-debugger). The stack trace displays the sequence of function calls in a transaction as a tree structure. Each element represents a function call or event trigger and includes information such as call stack depth, call type, and call parameters. In the[ Step debugger ](/use-cases/debugging/step-debugger)you can also access the smart contract source code along with the stack trace to dig deeper into the data. ### Call trace
The call trace includes: * The `Calltype` which can be `CALL`, `STATICCALL` or `DELEGATECALL` * The `Gas used` shown as whole number in \[] and on the right side visualized in blue bars to do gas profiling of each function step * The `to address` of the contract the call was made to * The decoded function signature with the argument types it requires * The `+` and `-` signs enable you to elapse and expand the tree ### Interaction flow
The call trace includes: * The `Calltype` which can be `CALL`, `STATICCALL` , `DELEGATECALL` or `OTHER` , the call types are also visually color coded as the color of the branch * The `Gas used` visualized as the thickness/weight of the branch * The `to address` of the contract the call was made to * The decoded function signature with the argument types it requires * The round node at each branch can be clicked to elapse and expand the branch # End-2-End Traces End-to-end (E2E) traces track an operation's journey through the entire decentralized application architecture. Starting from the frontend data source, E2E tracing assigns a unique span ID to each captured event. These spans document every step and invocation, creating a cohesive, long trace. This trace effectively maps the operation's path through various [data sources](/concepts/data-sources), enabling clear visibility into the performance and potential bottlenecks within the system's workflow. When your [dApp frontend](/concepts/data-sources/react-frontends) is added as datasource to blocktorch through [installing Dragon SDK](/concepts/data-sources/react-frontends#installation), each successful user interaction triggered in your dApps's frontend leading to a transaction on the blockchain will show up as a full trace in your [log details](/use-cases/searching/logs/log-details). # Dashboarding Dashboards in blocktorch offer a powerful and user-friendly interface that allows to gain insights into data quickly. With dashboards data can be visually tracked and analyzed. Dashboarding plays a pivotal role in enhancing the process of root cause analysis and fostering data-driven decisions. By aggregating data from multiple sources into a unified, interactive interface, dashboards simplify the identification of trends, outliers, and patterns that might indicate underlying issues. This real-time visibility into data not only accelerates the root cause analysis process but also ensures that decisions are based on the most current data available. Furthermore, the ability to customize and drill down into specific data points allows users to uncover the subtleties behind performance metrics, leading to more informed, precise, and effective decision-making. # Pre-made dashboards Blocktorch aims at providing the fastest data insights into your dApp stack, so we have created a number of pre-made dashboards throughout the platform based on user feedback. ### Home dashboard In Blocktorch the home of your project always provides global KPIs about all your [smart contracts](/concepts/data-sources/smart-contracts) out of the box, zero set up time from your side required. You can gain instant insights about the total unique users, gas burn, transaction velocity as well as monitors about the performance, efficiency and health of your dApp.

Blocktorch home

To navigate to the home dashboard anytime click the burning torch in the top left of the navigation. In case your torch is not on fire please do not panic, we are working hard on restoring all services, you can check our [status page](https://blocktorch.instatus.com/) anytime.
Hover over the chart to see the tooltip with specific data points. To hide data simply click on the respective legend.
{% hint style="info" %} Want to add custom monitors to the home dashboard? [Please let us know](mailto:contact@blocktorch.xyz) {% endhint %} ### Contract details page dashboard Every [smart contract that has been added](/concepts/data-sources/smart-contracts/adding-smart-contracts) to your project has its own details page. To access the details page click the contract in your smart contract overview. You can gain instant insights about the total unique wallets, gas burn, transaction values as well as revert rates of each smart contract.
To dig deeper into the logs of the data visualized, click on the specific data point in the chart you are interested to learn more about and click `Related Transactions`
{% hint style="info" %} Want to add custom monitors to the contract details dashboard? [Please let us know](mailto:contact@blocktorch.xyz) {% endhint %} ### Oracle details page dashboard Every [oracle supported by blocktorch](/concepts/data-sources/oracles) has its own details page. To access the details page click the oracle in your Oracles overview. You can gain instant insights about the the performance, efficiency and health of the oracle and [compare it to others](/use-cases/benchmarking).
{% hint style="info" %} Want to add custom monitors to the oracle details dashboard? [Please let us know](mailto:contact@blocktorch.xyz) {% endhint %} ### Transaction detail analytics dashboard In the [log details](/use-cases/searching/logs/log-details), there are four out of the box KPIs for this specific function call with a reference to which datapoint this specific transaction is throughout the timeline.
{% hint style="info" %} Want to add custom monitors to the log detail analytics dashboard? [Please let us know](mailto:contact@blocktorch.xyz) {% endhint %} * # Custom graphs Of course you are also able to create your own dashboards with monitor graphs. There is no restriction on the number of monitors you are creating in the current free tier. As soon as a new [monitor is built](/use-cases/monitoring/building-monitors) a visualization of that monitor is created as well. In the Monitor overview page all visualizations of your monitors can be found. These visualizations provide an at-a-glance view of the overall KPIS of your decentralized application, making it easy to identify trends, patterns, and potential issues.
{% hint style="info" %} Currently blocktorch provides stacked bar charts and stacked line charts. If you require different chart styles please [contact us](mailto:contact@blocktorch.xyz). {% endhint %} # Collaborating Collaboration is a cornerstone of successful software development, enabling teams to combine diverse skills, perspectives, and experiences to solve complex problems and innovate. Effective collaboration leads to higher quality software, quicker problem resolution, and a more agile development process. By leveraging the collective knowledge and capabilities of the team, organizations can more efficiently meet the evolving needs of their users and stay competitive in the rapidly changing tech landscape. In the context of web3, collaboration takes a distinct form, characterized by decentralized autonomous organizations (DAOs) and highly distributed teams. Unlike traditional settings, web3 projects often involve contributors from around the globe working asynchronously, relying on blockchain technologies and trustless systems for governance and decision-making. This decentralized approach fosters a unique environment for innovation, as it taps into a vast pool of talents and ideas without the constraints of geography or hierarchies. Recognizing the potential and challenges of such collaboration in web3 environments, **blocktorch** aims to facilitate seamless collaboration in software development and data insights, ensuring that teams can efficiently work together, regardless of their location. In blocktorch you can collaborate in two ways (1) [inviting others to your project](/use-cases/collaborating/inviting-others) and (2) [sharing certain data ](/use-cases/collaborating/sharing-data)to people outside of your project. # Inviting others Inviting others to your project will enable them full access to the project, giving them rights to * add, update and delete [data sources](/concepts/data-sources) * add , update and delete [monitors](/use-cases/monitoring) * [searching](/use-cases/searching) all [logs](/use-cases/searching/logs) and seeing its [details](/use-cases/searching/logs/log-details) * inviting others to the same project {% hint style="warning" %} Only invite people that you trust! Blocktorch team members will never approach you actively to get added to your project, also not in customer support cases {% endhint %} ### The extremely fast way of inviting 1. Click the `+` icon in the navigation menu
2. Input the email address and send the invite
3. The invitee receives a magic link to join the project ### The still very fast way of inviting 1. Navigate to the `Settings` page
2. Scroll down to `Access Settings` 3. Click the `Invite User` button
4. Input the email address and send the invite
5. The invitee receives a magic link to join the project ### The status of your invites 1. Navigate to the `Settings` page
2. Scroll down to `Access Settings` 3. The table shows on the very left whether an invite has been accepted or is pending
### Seeing your tean members * Navigate to the `Settings` page * Scroll down to `Access Settings` * The table shows all people in the project with it's status, the userID and the eMail address * `Admin` status indicates who has created the project * `Accepted` status indicated that member have access to the project * `Pending` status indicated that the person has not yet accepted the invite to join {% hint style="danger" %} One user cannot be part of multiple projects today. If the invitee is part of an existing project, and accepts your invite, the invitee loses access to the other project. {% endhint %} # Sharing data ### Making your project's home dashboard publicly accessible 1. On the left of your home dashboard there is a Share button, click the button to make the dashboard publicly available
2. Give your dashboard a title and click the share button
3. As soon as the share button is clicked, the link to the publicly available dashboard is copied to your clipboard
4. You can now share this link with anyone
### Sharing log search results To share search results, simply copy the URL from the address bar and send it to the desired recipient. The recipient will be able to view the same search results by visiting the shared URL. {% hint style="danger" %} If you share this link with anyone not part of your project organization by sharing your result the recipient will join your project as if you [invite the person](/use-cases/collaborating/inviting-others). this means the recipient will also be able to access all other data of your project. Only people who you can trust should be invited your project! {% endhint %}
# Debugging Debugging smart contract transactions is an indispensable step in ensuring their reliability and security before they are deployed on the blockchain as well as understanding them thoroughly in production when planning and developing the next version of the protocol. When a transaction fails or behaves unexpectedly, developers need to trace the [execution flow](/use-cases/tracing/stack-traces), inspect state changes, and [examine gas consumption](/use-cases/tracing/stack-traces) at each step. Blocktorch's [local fork feature](/concepts/data-sources/local-forks) and [step debugger](/use-cases/debugging/step-debugger) provide environments where developers can simulate transactions, dig into call stacks, and interact with the contract's state. Furthermore, incorporating comprehensive logging (meaning adding relevant events that are emitted) within the contract can significantly aid in identifying issues quickly. As smart contracts handle valuable assets and sensitive operations, thorough debugging is paramount to maintaining trust and functionality in decentralized applications. # Step debugger Blocktorch's Step Debugger simplifies debugging by providing detailed insights into blockchain transaction execution. It helps identify and solve issues quickly, enhancing your development speed. ### Getting started with the step debugger #### Navigating to the debugger To use the Debugger, you need to start from a specific transaction. 1. Either go to the [Search](/use-cases/searching) page from the navigation to choose a transaction or search for a transaction hash in the search bar on top, or click a specific contract in the contract overview to see the contract's logs 2. Click the `🪲`` `**`Debugger`** button located at the top right of the [log details](/use-cases/searching/logs/log-details).
#### Using the step debugger The Debugger interface is comprised of three main sections: * **Execution trace** (left): Displays the sequence of calls made during the transaction, , which can be used to navigate through the code. * **Smart contract source code** (top right): Shows the code of the contract being interacted with. If a contract is not added to the project and thus the ABI is unknown we will not be able to show the full decoded data, * **Call information** (bottom right): Provides detailed info about the current call.
# Benchmarking Benchmarking is an essential practice for staying competitive and enhancing your stack. By systematically comparing your smart contracts or oracle providers against industry standards or competitors, you engage in a continuous process of identifying areas for improvement. This data-driven approach enables you to make informed decisions that ultimately benefit the end user. By focusing on efficiency, security, and performance, benchmarking ensures that your technology not only meets but exceeds the expectations of its users, fostering trust and reliability in your services. Blocktorchs aims at providing all users best in class benchmarking possibilities ### Benchmark against others in your home dashboard In your home select `Asset to compare` on the right of the screen
You can either benchmark against protocols you have added to your blocktorch project yourself (e.g. your fiercest competitor's contract or your biggest role model) or use some predefined contracts for DeFi (Uniswap V3), NFT marketplaces (Opensea's Seaport), Stablecoins (Dai) or Name Services (ENS) Simply choose the protocol to compare from the drop down
Once you have chosen who to compare against, all your home dashboard's visuals will show the comparison data in orange
# Managing incidents Incident management is a critical component in maintaining the operational integrity and reliability of Web3 applications. It entails the prompt identification, assessment, and rectification of issues to avert their recurrence. The significance of this process in the web3 cannot be underestimated. While audits are very important before going to production, the risk of incidents is still imminent. Proper incident response and management is vital. Not only does effective incident management minimize service downtime and ensure security; it also plays a vital role in preserving and enhancing the trust of the user community. In the dynamic and often unpredictable realm of web3, where new vulnerabilities can emerge rapidly, the ability to efficiently manage and resolve incidents reinforces user confidence and fosters a more secure and stable environment for digital transactions and interactions. Of course incidents are not only exploits, but incidents can also be pure service downtime. While blocktorch aims at equipping web3 engineers with tools for developing secure and robust applications and increase collaboration between security auditors and engineers, we also want to give our users the best possible toolkit to [troubleshoot](/use-cases/managing-incidents/troubelshooting) in case of incidents and problems as well as making sure they do not happen again. > "Instead of proactively knowing about any issues arising in any piece of our stack we had to purely rely on the audits, and wait for our community to flag issues in our Discord. With blocktorch we were able to turn this process around and manage reliability proactively." # Troubelshooting At blocktorch we aim at being a reliable partner of our users throughout the whole software development lifecycle, and also equip engineers with the right tooling and data insights when troubleshooting. Below is an outline of steps that can be taken during the troubleshooting process and how blocktorch's toolkit can be of help during the process. Our mission is to help making web3 more reliable and secure for everyone involved. #### 1. Initial Assessment * **Identify Symptoms**: Determine if the issue is a downtime or a security breach. * Building the relevant [monitors](/use-cases/monitoring) in blocktorch can be crucial in identifying systems as fast as possible. Blocktorch ships some [KPIs and visuals out of the box](/use-cases/dashboarding/pre-made-dashboards), which can help in identifying issues, but you know your software better than us, so building custom monitors is an important practice. From the charts you can directly navigate to the related logs by clicking the data points in the chart you need to investigate further * **Scope of Impact**: Assess the extent—how many services, users, or systems are affected. * Looking at the[ stack traces and invocation flows](/use-cases/tracing) of the relevant logs can help figure out bottlenecks and affected services * We highly recommend also making use of [blocktorch's frontend Dragon SDK](/concepts/data-sources/react-frontends) to get deeper insights on client side issues #### 2. Communication * **Notify Stakeholders**: Inform the relevant team members and stakeholders about the issue. * When your team members and stakeholders are[ part of your blocktorch project](/use-cases/collaborating/inviting-others), they can receive monitor alerts proactively * **External Communication**: If necessary, prepare a communication plan for customers or the public. * Home dashboards as well as search queries are [shareable](/use-cases/collaborating/sharing-data) also with external stakeholders, so your community of users can get informed as well #### 3. Isolation * **Isolate Affected Systems**: To prevent further damage, isolate the compromised or malfunctioning components. * **Limit Access**: Restrict access to sensitive systems until the nature and scope of the issue are understood. * you can disable functionalities in your UI * if your smart contracts are built with the functionality to pause functions, you can think of doing so #### 4. Investigation * **Review Logs**: Check application, security, and system logs for anomalies or indicators of the cause by utilizing [blocktorch's search](/use-cases/searching) * **Identify Vulnerabilities**: Look for any vulnerabilities or errors that might have led to the issue. * Your smart contract code can be directly accessed in blocktorch's [contract details page](/concepts/data-sources/smart-contracts#smart-contract-details) * Blocktorch's [step debugger](/use-cases/debugging/step-debugger) can help you find the exact line of code causing the vulnerability or error * If your application is using Oracles and you believe the root cause could be there, you can check the Oracle's [out of the box details ](/concepts/data-sources/oracles#accessing-out-of-the-box-oracle-data) #### 5. Mitigation * **Patch and Update**: Apply necessary patches or updates to software to mitigate the vulnerability or error. * We are aware that this can be especially hard when the root cause lies within the smart contract, unless your project utilizes upgradable contract architecture * **Make aware your users**: If a security breach is confirmed, prompt users to not sign any malicious smart contract interactions #### 6. Recovery * **Restore Services**: Gradually restore services, ensuring they are fully sanitized and secure. * To test the services locally you can leverage blocktorch's [managed hardhat forks](/concepts/data-sources/local-forks/setup-managed-hardhat-fork) #### 7. Postmortem Analysis * **Analyze Causes**: Thoroughly document what happened, why it happened, and how it was resolved. * **Review Processes**: Evaluate and update security policies, response strategies, and monitoring techniques to prevent future incidents. #### 8. Ongoing Monitoring * **Continuous Monitoring**: Implement additional custom real-time [monitoring](/use-cases/monitoring) in blocktorch to detect future issues promptly * **Regular Audits**: Schedule regular security audits to ensure ongoing compliance and security. # Post mortem Writing a post-mortem is an essential process that follows the occurrence of a significant incident within a project or operation. It serves as a reflective analysis, aimed at understanding what went wrong, what was successful, and how similar incidents can be prevented or handled better in the future. Integrating data insights from **blocktorch** into a post-mortem can enhance the depth of the report. For instance, [monitoring](/use-cases/monitoring) data and visuals can pinpoint when and where the issue originated and metrics on performance degradation can illustrate the incident's impact. [Logs](/use-cases/searching/logs) and [traces](/use-cases/tracing) can support comprehension. By embedding such data, stakeholders can make informed decisions on corrective actions and strategic improvements, ensuring a comprehensive and insightful post-mortem. {% hint style="info" %} If you are interested in being a testing partner for us for a POC of automated post mortem generation through AI, please [let us know](mailto:contact@blocktorch.xyz). {% endhint %} # Predicting Coming soon....Blocktorch's prediction algorithms are WIP 🔮 {% hint style="info" %} We are currently working on POCs for prediction. If you are interested in starting a POC or becoming a design partner to have your hands on the **Blocktorch Fire Beetle Prediction** first and shape its roadmap please [let us know](mailto:contact@blocktorch.xyz) {% endhint %} **Blocktorch's Fire Beetle Prediction** will be key in improving observability, making web3 DevOps more efficient, and increasing threat detection. By using advanced analytics and machine learning, blocktorch's predictive models can guess future system issues, allowing teams to deal with them before they cause problems. Blocktorch's proprietary prediction helps you spot unusual behavior and track performance changes for a quicker reaction. Furthermore, the algorithms can predict workflow slowdowns and help manage resources better. Especially for threat detection blocktorch's prediction is a valuable , spotting possible security issues early, lowering the chances of breaches and allowing for early action. Adding prediction into these areas in your engineering workflows can boost productivity and strengthen system security. {% hint style="info" %} The black fire beetle is an insect, with sensor design with the ability to detect flames perhaps as far as 80 kilometres away. It can also hear the cracking of the wood and sense combustion products in very small amounts by using supersensitive receptors which are located in tiny pits on the beetle’s chest receptors. {% endhint %} # Demo videos ### Out of the box insights form the project home dashboard 👀 blocktorch’s home dashboard provides vast insights into all the data sources added to a blocktorch project. 🎁 The KPIs show performance, efficiency and health of the project without any setup requirements, they are provided fully out of the box. 👇Check out the video 👇 {% embed url="" %} ### Sharing the project home dashboard 👀 In web3 to trust is of utmost importance, and to communicate effectively with various stakeholders especially in times of incidents, the right information needs to be shared 🩻 The home dashboard of any project is shareable with communities, on socials, etc. through a simple link 👇Check out the video 👇 {% embed url="" %} ### Comparing projects against others to stay competitive 👀 For every dApp there are multiple alternatives users can choose from. To become the market leader the dApp needs to perform better and provider a better UX. 🥷 The home dashboard KPIs can be instantly compared to other leading dApps, giving the right insights to take data driven decisions on which areas to improve and choose the most competitive stack. 👇Check out the video 👇 {% embed url="" %} ### Invite your team members to have a common source of truth 👀 No matter if teams are working as part of organisations or DAOs, a common understanding of insights and data is necessary. Collaborating on building monitors ensures the best comprehension of the dApp 💌 Invite other users to collaborate into the project through email. They’ll receive a magic link to verify and join the project. 👇Check out the video 👇 {% embed url="" %} ### Creating powerful monitors to never miss important events 👀 Engineering teams in web3 need to monitor their stack to ensure the performance and reliability of their decentralized applications (dApps). Monitoring allows them to identify and resolve any issues or bottlenecks, optimize resource usage, and provide a seamless user experience. 🔬 In blocktorch teams can build unlimited amount of monitors for single functions up to monitoring across chains and data sources. Monitors can be filtered and grouped by specific variables. Targets ensure notifications whenever the monitor breaches the target 👇Check out the video 👇 {% embed url="" %} ### Powerfully search through system and smart contract logs 👀 finding the right logs for detailed information can be dreadful in today’s web3 world with various block explorers, custom indexers, and special API endpoints. One place to find the information reduced friction and powerful search enables to find the right info 🕵️ The blocktorch log manager allows to search logs across chains, across data sources with pre built filters as well as fuzzy search. Detailed informations about each log are provided as well. 👇Check out the video 👇 {% embed url="" %} ### Analyzing root causes for fast incident recovery 👀 In the case of incidents speed as well as accuracy matters. Really matters! ⛑ Blocktorch let users directly navigate from monitors that notified about spikes to the relevant logs of that time frame and the impacted systems. 👇Check out the video 👇 {% embed url="" %} ### Monitoring state variables with ease 👀 Monitoring state variables of smart contracts is a tricky task, however can be crucial. 🩺 Blocktorch’s monitor creating supports the depth of state variables with the same intuitive monitor creation as just monitoring transaction counts. No matter the depth and complexity of the data to be monitored, blocktorch makes it possible. 👇Check out the video 👇 {% embed url="" %} # FAQs Frequently asked questions
What is blocktorch? 🐲🔥Blocktorch as an end-to-end observability platform empowers engineering teams to **be more productive, take data-driven decisions, and scale dApps while ensuring a great user experience**. 🐲🔥\ \ Blocktorch provides powerful tools for exploring, analyzing, and visualizing data of decentralized applications. With features such as a query engine, log explorer, dashboards, monitors, and SLOs, Blocktorch enables users to gain valuable insights into their decentralized application.
What is observability? Observability is a key aspect of modern software systems that enables developers and operators to understand the internal state of a system by monitoring, analyzing, and visualizing its external outputs. This concept is particularly important for complex, distributed systems, where traditional monitoring approaches might not provide sufficient insights into the system's behavior and performance. Observability encompasses three main pillars: metrics, logs, and traces, which together provide a comprehensive view of the system's health, performance, and potential issues. By implementing effective observability practices, teams can proactively identify and address problems, optimize resource allocation, and improve the overall reliability and user experience of their software systems.
How do I get started with blocktorch? * Sign-up & log in [here](https://beta.blocktorch.xyz) * Done 🥳\ \ Check out our [Quickstart guide](/overview/quickstart)
Do I need to pay to use blocktorch? No, everyone can use blocktorch for free with certain usage limits. Pricing tiers can be found [here](https://www.blocktorch.xyz/pricing).\ If you are using blocktorch for free and want to give something back, we'd appreciate your feedback and to spread some love on socials like X, Farcaster and Hey ❤️
Is my dApps data private at blocktorch? The privacy of data within Blocktorch is treated with utmost care. **Publicly Accessible Data** For on-chain data accessed through the nodes of public blockchains, the information is publicly accessible. This includes data such as transaction details, contract addresses, and other information that is inherently public due to the nature of public blockchains. **Private Data in Blocktorch** However, Blocktorch also handles private data, such as off-chain data sources, user data, and privately uploaded data like private ABIs (Application Binary Interfaces). This private data is securely stored within Blocktorch and is accessible only to users who have been invited to the same project. Access to this data is restricted, ensuring that only authorized users can view and interact with it.
What are monitors and targets? Monitors in Blocktorch are used to track specific metrics or calculate Service Level Objectives (SLOs) based on the set targets. SLOs are performance and reliability targets that help you define and measure the quality of your blockchain ecosystem. By setting and monitoring SLOs, you can assess the health of your system and ensure that it meets the desired performance standards, enabling you to make informed decisions on improvements, resource allocation, and incident response.\ To learn more about monitors in blocktorch [see here](/use-cases/monitoring).
What are traces? Traces are a representation of the end-to-end execution path of a transaction or event within a distributed system, such as a blockchain network. They provide valuable insights into the performance, latency, and behavior of your system. Traces consist of two main components: end-to-end traces and stack traces.
#### End-to-end traces An end-to-end trace is a collection of spans, where each span represents a single operation or unit of work within the system. Spans are linked together by parent-child relationships, forming a hierarchical structure that captures the complete execution path of a transaction or event. In Blocktorch the starting point of the end-to-end trace is data from your [dApps frontend](/concepts/data-sources/react-frontends) which gets linked with the transaction data from the smart contract execution on the blockchain.\ \ **Stack Trace** A stack trace is a detailed representation of the execution path within a single function or method, such as a smart contract execution. It includes information about the function calls, line numbers, and any relevant error messages. Stack traces are particularly useful for debugging and diagnosing issues within your smart contracts, as they provide a comprehensive view of the execution path and any errors that may have occurred. In Blocktorch, you can view the full stack trace in the [Log Entry Details](/use-cases/searching/logs/log-details), which provides a complete breakdown of the smart contract execution
Can I have/be part of multiple projects? No. Currently a user can only be part of 1 project. To have multiple projects right now you will need to log in with different wallets or emails, or [reach out to us](mailto:contact@blocktorch.xyz). ATTENTION: if you have an exisiting project and join another project through an vit[Inviting others](/use-cases/collaborating/inviting-others) or by clicking a [shared search link](/use-cases/searching/sharing-search-results) you will leave your existing project and join the other project.
How can I share search results or visualisations with others? Search results can be shared by simply [sending your search's URL](/use-cases/searching/sharing-search-results) to the person you want to share it with.\ To make others see your visualisations/monitors invite them to your project. Invites can be sent by clicking the "+" in the navbar or going to your settings page. \ \ ATTENTION: when sharing your search URL the other person clicking the link will become part of your project. Only invite people/share with people that you trust and want to be part of your project.\ For the recipient: if your have an existing blocktorch project by joining another project (through clicking shared search link or following invitation) you will lose your existing project.
Can I use blocktorch with multiple blockchains? Yes, Blocktorch is designed to support multiple blockchains, allowing you to explore, analyze, and visualize data from various chains. To use Blocktorch with multiple blockchains, simply [add the smart contracts](/concepts/data-sources/smart-contracts/adding-smart-contracts) from the chains you would like to see the data from. \ Currently blocktorch supports the following [EVM Chains ](/concepts/data-sources/evm-chains)natively.
How can I see off-chain data in blocktorch? Currently supported off-chain data sources in blocktorch are [hardhat data](/concepts/data-sources/local-forks), [shadow data](/concepts/data-sources/custom-event-data), [IPFS](/concepts/data-sources/decentralized-datastorage) and [frontend data](/concepts/data-sources/react-frontends).\ [Let us know](mailto:contact@blocktorch.xyz) if you have specific off-chain data sources you need to be supported asap. \ Blocktorch utilizes [Open Telemetry](/concepts/telemetry), an open-source observability framework that allows for seamless integration with a variety of monitoring, tracing, and logging tools. If you are using any web2 observability tools and would like to connect it as a datasource to blocktorch please [reach out](mailto:contact@blocktorch.xyz).
Is blocktorch suitable for public and private blockchains? Blocktorch can be used with both public and private blockchains as well as [roll-ups](/concepts/data-sources/roll-ups), providing a comprehensive solution for analyzing and monitoring blockchain data regardless of the network type. For private blockchains, ensure that you have the appropriate permissions and access to the data. [Contact us to connect the private blockchain as data source to your blocktorch project](mailto:contact@blocktorch.xyz).
I am using web2 observability tools, is blocktorch compatible? Yes, Blocktorch is compatible with Web2 observability tools like Datadog, Dynatrace, Sentry, and Splunk. Blocktorch utilizes [Open Telemetry](/concepts/telemetry), an open-source observability framework that allows for seamless integration with a variety of monitoring, tracing, and logging tools. By leveraging Open Telemetry, Blocktorch can easily send data to your preferred observability platform, providing a unified view of both your blockchain and traditional web services. To integrate Blocktorch with your chosen observability tool [contact us](mailto:contact@blocktorch.xyz).
How can I contact the blocktorch team ? If you need support, have questions or to give us feedback feel free to reach out to us in the following channels: * [Email](mailto:contact@blocktorch.xyz) * [Discord](https://discord.com/invite/5PdvH58gbj) * [Twitter](https://twitter.com/blocktorch) * [LinkedIn](https://www.linkedin.com/company/blocktorch) * [Farcaster](https://warpcast.com/geryp)
# Open Source projects Blocktorch is committed to advancing the open-source ecosystem, particularly in the realm of web3 data engineering. If you are a developer you are warmly invited to contribute to the projects, which aim at enhancing accessibility and utility within the web3 data space. Currently, we have published two open-source projects: 1. **Decoder Service**: Designed to convert web3 data into formats that are easy for humans to read, this tool is crucial for developers working in blockchain data analysis and interpretation. [Repository](https://github.com/blocktorch-xyz/decoder) | [Blog Post](https://medium.com/@blocktorch/decoding-web3-data-into-human-readable-format-6804669b6db5) 2. **Batch Decoder**: This project focuses on tracing transactions between Layer 1 Blockchains and Optimistic rollups as Layer 2 solutions, addressing a critical need for better interaction and understanding of cross-layer transactions. [Repository](https://github.com/blocktorch-xyz/optimism-batch-decoder) | [NPM Package](https://www.npmjs.com/package/@blocktorch/optimism-batch-decoder) | [Blog Post](https://medium.com/@blocktorch/the-missing-link-between-l1-and-l2-transactions-on-optimism-b119f61d0464) Both projects are meant to help decode, make sense and work with blockchain data.