Cristian Strat on Warpcast

Content pfp

0 reply

0 recast

0 reaction

ChristianØ pfp

Crypto taxes suck. But it's a data problem, not a tax calculation problem. Few people know this. And even fewer are trying to fix it.

2 replies

0 recast

9 reactions

Mark Hilgenberg pfp

Mark Hilgenberg

I use token tax and they do a great job with the data. Over 20,000 transactions one year with LPs, staking, cross chains etc.

1 reply

0 recast

1 reaction

ChristianØ pfp

I've tried token tax a bunch of times and they always seem to get something wrong. Tx classifications or missing data, something is always wrong.

1 reply

0 recast

0 reaction

Mark Hilgenberg pfp

Mark Hilgenberg

If you are just doing the basic ya, I use the VIP and some years above that.

1 reply

0 recast

1 reaction

ChristianØ pfp

Not basic, used Pro. Vip the only difference is that I get consultations and they will manually sift through the data for me. But the data was still wrong to begin with, in their systems.

1 reply

0 recast

0 reaction

Mark Hilgenberg pfp

Mark Hilgenberg

Hmm, not sure what would cause that. They draw from blockchains and CEXs. The only issues I found was with very old BTC.

1 reply

0 recast

1 reaction

ChristianØ pfp

CEXs are usually easy, that's just swaps and staking and really just simple stuff. The problem with getting the data from the chain is usually that the source they retrieve that data from can provide all or only some of the data needed to get an accurate picture of the transaction history, on that chain, on that specific account. That doesn't even cover the other hard part yet which is the categorization of each transaction and account reconciliation. Now repeat that across 10-15 chains or more, and something always ends up wrong. Always.

1 reply

0 recast

0 reaction

Mark Hilgenberg pfp

Mark Hilgenberg

If you have that complex of stuff, you need the VIP. I was doing LPs on Osmosis Zone in 2021, so that is how I found them, no one could handle the Cosmos eco.

1 reply

0 recast

1 reaction

ChristianØ pfp

Vip still doesn't solve their data problems though. Again it just hires their team to do manual work. Yeah cosmos stuff is a nightmare, we get a lot of requests there.

1 reply

0 recast

0 reaction

Mark Hilgenberg pfp

Mark Hilgenberg

I guess I would need to see a data problem issue to understand your issue. I worked with their team to solve all my issues.

1 reply

0 recast

1 reaction

ChristianØ pfp

Ok, bear with me here... First, by default, nodes from most data infra providers do not typically come with trace turned on, it's not common. Which is essential to get a 100% accurate report of a transaction, and essential for wallet reconciliation. Tokentax is not running it's own nodes (especially not trace nodes) on every chain they support. High volume, heavy compute loads, the possibility of this being the case is basically zero. (even less common for the chains that are further and further away from mainnet e.g. Degen) In a transaction like the example in the second image, the transaction on the explorer displays inaccurate information (which is what tokentax displays) because it doesn't immediately pull all the internal txns, assuming it already has all the data it needs to accurately report. Problem is, that initial glance of the transaction (the data pulled into tokentax) is missing vital information about the transaction itself, and without it, the gain/loss and tx classification is wrong.

2 replies

0 recast

1 reaction

ChristianØ pfp

I'm barrrrreely scratching the surface here. This is one transaction on one protocol on one EVM. Data structures are different on cosmos vs. move vs. solana vs. evm. This is a large scale data infra problem that they're trying to solve as a tax software company, it's just not gonna happen.

2 replies

0 recast

0 reaction

Cristian Strat pfp

Not sure I get this example. Most/all AMM contracts emit decently detailed events. Those plus the ERC20 events should suffice for most AMM transactions, no? If there’s a really wonky tx they can trace that with a hosted node provider. No?

2 replies

0 recast

2 reactions

ChristianØ pfp

Yeah, maybe. But either way, the information displayed on the explorer as well as in token tax was/is incorrect. Happens all the time. Somewhere along the line, they miss something and their data is incomplete. Retrieving raw data, trying to DIY the processing and enrichment, and then consuming that data - it's too much, too complex. Tokentax, koinly, crypto tax whatever, they're always getting something wrong on any given chain.

1 reply

0 recast

0 reaction

Cristian Strat pfp

Can you link to an explorer showing incorrect data? I understand it can be unparsed or insufficiently enriched but not sure what you mean by explorer being incorrect. TokenTax/similar being incorrect - that is easy to see of course, no examples needed.

1 reply

0 recast

1 reaction

Cristian Strat pfp

I agree with the “data problem” point in general, though perhaps in a slightly different way. Tx parsing and enrichment is a core competency needed, but I see 90% of the challenge being primarily in the tax/accounting domain logic - countless cases where you must infer the accounting/tax semantics given ideal full onchain information including traces and whatnot, and only 10% is general low-level onchain infrastructure of the sort you can buy from Alchemy/similar.

1 reply

0 recast

1 reaction

Cristian Strat pfp

So it’s a data problem, but more specifically data interpretation in the domain of accounting and tax. Somewhat related, it would be really useful to have some standards or at least a shared repository of inferences of tax/accounting properties from common transaction types. Make this parsing consistent across tax products.

2 replies

0 recast

2 reactions

ChristianØ pfp

1. https://warpcast.com/christian/0xfefb1a5f The routescan team has since made a manual fix on this tx, now extracting the correct function from the multicall which is "swap" not "withdraw". 2. https://explorer.degen.tips/tx/0xb2e6e31eac3be84268534b3be1519a53994b7001f0296d3640ef0be66324bdf9 This is the tx where again without also pulling internal txs, the tx leads you to believe the 1476 wdegen is burned instead of claimed. You can see the corrected, Noves data at the top as a summary of what the tx actually did. 3. Dymension A top 5 crypto tax company came to us because they could not access some cosmos chains data. Base infra was so slow that a predictable service was not possible. e.g. RPC regularly times out at 60 seconds asking for the most recent 10 tx sent by some* accounts. Our fix: https://docs.noves.fi/reference/post_cosmos-chain-job-start And yes, then the next step is the accurate classification of the transaction so that the tax software can determine taxable/not taxable.

0 reply

0 recast

1 reaction

ChristianØ pfp

Incomplete is a more accurate word than incorrect I suppose. I'll drop the tx here in a minute. But it is both the accessing of the data across multiple chains and ecosystems that's an issue, getting 100% of the data to be 100% accurate in reporting. And it's also the classification of the transaction.

0 reply

0 recast

1 reaction