If you’ve been following TrackTerra you’ll know that ive recently made TrackTerra opensource. Im happy to report the community has picked up the gauntlet , and a developer by the name of @rebaz_sabir (rebaz88 (Rebaz) · GitHub) has been working with me for the past 2-3 weeks making lots of improvements to the TrackTerra codebase to improve the sustainability and extensibility of the code.
This grant will fund Rebaz full-time for the next 1-2 months to continue with a massive overhaul of TrackTerra with features that will focus on making TrackTerra fully extensible to support future protocols and transaction types with little to no development effort.
My involvement in this project will be in the form of an unpaid advisory position where i will continue to advise and assist Rebaz from a technical and project management perspective. See the below proposal for more details and milestones.
Funds will be held in a multisig wallet held by myself and Rebaz.
We may come back with a follow up proposal that will fund infrastructure for TrackTerra that would include hosting our own FCD node . Ideally we’d prefer contracting out FCD hosting to a service provider such as QuickNode when such services become available.
As you might already know TrackTerra is a tax and reporting application. It is build to ease the process of transforming the blocks/transactions data into a single transaction form exportable in to popular tax reporting softwares. It currently supports native send/recieve, anchor, mirror(partially), pylon(partialy) and terraswap protocols.
TrackTerra – a tax focused blockchain explorer for Terra
TrackTerra parses transactions from terra wallets in to a format that can easily be imported in to popular crypto tax software.
Removes the complexity and barrier to entry around reporting requirements for transactions in the terra ecosystem
The app uses nodejs and has it’s own database backend where it stored parsed transactions. Our MVP is mostly functional and can be demoed at beta.trackterra.org. Active development can be viewed here
The target end users are users of the terra ecosystem that have any sort of tax reporting requirement, and crypto tax softwares that will either adopt our codebase or use our APIs. Crypto tax reporting is a major burden for crypto investors and this solution aims to solve this for the terra ecosystem.
There is one competitor to trackterra which is stake.tax, however this solution is nearly unusable and doesn’t have support for many terra transactions. This solution is also not opensource. TrackTerra aims to build a solution that can easily be extended with little development effort that is also fully opensource.
Total Costs: $42,680 (38,800 + 3880) converted in to luna based on market value at the time of proposal , 10% ($3880) is added to the total cost to cover any price variance during the voting period.
Milestone 1 — Add support for dynamically adding new protocols
Estimated duration: 40 working days
Costs: 22,400 USD
Generic Classifier & Parser
- Create a scrapper to go through each protocols transactions and store them in a database for later use
Classify the transactions Manually/Automatically and add support for each transaction type in the current version
Write test for each transaction type for each protocol.
Develop a generic classifier that is able to classify all types of the transaction for each protocol.
Write test for the generic classifier.
Add parser for some of the transactions that are not parsed by the current parser.
Write test for each parser.
Develop a generic parser that is able to parse all the transaction types for each protocol.
Write test for the generic parser.|
|2|Add ui for managing protocols & transaction types|- Add ability to add rules for each protocol/transaction type through ui.
Write unit and e2e test for adding rules through ui
Protect ui to allow only authenticated users to add protocols/transaction types.|
|3|Supporting protocols|Minimal Support: Anchor, Mirror, Terraswap, Nexus, Valkyre, Mars, Astroport, Loop, Spectrum, Apollo|
Milestone 2 — Add support for tax software
Estimated Duration: 5 working days
Costs: 3,200 USD
Export data to a format readable by Koinly , Cointracker
- Users will be able to filter the transaction by date, transaction type.
- Users will be able to export the data to three supported third-pary apps based on their filter.
Milestone 3 — Add support for REST and GraphQL
Estimated Duration: 5 working days
Costs: 3,200 USD
This will allow interacting with the application for third-party apps
Retrieve and filter data by Wallet address, Transaction type, Transaction date
Maintenance and Upkeep
Costs: 10000 USD
These funds will be held in the multisig and deployed to cover the costs for any upkeep or maintenance. If we do not get to our stretch goal of implementing NFT marketplace support we will tap in to upkeep fund to cover those development costs. This maintenance fund will also cover hosting the app (excluding FCD)
This is much needed and will benefit all of us. Everytime I make a transaction on Terra, I have a little sense of dread because I know I’m going to have to go back and reconcile all of this stuff at year end. I hope Koinly is one of the app formats chosen.
Koinly support will come first. Beta.trackterra.org already supports koinly. But because koinly doesnt support some tokens a workaround of placeholder tokens needs to be implemented where unknow tokens are replaced with NULL01, NULL02, etc place holders (really annoying , i know) This is not currently available in the beta but will be covered in this proposal .
Hey everyone! This is KashRon with the Intellabridge team. I just want to give my full, 100% support for this proposal. I’ve been looking for an accounting solution that could compliment Kash DeFi for several months now and this would slot in so perfectly with what we’re looking for. Since Kash is providing fiat on-ramps to the terra ecosystem (bank wires, ach, iban, debit cards) we will need accounting solutions to help comply with local government tax reporting requirements. Papi is a true treasure in the Terra community and this tool would solve an immense pain point.
I’m more than happy to be a reference for both this project and Papi as a human being, [email protected]. These projects are as much about believing in the people as the concept, and knowing Papi has given me complete confidence in putting my reputation on the line to support any initiative of his.
Okay, selfishly I want Kash to try this out as well
Also agree. At Bidali, we’re integrating UST and Terra for spending and on/off ramping too. While we have some internal tooling for taxes and reporting on our own system, tracking transactions on-chain is still a bit of a pain. For ~$50k, if it works there is significant value that can benefit the entire community from individuals to businesses to protocols.
If terra luna is to be used by all, it is necessary that the accounting of transactions to pay taxes in accordance with the law. This is probably the most important feature needed for terra luna to be used easily by everyone.
This is a given. UST will be held in a multisig wallet held by myself and Rebaz.
The only thing missing here is support for NFT marketplaces. Tracking transactions made by a given wallet is fairly straight forward however when transactions are made from a contract on behalf of a wallet tracking such transactions for tax purposes gets quite complex. Mainly because you cant query a wallet for such transactions and rather need to query parse and index transactions from a given contract. Ive discussed this with Rebaz and we have this on the list as a stretch goal , however it’s not something were going to commit to as part of this proposal . I havnt looked in to it but it should be similar to dealing with mirror CDP , limit orders ,and anchor liquidations. If it’s more complex than that we’ll probably come back with a follow up proposal once weve met these milestones.
With the said we are designing trackterra to be generic and extensible where if a protocol isnt already supported via the generic parsers it will be easy to create rule based parsers in the web gui to add support for new protocols.
It’s not so much about priortizing one protocol over the other. The focus is on building generic and extensible parsers that work on all transactions. I see two differentiatiors ,transactions executed by a given wallet ( ie 99% of transactions) and transactions executed on behalf of a wallet within a contract (ie liquidations, marketplaces , etc) . The take away here is that were not focusing on any particular protocol but we will be spending quite a bit of time ensuring that our generic parses work for the protocols listed.