Bitpanda staking transactions unknown

[wullxz]

Bitpanda has an unknown transaction type for staking: "transfer(stake)" that comes with an accompanying opposite "transfer" transaction.

There has been in issue about staking and a discussion about order and categorization for speculation periods in #57 (which in turn mentions #4) but since I stumbled upon this project today, I'm not familiar with the implementation yet.

Since my coin is still staked and I haven't unstaked until now, I'm going to ignore these transactions for me for now to prepare my tax documents. I'm still interested in the topic and also would look into properly implementing this or at least help with the implementation.

For starters, here are two example transactions for a stake operation (with the amounts anonymized) for bitpanda:

"Transaction ID",Timestamp,"Transaction Type",In/Out,"Amount Fiat",Fiat,"Amount Asset",Asset,"Asset market price","Asset market price currency","Asset class","Product ID",Fee,"Fee asset",Spread,"Spread
Currency"
1edfe6e2-4a5c-6ed8-8be4-fa2a24845dbd,2023-05-30T00:14:13+02:00,transfer,outgoing,123.00,EUR,0.1231231234,ETH,1768.59,EUR,Cryptocurrency,5,-,-,-,-
1edfe6e2-4900-67b0-c78f-e95654e42b18,2023-05-30T00:14:13+02:00,transfer(stake),incoming,123.00,EUR,0.1231231234,ETH,1768.58,EUR,Cryptocurrency,5,-,-,-,-

Edit: There is an other transaction type that's apparently not yet supported: "reward" for staking rewards.

1ecec206-097a-6efe-99b6-7edf230be237,2022-06-14T22:27:14+02:00,reward,incoming,0.02,EUR,0.03473994,ADA,0.58,EUR,Cryptocurrency,22,-,-,-,-

[provinzio]

What are the column headers of your example?

[wullxz]

@provinzio sorry, updated them in my initial comment!

[provinzio]

Dou you now for what the two lines are for? You mentioned that your coins are still staked. Sounds to me like some internal bitpanda stuff which might not be an taxable transaction.

[wullxz]

Yes, it's the transaction of staking my owned supply of ETH. I know it's not taxable but it might still be of interest when calculating the "Spekulationsfrist". In the linked discussion, it was said that staked coins could be handled in a different account or something similar to make it clear which coin is getting sold if there is a sell transaction afterwards (since there was some trouble identifying the correct start of the new one year speculation deadline).

I also just included the "reward" transaction that's also not yet understood by this project. In my case, the reward is staking reward. AFAIK, staking rewards are taxable but are they really when I receive them as crypto (as is normal for staking rewards)?

[wullxz]

Should I open a new issue about the staking rewards? I will also run into staking rewards when CoinTaxman was able to ingest my bitpanda statements because my coinbase statements will also have staking rewards in them. Or is there already a way to process these? I might be able to create a patch if the handling of staking rewards has already been done for other exchanges (by looking up and copying the behavior from the code for other exchanges).

[provinzio]

Yes, it's the transaction of staking my owned supply of ETH

In that case. The transaction should be recognized as Staking. But why are there two lines in the CSV? Is the other one for unstacking the coin? If that's the case, it should be recognized as StakingEnd.

In the linked discussion, it was said that staked coins could be handled in a different account or something similar to make it clear which coin is getting sold if there is a sell transaction afterwards

As of now, staking does not change the buy/sell order.

You can checkout taxman.py::_evaluate_taxation_GERMANY for more information on how each transaction type is handled.

also just included the "reward" transaction that's also not yet understood by this project. In my case, the reward is staking reward.

That should be recognized as StakingInterest.
What makes me nervous, is that the bitpanda transaction type is named reward. How can we be sure, that this comes from staking and is not some other reward?

Should I open a new issue about the staking rewards?

As far as I can see, this can all be handled in this issue.

---

Have a look at book.py. the error code should already hint you the correct place to look. In book.py is a reader function for bitpanda in which the transactions are mapped to our internal transaction types. Feel free to checkout the binance read function as a reference.

[wullxz]

In that case. The transaction should be recognized as Staking. But why are there two lines in the CSV? Is the other one for unstacking the coin? If that's the case, it should be recognized as StakingEnd.

The first transaction is basically the one that substracts the staked amount from the "normal" wallet and the second transaction adds the staked amount to the staking wallet (assuming they are two separate wallets and in absence of a better word). It's like in accounting where you always have two booking statements between accounts.

As of now, staking does not change the buy/sell order.

You mean the start of the Spekulationsfrist for the staked coin is untouched by staking?

That should be recognized as StakingInterest. What makes me nervous, is that the bitpanda transaction type is named reward. How can we be sure, that this comes from staking and is not some other reward?

Yea, I also stumbled over this. I only assumed it was a staking reward because immediately before that I staked the coin in question. I think though, that in case of bitpanda, rewards can generally be treated as staking interest unless it's rewards in BEST coin, which is their internal coin. You receive BEST for transactions on bitpanda (which are also taxable, right?).

Have a look at book.py. the error code should already hint you the correct place to look. In book.py is a reader function for bitpanda in which the transactions are mapped to our internal transaction types. Feel free to checkout the binance read function as a reference.

I'm looking through book.py already but I'll check the binance code next. Thanks for the hint.

[wullxz]

I checked the bitpanda statements again for the BEST rewards. They are actually booked as "transfer", which is currently ignored (but probably shouldn't be ignored?).

Example:

1ee10b0c-fdd7-602c-9fb9-de3f2c51db25,2023-06-22T05:56:54+02:00,transfer,incoming,1.07,EUR,2.94025794,BEST,0.36,EUR,Cryptocurrency,33,-,-,-,-

Edit: BEST rewards themselves can be ignored since using a service (i.e. the platform bitpanda) is not an action. Therefore, the BEST reward for using their service is not taxable. Selling the BEST on the other hand is a normal sell operation.

"„Die reine Nutzung einer Plattform sollte zu keinem steuerbaren Airdrop führen, und zwar aus folgendem Grund: Die bloße Verwendung einer Plattform ist kein ‘aktives Tun’ im Sinne eines Gegenleistungscharakters. Vielmehr handelt es sich schlicht um die Inanspruchnahme einer Dienstleistung. Daher ist die Zuteilung der Bitpanda BEST Rewards nicht steuerpflichtig, weil keine Gegenleistung erfolgt. Dementsprechend gilt: Zufluss mit 0€, keine Versteuerung.”"

from here: https://blockpit.io/tax-guides/krypto-steuer-guide-deutschland/#:~:text=Vielmehr%20handelt%20es%20sich%20schlicht,0%E2%82%AC%2C%20keine%20Versteuerung.%E2%80%9D

[provinzio]

The first transaction is basically the one that substracts the staked amount from the "normal" wallet and the second transaction adds the staked amount to the staking wallet (assuming they are two separate wallets and in absence of a better word). It's like in accounting where you always have two booking statements between accounts.

In that case we'll only need one of them. The other can be ignored.

You mean the start of the Spekulationsfrist for the staked coin is untouched by staking?

It's untouched by staking. But that's not what I mean. Staking does not "block" coins from being sold. E g. Of you buy a coin, stake a coin, buy a coin and sell a coin, you would sell the first coin bought. (our current implementation)

[wullxz]

In that case we'll only need one of them. The other can be ignored.

Which one can be ignored? Can't they both be ignored since the initial balance of bought coins basically doesn't change since the Frist only considers the initial acquire?

[provinzio]

In that case we'll only need one of them. The other can be ignored.

Which one can be ignored? Can't they both be ignored since the initial balance of bought coins basically doesn't change since the Frist only considers the initial acquire?

Our current implementation does not handle staking but we should consider it for the future.

[wullxz]

Ok, so the following changes are needed:

• transfer(stake) should be associated with Staking if the direction is incoming (I guess I need to unstake to see if the transaction looks the same except the direction being outgoing to also implement StakingEnd).
• reward should be associated with StakingInterest but should probably print a warning that the label isn't clear and the user should check if all the reward transactions are indeed staking rewards
• transfer of BEST should be associated with Airdrop since it's non taxable but still needs to be considered when selling the acquired coin

Is that correct?

[wullxz]

Oh and just to be safe: BEST is also used for the platform specific fees (the bitpanda fees per transaction not the blockchain fees). A transaction for deducting the BEST balance by the platform transaction fee looks like this:

Ce0d9453e-552b-4649-8a47-818025cf6a40,2021-05-13T00:30:59+02:00,withdrawal,outgoing,0,EUR,0.00000000,BEST,0.00,-,Cryptocurrency,33,1.35516244,BEST,-,-

How should they be categorized? They are relevant for the Frist, right? And if they are, they should be booked as well but as what?

[provinzio]

Looks good to me.

If I remember correctly, Airdrops should have an optional Parameter somewhere whether they are taxable or not.

Please add your explanation for the best reward in the readme with the source.

[provinzio]

Book fees as Fee transaction type. The algorithm tries to match them to trades

[wullxz]

Just a quick question because I just stumbled upon this: In _read_coinbase Rewards Income is associated with Staking. Shouldn't that be StakingInterest? It's definitely staking rewards.

[provinzio]

Just a quick question because I just stumbled upon this: In _read_coinbase Rewards Income is associated with Staking. Shouldn't that be StakingInterest? It's definitely staking rewards.

Sounds like it. It might be wise to ping the writer of that line to double check or look into the Coinbase documentation.

[wullxz]

Well, you are the author of that line ;) (here) And I checked with my coinbase export: Those transactions are definitely staking rewards. I think, the staking operation is not included in their export. I can't find anything related.

[provinzio]

Well, you are the author of that line ;)

Dammit 😂

Sounds reasonable to fix that

[wullxz]

just a heads up: I've tried to get everything to work but while doing that I found a bunch of other anomalies. The ones I found are:

• rewards were not always tagged rewards. Prior to 2022-6-14 (or a few days before - can't tell without doubt) staking rewards were tagged as incoming transfer. I check if incoming transfers before that date are for asset type Cryptocurrency and if so, I'll tag them as rewards / StakingReward
• When bitpanda started offering stocks, they gave away random stocks to their members. Their asset class starts with "Stock" (and contain additional info like "derivative"). I'm flagging those stocks (incoming, transfer, asset_class starts with "Stock") as airdrop gifts. This occurence prints a warning.
• outgoing transfer Cryptocurrency is flagged as staking. The case here is similar to the first point: bitpanda didn't flag them as transfer(staking) from the beginning but I can't find any other reason why outgoing transfers of Crypto should be something else. This also prints a warning.
• When holding stocks that pay dividents, the divident is accounted for in your FIAT wallet as incoming transfer and I'll flag those as AirdropIncome, a new subclass of Airdrop that sets the flag for taxable_type = "Einkünfte aus sonstigen Leistungen. This should probably contain "Einkünfte aus Kapitalerträgen" or something similar? This also prints a warning and also tells the user how to check if the transfer of FIAT actually is divident income.
• In 2022 the Terra (LUNA) blockchain crashed. It got "restarted" as Terra 2.0 (LUNA) but the old chain still continues to exist as Terra Classic (LUNC). If you had LUNA at the time of the crash (owning LUNA through bitpandas crypto indices also counts), you've received an airdrop of LUNC according to your previous ownership of LUNA. To be honest, I don't know what to do with those airdrops (also incoming transfer btw), so I print a warning with a link to bitpandas blogpost about the event and tell the user that this behaviour is not yet implemented. In my case, I still own those LUNC tokens because they're basically wothless (at least the amount I have) so I don't really need to think about them. I'd like to implement this correctly though if possible. If I understood correctly, the Spekulationsfrist for the newly created coin starts at the same time, the original was procured. So I'd need to look up the buys and sells of the past to basically copy them I guess? Also, German law is not entirely sure about how to handle events like that. The most likely way it would be handled is to assume procurement cost of 0€ - see here.
• Also in 2022, Ethereum switched to Proof of Stake and it did that using a fork. The old PoW chain still exists and something similar to LUNC happened: bitpanda awarded you ETHW tokens if you owned ETH before the split which essentially is the same situation as what happened to LUNA/LUNC and to which I don't have a proper solution. In my case the value of the ETHW, which I immediately sold was below 10€ which is why I just deleted the airdrop and the sell order to continue working on everything else. I think I'd just take my chances and drop it from my declaration or add it manually for now. Still, as in the case of LUNC, a proper implementation would be preferrable.
• Stocks. They haven't been implemented at all so far and they don't have that same 1 year Spekulationsfrist. I'm probably starting implementing stocks today and I'll create more Transaction subclasses for StockBuy and StockSell which will contain a flag to ignore the 1 year Frist.

I'm sorry but the PR I'm going to send will be a bigger one. If you'd like several PR I can try to make that happen but it would take me longer. I'll split the work on bitpanda and coinbase into separate PRs though.

[provinzio]

As long as the names they use for transaction types are unique there should be no problem in matching them to the corresponding Countaxman Transaction (see binance implementation)

Dividends of stocks are not really in the scope of this tool. Dividends might not be Einkünfte aus sonstigen Leistungen but Kapitalerträge which are taxed differently. If you really want to include stocks and stuff. We should implement it including a tax report similar to the tax reports of banks. As this is quite a lot of work and not in the scope, I would vote against this. But feel free, please add it as separate PR.

For the LUNA case. What about an relabel transaction class which kind of relabels other transactions so they have the new coin name for matching with sells/withdrawals. Keep in mind that there are more than just buy transactions from which you can get coins.