Horizen Batch Withdrawal and Send Back

Can you please find away for accounting to recognize batch withdrawals from several Horizen addresses to a single address. Batch withdrawal is a feature of Horizen’s wallets and is used all the time for users staking coins on nodes.

Rewards are paid on to the staked address. When the node operator wants to remove coins from all their staked address they need to remove the earning and keep the certain level of coins on the sending address which creates a situation where coins are removed from several zen address simultaneously and then sent to the consolidate address. However to maintain the staking balance part of the zen sent in the transaction is returned to the sending addresses to maintain the staking requirements.

This type of transaction is usually completely internal in the sphere wallet but it causes significant difficulties with accountings software because it gets confused by this transaction type because the coins usually are moving all from internal addresses to a consolidation address but then some coins are sent back to staking address minus the transaction fees and accountings software can’t seem to line up what coins went where even though they are all internal transfers.

When I manually try to reconcile where the transfers all went I have multiple options with varying values for identifying the internal transfers. I have attempted to reconcile these types of transfers numerous times as internal transfer but it always leads to a significant miss match between what is on my staked addresses and what accointing thinks my balance should be on my stake addressed.

I have had to delete and reimport all my transactions for years several times and in the end I couldn’t get things to cleanly reconcile which has left me with no choice but to not categorize these type of batch internal withdrawals in the system because it just leads to inaccurate balances.

Ideally I would like to have this issue fixed so that accointing can recognize all the coins the were recirculated back into their staking address and that when multiple address receive a withdrawal in one transaction it can be clearly identified as an internal movement of coins.

Also it would be verify helpful if you could increase the number of zen addresses that can be added to an accointing account. I have already hit the limit of addresses I can import and I still have several address that I have used historically that I can import cost basis from because the system seems to have a hard limit on the number of wallet addresses I can import into the system. This low hard limit of zen addresses just further complicates my accounting as I try to reconstruct cost basis on my transactions over the past few years.

Hey! Thanks for the feedback! In ACCOINTING.com, we work based on a voting mechanism: the more upvotes your feature requests has, the faster it moves in our development pipeline. Hopefully, you’ll get enough upvotes from this community to have it implemented.

Also:

I understand your frustration with the staked and staking classifications so just to clear this out from our standpoint:

all tokens that were staked=do not classify
all tokens that came as a reward for staked tokens=staking

The reason why we don’t have more strict guidelines is because there aren’t any and they are subject to the interpretation of the different jurisdictions. That bein said, here is an article from Bloomberg providing further context on the matter:

Now, the lender could be considered to have converted their crypto for another crypto when they “stake” their money into the liquidity pool and received another token they can sell elsewhere. That is a taxable event, so in this example, just as dividends are taxable, so are tokens generated from staking activities.

However, it’s not as straight-forward as that because this transaction can also be viewed in another way; in that what the lender deposited in the liquidity pool is still their money and the tokens they receive in exchange is nothing more than a receipt. That means it is not a taxable event.

Meanwhile, on the borrower’s side, it can be argued that depositing collateral and receiving a loan in a different token form is akin to an exchange transaction, so a taxable event. Of course, usually taking a loan is not a taxable event. However, the transaction on a DeFi is unique. Unlike conventional loans, it includes depositing one currency as collateral to receive a loan in another.

If you need any tax assistance with your crypto taxes, make sure you visit ACTAN in the Hub where any of our crypto tax professionals can help you out.

Consider voting for this [link] and comment how voting for this would help you :slight_smile:

I will ask for support to see if this is a bug.