Trackterra V2- Request for Feedback

Blockchain
1

Greetings my fellow Terraists . It’s long overdue , however i’d like to give you all an update on my plans for Trackterra V2(trackterra.org) . This project has been moving slowly as of late as im currently designing a major rewrite that will improve functionality and supportability moving forward.

Right now the biggest struggle is that trackterra was written as such to rely on mirror graphql for most of its data as parsing transaction logs is quite cumbersome and can take quite a bit to get working right.

However this comes with two major flaws, it doesnt parse or reparse transactions on demand and this can result in some transactions sporadically missing(i think this issue is related to the spam attack in march?), but more importantly the graphql transaction parser doesn’t start “watching” an address until it interacts with the mirror contracts.

So this means if you used terraswap or other terra native functions prior to ever using mirror, trackterra would not know about these transactions as the graphql api doesn’t return them .

So in order to fix this transactions need to be parsed directly by trackterra when processing a report. In order to do this i will be porting the trackterra report generation code to nodejs , and i will be stealing some code from mirror-graph/src/collector at master · Mirror-Protocol/mirror-graph · GitHub in order to implement a transaction parser. I will also be building this out to include anchor and terra native support.

This is currently in the works , and i will actually be bringing on some extra development resources to help get this done. Estimated timeline just now is July/august.

TrackTerra v2 is expected to include

Anchor Support
UST/aUST swaps
Luna/bLuna swaps/mints/burns
ANC reward claiming
bLuna delegation rewards
Provide/Withdraw Collateral
Liquidations

Mirror v1 and V2 support
Support for long and short staking positions
CDP minting and burning
More details to come

Misc
Proper tracking of shuttle fees
Native swap support Luna/UST minting
Fee aggregation
Delegations/undelegations

Slashing? (anyone have any tx examples of this?)
Delegation rewards (any tips on the best way to track these?)

And for anything missing here i would love to hear from the community as to what you would like to see.

I would like to get some feedback on monetization , i see a few approaches that can be taken here . But in order to keep up with the growth of the terra ecosystem some method of monetization needs to be implemented.

In general upkeep consist of the following

  • Hosting costs are about 750 - 1500$ per year, includes hosting a full node

  • Im going to roughly estimate about 60-80 hours of effort to support a new protocol over the course of a year. An additional 20 hours allocated to support and bug fixes over the course of the first year. And after the first year unless there are any major protocol updates need for support should be minimal.

So as far as monetization , id ideally like to recoup some of the development costs , but at minimum i’d like to recoup the yearly hosting costs .

Since v2 on its own is going to support 3 different apps on terra, should my community spend proposal be split up between different platforms?

I expect costs for all three integrations and hosting for the next 3 years will be between 10k - 15k . Would the community support reimbursing these costs via the respective DAOs? In return the codebase will be made opensource and i will host trackterra for 3 years. After 3 years i will ask the DAO to fund another 3 years of hosting.

In order to support additional projects , either the respective project can update the trackterra parser, or they can fund a grant in the 5k - 10k range depending on complexity and we will take on development.

The alternative approach would be to implement an approach similar to astro tools , where you would need to hold a trackterra token in order to use the platform or the full version of the platform. With this approach it’s not in our best interest to be open source. I feel being 100% DAO funded is the way to go. But if you think otherwise, would love to hear your feedback.

4 Likes
2

I am very excited for this to be built. thanks for doing this. I have already made a significant financial donation and hope others do too. Also the project treasury should contribute as this is valuable to the ecosystem!

1 Like
3

Think this would be popular as a community pool grant proposal.

One thought: as new contracts come live on the Terra blockchain, can you think of a way to scale trackterra without having to write custom indexers for each dapp?

Perhaps a graph protocol model where devs are incentivised to write subgraphs?

5 Likes
4

I think the service is very important and would like to see it community funded.

5

Papi I think we already voted for you in the feature wish box. And oh look another one incoming.

A community grant and/or setting something up on pylon(if possible and when ready) would certainly get backing. Subscription stream on Pylon for monetization?

Something like Do says with a terran graph would be great to see also. This seems like a separate project than trackterra though. Looking ahead this could be an additional community grant to collaborate with graph guys/bring it over? I’m all for it.

1 Like
6

Good question. I suspect you could apply a generic parser to most transactions . But this will be a bit of a nightmare as your generic parsers will need to filter out transactions that could be misclassified. For example if your generic parser was looking at token flow IE if a wallet sends one token and receives another you could speculate a swap transaction is a swap, CDP , or aUST transaction . One idea here is you could have generic parsers , but instead of letting the parsers just work for new contracts , for each new contract you would require someone to submit an ABI (or as an alternative a list of contract functions ) and classify each write function with a generic parser IE native swap, swap,pool deposit, pool withdrawal, CDP, airdrop (rewards), or an “ignore” option. I think this would be the only way generic parsers would work well and you could avoid all of the one offs and keep them pure . Unclassified transactions would be returned in a separate report and end users could then (if they want or need to) assist in the function classification process. This might require a bit of upfront work, but it would make onboarding new contracts easy . I dont think that contract classification should be wide open but we would aim to implement some sort of support help desk where users could submit changes and they would need to be approved before implementation .

On implementing this in graphql , it makes sense, data standardization is the biggest challenge in parsing terra transactions for tax reports and graphql solves this .

Although i dont think it makes sense to store trackterra after processing data in graphql as this data could vary between different tax report generation software, and i think the goal here should be that graphql contains standardized and clean data . For koinly LP in and out transactions transactions are split in to two “swap” transactions where underlying asset are swaped for LP and vice versa. And currently Koinly does not support terraswap lp tokens so we use placeholders as a workaround (NULL1, NULL2, …) and store an index of token name placeholders and the actual lp token name so that generated reports are consistent.

Edit: i suppose the clean data and koinly specific data could be separated and stored in different tables. We’ll also need to query and store liquidation data for mirror and anchor , and i think people would find it useful to have a graphql endpoint to query this from.

As an ultimate goal we would index the entire blockchain in to graphql :sweat_smile: but the feasibility of this is questionable as reparsing transactions when function lookups are changed or added would be a complete nightmare. This would be a bit more feasible after the trackterra parser has time to mature and become mostly reliable. You would still have the problem of the delta period of when a new contract is deployed and when the contract function lookup is submitted and you could fix that by simply asking for a block number when function lookups are submitted. Then the parser would reparse all uncategorized transactions from that block. For reparsing incorrect function lookup tables you could address this by reparsing transactions from block where contract address = x.

For launch i think we should focus on implementing an interface that will reparse a wallet on report generation, with an option to trigger this via authenticated API as well . That way graphql is kinda useful for non trackterra stuff in the interim . Parsing the entire blockchain is a major undertaking of it’s own.

2 Likes
7

Development is proceeding a bit faster than anticipated, no updated timelines just yet, but stay tuned.

So far here is a list of supported transactions types . Excluding mirror v2, anything missing here?

Transaction types

Anchor

anchorMintAust
anchorRedeemAust
Luna/bluna mint and burn (excludes “instant” transactions that are parsed via terraswap parser)
anchorBlunaMint
anchorBlunaBurn (Can someone send me a tx where you claim your bluna after 21 days, otherwise im gonna need to wait 21 days, or implement this in such a way that the “swap” occurred the day the claim is initiated)
anchorProvideColateral
anchorRemoveColateral
anchorBorrow
anchorRepay
anchorLpRewards
anchorBorrowRewards
anchorBlunaRewards
anchorStakeLp – ignore for tax report
anchorUnstakeLp – ignore for tax report

Terraswap

tsLpAdd
tsLpRemove
tsSwap

Mirror

mirrorCdp
mirrorGovPool
mirrorStakeLp – ignore for tax report
mirrorUnstakeLp – ignore for tax report
mirrorClaimRewards
mirrorCreatePool
mirrorLiquidated
mirrorLiquidate

Native
nativeSend
nativeReceive
nativeSwap
nativeStakingRewards
nativeDelegate
CW20 Send
CW20 Receive
Shuttle

2 Likes
8

This project is a great idea. I’m in the process of doing my tax returns and its very time consuming doing this manually.

Any idea when the trackterra website will be operational? I’ve tried using it for my terra address, but it still says “report is processing” about 4 days later.

Anyone know any alternate ways or websites to easily extract a spreadsheet of all your terra transactions?

9

Try again. Aware of the issue here but im not going to implement a fix for v1. For now i will add a small mitigation.

10

Hi, Yes it works now thank you. I’ll have to wait until you release the new version however, as I noticed it only displays records for deposits. For it to be useful for tax reporting purposes, it would need to display records for claiming staking rewards and also any swaps from anc or mir to luna and vice versa.

Any idea when your new version will be released? I’m based in the UK and our tax reports have to be completed very shortly. So I don’t think this will be working in time.

Does anyone know any similar other solutions? Its frustrating that Terra or Terra Station doesn’t have something similar built in.

Thanks

11

It supports mirror v1 pretty well for this purpose , it also supports terraswap pools via the mirror graphql api which does have some limitations. This was originally developed to help me with my 2020 tax calculations , and the ecosystem has been exploding in growth since it was launched.

As you can see above, trackterra v2 is going to support a much more exhaustive list of transaction types , with considerations to support new protocols moving forward.

In the meantime you can get your transactions from the block explorer and transpose them to CSV
https://finder.extraterrestrial.money. The mirror website also supports exporting a CSV, but will likely need to be reformatted for koinly purposes.

V2 will be launched in about 5-6 weeks, perhaps earlier , but im not commiting to an earlier timeline just now.

1 Like
12

Hi there, I also would like to see something for taxes for terra. Do you need any help? I’m also a developer and could contribute. Thanks

13

Also grateful and excited for this!

14

phenomenal work!

15

We actually did end up doing this - check out github.com/terra-project/mantle

4 Likes
16

@dokwon and @cephii1 There already was a proposal in April for this, which was approved (proposal 76). Not sure how we even find out what happened with it (was it actioned?), as I haven’t really been in the game long.
The best I’ve seen so far in this area though is the stake.tax site, does a pretty damn good job. Few things missing though which would be essential for tax calculations, like price per unit at transaction time.
Anyway, really hope to see some progress on this soon.

17

The proposal your referring to is not related to this initiative. I applaud the efforts of the stake.tax guys, but it looks to suffer from the same problems the initial version trackterra dealt with. It uses graphql to retrieve it’s data which has some limitations .

A release date will come towards the end of the month.

18

Also, for anyone using v1 we were parsing some native transactions (native sends) , but it looks like there was a change to FCD where getting a list of transactions is now a bit different (before it was paganted, now it’s offset by a block #) . Not everyone will be affected by this. This wont be fixed in v1. If it’s a problem, wait for v2.

19

For anyone waiting for this to do their taxes for $luna, I have found the following website which seems to work well : https://stake.tax

20

So i’ve built a generic parser that can handle single input, single output, or single input and single output transactions. So this means that when a new project comes online the only thing that needs to be done is to build a classifier for the type of transaction and even that is not required. This allows for rewards claims to be classified as staking rewards and swaps to be classified as swaps . It allows for nice labeling and depending on the transaction intent it could be taxed a bit differently.

For more complex transactions like the auto_stake transactions on mirror v2 these almost have to have custom parsers . For these i will be breaking down the transaction in to multiple transactions based on the actions performed by auto stake as this is better for claiming losses on LP , i dont think it makes a difference for short farms.

But generally speaking most transactions are single input output transactions , so im thinking scaling will be a non issue.

Expect to have an update next week.