Skytale Finance Integration Grant Proposal

[skytale]

ICON Grant Proposal

Skytale platform

🔥 For the increasing number of companies adding digital assets to their treasuries, issues with administration, tracking, tax regulations, and scams provide significant headwinds to adoption. At Skytale we have developed a full-suite analytics platform allowing users to view all of their holdings in one place, prepare data for tax and accounting, automatically flag scams, manage liquidity pools and much more.

Skytale is a DeFi curated ledger to consolidate on-chain activities into one single view and to prevent fraud by flagging transactions and preparing critical data for tax reporting. With data aggregated from an extensive and expanding list of supported networks and protocols, Skytale enables anyone to make more informed decisions about their investments and to be alerted to potential scams in the DeFi and NFT space. Skytale services are available either via a browser dashboard or else via an API that allows you to build custom white-label solutions on top.

📣 **Skytale platform is live since November 2021, with 6k sign-up, and 39% of recurring users among 20+ networks. Our backers are protocols such as Balancer and mStable. We signed strategic partnerships with Lightnift, Router, Boring DAO, Unstoppable Domains, ENS and more.**

More in detail, Skytale:

• allows users to easily follow transactions and portfolios in their ecosystem across the already supported networks (Ethereum, NEAR, Solana, Polygon, Fantom, Arbitrum, RSK, BSC, Avalanche, Moonriver, etc.).
• enriches blockchain data with particular key information, such as manual and automatic tags on certain transactions, historical FIAT values and so on.
• offers the possibility to integrate with Discord and Slack through WebHooks: this allows the user to get notifications on every incoming or outgoing transaction.
• visualizes transaction flows in DEXs and dApps ecosystem for any project wanting to offer a more personalized transaction management option to their end-users.
• simplifies the accounting process allowing users to seamlessly export their transactions in a CSV file or import them into Quickbooks account. Users can cherry-pick the transactions they want to properly report taxes by sharing them with their accountant in a frictionless way.
• automatically identifies and filters scam tokens (and potential malicious attacks) protecting the end-users. Our classification engine, our flagship feature in development, will use machine learning to analyse and categorize smart contracts and their transactions. It will incorporate a traversable data structure, containing all the information about contracts. This structure will be able to respond to different queries and will provide data in different formats.

Competition Landscape

There are other players offering a tracking solution such as Zapper, Zerion and Debank. Also Cryptio and Gilded offer an accounting and bookkeeping tool. However, nobody has a combined solution able to offer an analytics tool together with an accounting and bookkeeping solution.

If we compare the value proposition of Skytale with Zapper, we notice that:

Feature	Skytale	Zapper	User journey
Transactions Filtering	wide range of filters (date, transaction types, network, wallet address, exchange, tag) to be combined together	It offers a generic search bar	Combined search by date range, transaction types and network
Transactions Tagging	add multiple standard or custom tags to any transactions and search by them	Not supported	Tag two transactions from different networks as “travel” and search by that
Transactions Drill down	explorer deep links regardless of the chain network of transaction, sender and receiver	Not supported	Get the explorer deep link of transactions, sender and receiver
Scam alert	filter out scam tokens automatically detected by a machine-learning classification engine👍🏿	Not supported	get informed if any scam token or malicious attack has been received
Webhooks	Don’t call us, we call you back. Configurable webhook area to get notified of any on-chain and off-chain activity👍🏿	Not supported	receive a notification on Discord or Slack channel about any incoming or outgoing transaction that happened in the last hour.
Quickbooks	Integrate with an already existing QBO account👍🏿	Not supported	cherry-pick your transactions to add them as journal entries to your bookkeeping tool and get your accountant updated.

The Asset Tracker Grant Proposal

We are glad to apply for a grant proposing our Asset Tracker allowing the users to manage their assets within ICON network.

🏃🏼‍♀️ As a hypothetical user journey, a user accesses Skytale.finance by sharing their metamask public wallet or their email, registers their wallets, tracks and tags their transactions, checks their balance and imports their transactions in Quickbooks in a frictionless way. On top of that, a user is able to transfer their tokens across any supported EVM network.

Economical proposal

Amount	Description
$20,000	Skytale platform is granted, including all the features described in the delivery plan below.

Delivery plan

We aim to deliver the following single milestone and ask for a grant according to the timeline below.

Milestone	Description	Notes	Grant tranches (USD)	Deliver
Integrate ICON Labs addresses and balance and history	Users can register their ICON wallet on Skytale, access their balance, and track transactions in history	Skytale allows users to track all their on-chain activities. Skytale allows users also to tag any transactions, add notes and export them on a spreadsheet or Quickbooks.	$20,000	30 to 45 working days from acceptance

Costs Breakdown

In order for Skytale to provide support to ICON in its own platform, a few costs must be considered:

Item	Description	Goal
Indexing	Skytale performs its own indexing in order to provide search functionalities. This indexing happens in two places: simplified indexing allowing a fast search for the wallet’s transactions, and detailed indexing allowing a deeper search into the wallet’s transactions. Our approach is either to query the public RPC URL or to run a in-house node. Alternatively we can consume the API offered by the Tracing. Besides the initial effort, Skytale will take care of integrating the mainnet once ready.	Create an index of public keys against transactions to retrieve any historical transaction belonging to a wallet, even if as a side effect. Create a searchable cache which allows to perform fast queries combining multiple filters.
Accuracy Monitoring and Testing	we configure our monitoring dashboard and alerting system to continuously check and notify if data are consistent and accurate. The roll-out phase involves also different testing either automatic or manual.	Get notified in case of stale or inconsistent data to allow the team to investigate further.
Storage	Skytale has storage costs for the wallet’s transactions, depending on the size of the wallets and on the frequency of the search, including devnet and mainnet data until devnet is dropped.	Get the necessary space to index any user’s ICON transactions from the genesis block.
Token classification	Skytale provides extra information about the tokens being shown to the user. To do so, Skytale built a token classification engine. Such information is retrieved from a curated catalogue, that needs to be fed manually based on our research and on the feedback received by the wallet’s owner.	Detect and isolate potential scams or malicious attacks. Ultimately inform properly the users and get continuous feedback through our communication channels.
Transaction classification	Skytale provides detailed information about the transaction, for example, the transfer happening in or out of the wallet for a given transaction and the nature of it. That information is continuously evolving and requires data about contracts and requests to be up to date in order to give the most accurate information to the user.	Enrich transactions with off-chain automatic data, such as labels, tags, historical FIAT value, and more.

What will be free to use and what sits behind a paid wall

Skytale offers a lifetime free Basic tier which allows the user to register for a free a wallet on a given chain, to:

• track up to 500 on-chain activities in the last 3 months
• users can tag any transactions
• EVM Chains have the same address, so one address could be used for all those chains.
• users will have to decide which address to use if non-evm

V2 further plans

Once the first grant is delivered, Skytale is willing to further support ICON in the future, by proposing a 2nd grant, to support liquidity pools e.g. Balanced by allowing the users in the Basic Tier (free) to:

• get APR / APY / Impermanent Loss
• Add liquidity
• Claim tokens

FAQs

What experience does the team have with non-EVM chains?
We have integrated multiple non-evm chains into the Skytale platform including Solana & Near

Does Skytale plan to open-source?
Skytale is a dashboard-as-a-service and its business model is SaaS. However, we aim to offer a hybrid solution in the future by open-sourcing two components:

• a js library, which handles the communication with DeFi protocols to easily get APR/APY from any liquidity pool and to add liquidity there.
• the classification engine to automatically detect any scam asset or malicious attack.

Why use Skytales indexer instead of the existing techniques via the community tracker?
Skytale uses two systems: one is a generic indexer that stores and indexes raw transactions to find the ones that involve a specific account, similar to what happens in a normal explorer; the second indexer generates transactions tailored to the account itself and allows a user to filter the transactions based on different aspects.

Skytale allows a user to tag transactions and add notes to them, and make these tags searchable. Our indexing allows users to search transactions by combining multiple filters.

Links

• Skytale platform
• Skytale website

[Ali]

Interesting! I think its a reasonable proposal and would be useful for tax filings

[bwhli]

1. Is the team aware that ICON is not an EVM chain? The proposal mentions MetaMask and EVM, so just making sure. If the team is aware, what is their process for onboarding onto the ICON chain? Who will they be working with to get up to speed? The proposed timeline feels unrealistic for a team who hasn’t built on ICON before.

2. Stuff like the transactions filtering has already been built by Sudoblock – the Tracker API is very complete and covers pretty much everything in the “indexing” section. If necessary, I’m sure the team could even get direct access to Sudoblock’s Postgres database to perform their own SQL queries. Alternatively, instead of devising a whole new API, developing a middleware to interact with the Tracker API’s endpoints feels like a better use of resources.

3. What’s the use case for transaction history exports if they don’t include stuff like LP/DEX support? In crypto, when people need support for taxes, it’s for DeFi stuff. So if none of that is included in V1, what’s the purpose of exporting transactions in a Quickbooks-compatible format? I’m asking because it’s very easy to query the Tracker API and output it as a CSV – I’ve done this myself with 2-3 hours of work. The real value is in the logic that processes stuff like DEX trades, LP, and more.

[errcsool]

I agree with these concerns.

I also want to share that I think it’s generally a great proposal. Full support for the Eye on ICON team, and I would be very happy to see the Skytale dApp in the ICON ecosystem

Some thoughts:

What is the benefit analysis of using the skytale indexing versus using existing indexing techniques via the icon community tracker?

Would your team look to integrate with OKX Wallet or Trust Wallet? Or the more ecosystem-specific Hana Wallet?

Is any of this open-source or planned to be? Are you looking to integrate with other dApps in the ecosystem or create collaborative components? I encourage as much development as possible to be open source and done with connection to other groups in the ecosystem

[skytale]

Hey bwhli, thanks for the thoughtful responses! We will address your questions one by one.

Is the team aware that ICON is not an EVM chain? The proposal mentions MetaMask and EVM, so just making sure. If the team is aware, what is their process for onboarding onto the ICON chain? Who will they be working with to get up to speed? The proposed timeline feels unrealistic for a team who hasn’t built on ICON before.

As mentioned in the proposal, we are open to exploring different ways to access the transactions, and, indeed, if such an index is available in the API, we will be more than glad to use it. Still, we will need to translate the transactions to our internal representation and extract the most valuable information from them. So this is something we’d have to further explore.

While it is true that we haven’t worked with ICON previously, we have integrated multiple other non-EVM networks, such as NEAR & Solana into our system. The timeline was created with a deep understanding of the work that needs to be done and we are confident in our capacity to fulfil said work within the timeframe stated.

We support Trust Wallet which is compatible with Wallet Connect so there’s no issue there.

Stuff like the transactions filtering has already been built by Sudoblock – the Tracker API is very complete and covers pretty much everything in the “indexing” section. If necessary, I’m sure the team could even get direct access to Sudoblock’s Postgres database to perform their own SQL queries. Alternatively, instead of devising a whole new API, developing a middleware to interact with the Tracker API’s endpoints feels like a better use of resources.

We are completely open to it. The tracker API is a good starting point for retrieving the transactions, but, as we mention above, we need to do our own indexing to make a transaction compatible with our search engine.

Having direct access to the database will be even better. We used the same for indexing NEAR transactions, allowing us to get a better view of a wallet’s history.

What’s the use case for transaction history exports if they don’t include stuff like LP/DEX support? In crypto, when people need support for taxes, it’s for DeFi stuff. So if none of that is included in V1, what’s the purpose of exporting transactions in a Quickbooks-compatible format? I’m asking because it’s very easy to query the Tracker API and output it as a CSV – I’ve done this myself with 2-3 hours of work. The real value is in the logic that processes stuff like DEX trades, LP, and more.

We agree that we can extract this information from an API, and we have done it in the past when a proper tracker was unavailable. On a personal note, we started trading in crypto back in 2016, and we created Skytale because we felt the pain of having to create and organise our own CSV from the CEX APIs. We feel that for Crypto to cross the chasm from innovators & early adopters to the more mainstream user, removing the friction of having to query APIs manually and instead using an intuitive search engine will be paramount, particularly as many non-technical users are unfamiliar with APIs and how they work.

As mentioned, the transaction details provided by Skytale are be enriched with information that will give a better scenario of your investment and fund movements.

Also, we do not provide a Quickbooks compatible CSV, we allow the transaction to be directly uploaded into QBO as a movement, with all the information belonging to it.

I hope this has answered your responses, thanks again for the thoughtful questions!

[skytale]

Hey errcsool,

We appreciate your kind feedback!

What is the benefit analysis of using the skytale indexing versus using existing indexing techniques via the icon community tracker?
Skytale uses two systems: one is a generic indexer that stores and indexes raw transactions to find the ones that involve a specific account, similar to what happens in a normal explorer; the second indexer generates transactions tailored to the account itself and allows a user to filter the transactions based on different aspects.

In a normal explorer, you will see all the facts about a transaction; in the Skytale index, we extract only the facts that directly involve your own wallet, with all the movements of funds, in and out, and possibly all the transfers in one direction or the other, occurred between your account and different actors. Also, classify the transaction regarding its behaviour, telling you what is happening.

On top of that, Skytale allows a user to tag transactions and add notes to them, and make these tags searchable. Our indexing allows users to search transactions by combining multiple filters.

Skytale is multi-chain and multi-wallet, and it offers a single view to show you all your transactions in any of your wallets and chain of choice, provided we have already integrated it.

This is what you see in a traditional tracker for a bridge transaction:

this is the same transaction in skytale tailored to the sender

The same transactions, as seen from the point of view of the receiver, will be described differently.

Would your team look to integrate with OKX Wallet or Trust Wallet? Or the more ecosystem-specific Hana Wallet?

We currently support WalletConnect, by extension that means Trust Wallet is supported. As for other wallet integrations, its something we’re always on the lookout for and will discuss internally! We’re in conversation with OKX currently so this is something we could potentially fast-track if the appetite is there.

I hope this answers all of your questions, thanks for the sharing your thoughts!

[skytale]

Thanks for the feedback Ali!

[robcxyz]

Hi @skytale - I manage the tracker APIs. Can you be more specific about “Our indexing allows users to search transactions by combining multiple filters”. Have you looked at the tracker’s API docs?

https://tracker.icon.community/api/v1/docs/

Which filters are you needing? It has many. It is also open source so if you need another filter, you can contribute that / request it. Basically all the data is indexed on a transaction level and so adding additional filters is trivial at this stage and generally something I would do if the request is reasonable since I built it and know how it works. But from what you are mentioning about being able to filter on to and from addresses, that is already there. Also on a token transfer level as well.

Also FYI - as @bwhli mentioned, it is not an EVM chain and so you don’t need to index traces to get token transfers. There is another index I will be supporting in the future around event logs by normalizing them based on contract ABIs but that I think is out of scope for what you are trying to do. Other than that, I don’t really know what additional indexes are needed but please, if you have a suggestion, would be very receptive to it.

[skytale]

Hi @robcxyz nice to meet you and to know you are in charge of the API. We will have more occasions to discuss our approaches and any possible add-ons to your index.

Hi @skytale - I manage the tracker APIs. Can you be more specific about “Our indexing allows users to search transactions by combining multiple filters”. Have you looked at the tracker’s API docs?

Which filters are you needing? It has many. It is also open source so if you need another filter, you can contribute that / request it. Basically all the data is indexed on a transaction level and so adding additional filters is trivial at this stage and generally something I would do if the request is reasonable since I built it and know how it works. But from what you are mentioning about being able to filter on to and from addresses, that is already there. Also on a token transfer level as well.

Our search engine performs its search across multiple chains. Our solution to search faster was to unify the searchable population in one search engine with an indexer that adds some extra data to the raw transactions.

As each chain has its transaction schema, we must use a common one based on the most relevant information; once we have the transaction from the relevant network, we convert it into our schema and store it in our database for searching.

While your API provides all the information needed to understand transactions in the context of the ICON network, we must still perform this step. Also, some fields do not come from the raw transaction itself but our system assigns them, such as tags, notes, transaction types, and reliability.

Below is the list of fields we use for the search now. We plan to extend this list.

Field	Description
Chain	Search transactions within a given chain
Wallet	Search transactions for a given wallet address and its chain
Tags	Search transactions with associated tags
Notes	Search inside notes attached to transactions (not yet implemented)
Transaction Type	Search transactions for type. Transaction type could be anything, and our classifier tries to give each transaction a proper classification, such as airdrop, send, receive, swap, trade and other
Time Range	Search transactions happened in a time interval
Hash	Search a transaction with a given hash. It could give multiple results if the transaction involves multiple wallets in the portfolio of a user (i.e. if I transfer funds between two of my own wallets, I will see the transaction twice: one classified as send, the other as receive)
Status	Search transactions either successful or failed
Shared	Search for transactions shared across multiple accounts. Our system allows users to share wallets (in read-only mode) within groups of users she/he belongs to. In this way, they can share any information they attach to a transaction (tags, notes and others)
Reliability	Search for the reliability of the transaction (experimental). Our system assigns a risk score to each transaction based on its behaviour or on the risk score of the tokens involved

Also FYI - as @bwhli mentioned, it is not an EVM chain and so you don’t need to index traces to get token transfers. There is another index I will be supporting in the future around event logs by normalizing them based on contract ABIs but that I think is out of scope for what you are trying to do. Other than that, I don’t really know what additional indexes are needed but please, if you have a suggestion, would be very receptive to it.

Having normalised logs will be very helpful, as it will make our job easier. Our system extracts information from these logs to provide the classification quoted above. The scope is to give any possible information to understand the scope and meaning of every single transaction.

Just to give an example: let’s say a customer owns account A; a simple swap is the combination of two transfers, from our account A to account B and the other way round; we need the logs within the transaction to understand in which context these transfers occurred and, more importantly, what these transfers mean to account A.

[robcxyz]

Hi @skytale - Thanks for the detailed response.

Before getting into specifics, at a high level, I think you don’t need a new indexer and just would want to scrape the existing one.

That being said, I do have additional questions.

• In your schema, you have a field wallet. Is this to and from with an additional record for each?
• What are tags? How are they supplied? Do you have a mechanism to do this automatically and what factors are you planning on bringing in?
• For notes, how are you planning on bringing this in? Is this some user supplied value?
• For transaction type - Is this just the Tx method? If it is an airdrop, how would you classify this?
• For shared - I sense that this is only something that is useful when someone engages with your platform and chooses to actually share their wallet. Is this correct?
• For reliability - Can you share any details about how this would be scored?

As for normalized logs, I don’t think this will be useful for you based on what you are describing. This gets into specifics of each contract and ends up being a big challenge of knowing what each field means for each contract. So probably just noise based on your prior response. It is a big challenge in ICON since ABIs can change over time. Otherwise, this would be trivial to normalize the logs based off of ABI.

[skytale]

Before getting into specifics, at a high level, I think you don’t need a new indexer and just would want to scrape the existing one.

We already have our index, and, for the reasons we mentioned previously, we want to have a single search point.

That being said, I do have additional questions.

• In your schema, you have a field wallet. Is this to and from with an additional record for each?

In our schema we define different wallets, or accounts, associated with a transaction:

1. the location wallet: this is our user’s wallet, which is involved in the transactions, directly or indirectly

2. the sender (from): this is the originator of the transaction or of a transfer within the transaction

3. the receiver (to): this is the destination of the transaction or of a transfer within the transaction

   the latest two can be or can be not another record in our database

   please, note that by wallet we mean either a contract account or a personal account

What are tags? How are they supplied? Do you have a mechanism to do this automatically and what factors are you planning on bringing in?

Tags are extra information added to the Skytale transaction by the user; users can select tags from a preloaded list or create their own; for the future, we are planning on a solution to assign tags to transactions in an automatic fashion

For notes, how are you planning on bringing this in? Is this some user supplied value?

In addition to tags, notes are generated by the user within the Skytale dashboard, but they are free text associated with transactions. Please consider that tags and notes persist in a different collection in the database, so we can recreate the transaction description at any time without losing the user’s interaction history.

For transaction type - Is this just the Tx method? If it is an airdrop, how would you classify this?

If available, we look at the Tx method, events and transfers happening into the transaction to determine a type for the transaction. Our classification algorithm is still a work in progress though.

For shared - I sense that this is only something that is useful when someone engages with your platform and chooses to actually share their wallet. Is this correct?

Correct. If individuals want to share information about a wallet with a wider audience without sharing the wallet itself, they can do so by sharing it in a group. This is particularly useful when sharing tags and notes. Currently, the other members of the group only have read permissions. At Skytale, we use this functionality to share information with our accountants, but other DAOs have requested it to share information across working groups.

For reliability - Can you share any details about how this would be scored?

We are working on a proper risk score engine for tokens and transactions based on ML and graph analysis. The current solution is based on a catalogue of malicious, suspicious or just annoying tokens (think about marketing tokens with no real values cluttering a wallet) that is updated continuously, and a simple algorithm extracting the most relevant fields of a token and assigning a risk score to each of them; if this score trespass a given threshold, the token is marked as suspicious and then we perform a manual check.

As for normalized logs, I don’t think this will be useful for you based on what you are describing. This gets into specifics of each contract and ends up being a big challenge of knowing what each field means for each contract. So probably just noise based on your prior response. It is a big challenge in ICON since ABIs can change over time. Otherwise, this would be trivial to normalize the logs based off of ABI.

This is something we will analyse and check the best solution to check the ICON logs and provide classification. Moreover, when discussing fields, we assume that a token must respect a given interface implementation (IRC2); any other fields outside the scope of the interface could be useful but not fundamental. While ABI may change, we expect that a particular contract fulfils the expected behaviour.

[errcsool]

The responses so far to community concerns have been pretty thorough, so I appreciate that

As this is appealing to the community funding pool, it is important to note that the current community priorities seem to be to fund crucial tooling and infrastructure. How does Skytale provide openly available tooling and infrastructure that benefits the ICON ecosystem?

From what you’re showing, there are a lot of different subsystems involved in the Skytale product. I’m sure some are better left private, but introducing or developing some as public, open tooling / systems would gain a lot of community favor

Additionally, we are prioritizing accountability and validation of development progress. This would be more involved than monthly progress reports, and would require a deeper form of engagement with the ICON community. This would be potentially going through case studies and focus groups on the product to provide further context on development status prior to community voting on progress approval. What are your thoughts on that?

[skytale]

At Skytale, we strongly believe in democratizing access to any public decentralized ledger. That is why we offer openly available tools to the ICON community, helping to alleviate the pain of:

1. aggregating balances by tokens. To accomplish this, it should take into account the various wallets where the assets are stored. It is important to ensure that all balances are properly accounted for and that the portfolio’s overall value is accurately reflected. Our tool provides valuable insights into the performance of individual tokens as well as the overall market trends;
2. protecting ICON users by identifying and filtering scam tokens and potential attacks. Our classification engine (in development) uses machine learning to analyze and categorize smart contracts and transactions. It includes a traversable data structure that links all the interactions between contracts. We hope the ICON community will support us in identifying new scam assets to enrich our knowledge base.
3. finding and managing historical transactions for personal or organizational accounting needs. Our tool makes it easier to track expenses and income over time, budget and plan for the future, allowing you to run reports to analyze spending habits and identify areas where you can cut back or invest more. Included in the lifelong basic subscription, users can enjoy the ability to track and manage up to 500 historical transactions. This means that users can easily seamlessly track their transaction history. Furthermore, our subscription offers the benefit of enriching users’ transactions with off-chain information. For instance, users can automatically view FIAT prices associated with their transactions and manually add tags to them.

We also believe that open-sourcing the following components will allow for greater collaboration with ICON community. In addition, it will make it easier for us to scale our infrastructure as we continue to grow. We are currently working on the open sourcing of two crucial components that make up our infrastructure and are willing to open any other tool that will come up during our journey:

1. a npmjs library that allows seamless communication with different DeFi protocols to easily obtain and interact with APR/APY and any information from any liquidity pool. The library artifact has already been distributed in a public repository, and soon the code base will be accessible to anyone on Github under an open-source license. The connector allows communication with several predefined protocols and AMMs, including Balancer, mStable, and RefFinance. Moreover, the library is open to any new integrations, such as Balanced or any ICON-powered pool provider.
2. A classification engine which is designed to detect any potential scam asset or malicious attack automatically. Currently, we are in the process of developing this engine to be something more than just a curated catalogue of scam tokens. Our ultimate goal is to create a dynamic system able to assess the risk associated with any transaction in real-time. The purpose is to produce a risk score based on a wide range of factors, as the nature of the assets being exchanged, the history of the wallets and transactions involved, and the current market conditions. We aim to ensure a safe and secure journey for the users and educate them on the danger of a scam. The ICON community is welcome to utilize our intermediate results and artifacts to experiment independently.

In order to ensure that we are making steady progress, we make it a point to establish milestones that will help us stay on track. At the same time, we also value the importance of remaining connected with the ICON community and would be more than happy to participate in regular focus groups where we can discuss our progress in detail, as well as learn more about the specific needs and preferences of the community. By sharing case studies and engaging in frequent calls with our users, we believe that we will gain valuable insights that will help us fine-tune our tool and make it even more effective and user-friendly than ever before.