Request support for XRD

Starting on June 30 there will be a new token running on its own “blockchain”, called XRD. Starting on July 7, there will be software called instabridge that implements a 1:1 exchange between an existing ERC20 token with ticker eXRD and XRD. This bridge is designed so that when an exchange happens, the other token is in a locked state and cannot be used for anything, except for an exchange in the other direction. eXRD and XRD will trade as two separate but equivalent tokens each on their own blockchains. If any price differences should temporarily exist, it is expected they will be quickly arbitraged away. Thus it works similarly to the way WBTC is “equivalent” to BTC, with the one difference being that WBTC can be traded on the Etherium blockchain.

To the best of my (limited) knowledge, all jurisdictions treat this as a like-kind exchange. That is essentially the same as moving cash from one pants pocket to another, and not a taxable event. So, I am requesting that you (after approval by your lawyers) make a small software change to recognize the essential equivalence of eXRD and XRD, just as you now (I think) do the same for other “wrapped” tokens.

If you have any questions, you may contact the project team at hello@radixDLT.com

Also, to the best of my knowledge, the team has not yet contacted you as to the best way to interface with your software. Of course, it is a CSV file, but I have some concerns about the novel way they plan to implement DPOS. Validators (and people who delegate and t team will receive some share of a protocol emitted emission

For unknown reasons my message was terminated before I had finished typing it. I was also unable to edit, even to delete typos. So let me continue by replacing my last sentence.

Validators (and people who delegate to them) will be paid for staking by the receipt of some share of protocol emitted XRD, according to a documented formula. Unlike most blockchains, this is not simply stored on the ledger as a transaction record describing the date/time, the amount, the receiving address, the sending address, and a transaction hash, etc. This results from their revolutionary extension of blockchain into a more general data structure to support their revolutionary consensus mechanism, capable of shading to an unlimited extent.

This requires the existence of some offline piece of software that can analyze the data structure on the “blockchain” (it is something more flexible than a blockchain). And then produce a CSV file that you can import. Please contact them (or me) at the above email, and see if there is some way that the provider of such software can be advised of your preferred format for this data. You have my permission to copy this mail and my email address in contacting them, should you so desire.

Some issues I have identified: Is the acquisition date/time of emissions: (a) the end of an Epoch, when the amount of emissions is calculatable (b) the time I request a (partial or full) unstake, (c) the time “approximately” two hours after an unstake request when I can possibly spend the unstaked tokens. Does the potential (but not realized) ability to unstake an epoch’s emissions influence my cost basis? Does this vary from jurisdiction to jurisdiction? Does German law (so I hear) really require that you pay taxes on emissions first, even though the token is fungible?

Most importantly, what kind of information would you like to see in the CSV file software so that you can properly support all the different jurisdictions you have customers for? If this requires more changes to your software, when/if can I expect them to be implemented. If you cannot commit, I may need to find another tax software provider.

One other unrelated “bug”. I use Grammarly to do routine spelling and grammar checks on my text. When it detects something suspicious, it highlights it with an underline. For unknown reason the underline is displaced horizontally in the text by about a dozen characters.

Thanks for your patience in reading a necessarily long post,