Cryptocurrencies transactions that are exchanges (cost basis)

147 views
Skip to first unread message

CD

unread,
Mar 16, 2024, 3:45:18 PM3/16/24
to Beancount
Two random transactions that I created based from an old Poloniex export a friend gave me...

2018-01-03 * "Crypto Buy" "Order number: xxxxxxxxx"
  Assets:DGB   5171.00018694 DGB @ 0.00000447 BTC
  Assets:BTC  -0.02317230 BTC
  Expenses:TradingFees    12.95990021 DGB @ 0.00000447 BTC

2018-01-08 * "Crypto Sell" "Order number: xxxxxx"
  Assets:ETC  -13.30376940 ETC @ 0.00225500 BTC
  Assets:BTC   0.02995500 BTC
  Expenses:TradingFees    0.00004499 BTC


Poloniex at the time only had transactions made between different cryptocurrencies, so there are no USD trades.  Everything is priced in one half of the pair  ie BTC/ETC DGB/BTC in the above examples.

How does one go about making everything into USD in reporting  (cost basis, etc)

I'm baffled.

If I set price directives for the different cryptos before each transaction will that do it?  Or am I going about it all wrong?

There doesn't seem to be a way to do double @ either.  So for example I couldn't do  5171.00018694 DGB @ 0.00000447 BTC @ 21000.00 USD  right?

Is there some way to set up the cost basis in USD in the initial transaction or using price directives?


Eric Altendorf

unread,
Mar 16, 2024, 6:16:35 PM3/16/24
to bean...@googlegroups.com
All of the following is not tax or accounting advice, but simply my understanding.  Feedback from other beancounters would be welcome.

I think you have to figure out the USD values yourself, based on your assessment of the FMV.  Here's some examples of how I structure exchanges.  (Reminder: this is a generated file with fake data)

2020-04-10 * "Exchange 1483.9889 USDT for 9.4000 ETH"
  Assets:Account:ETH                              9.4 ETH {158.1869 USD}
  Assets:Account:USDT  -1483.988882235528942115768463 USDT {} @ 1.0020 USD
  Income:CapGains

2020-06-10 * "Exchange 20.0000 ETH for 4943.2960 USDT"
  Assets:Account:USDT  4943.296022386568059164501299 USDT {1.0006 USD}
  Assets:Account:ETH                             -20 ETH {} @ 247.3131 USD
  Income:CapGains

I do this in my importers.  For example, the coinbase pro importer, when a transaction has an increase leg, looks up the USD price of the increasing currency:
I am sad I never had the time to clean all this up and create an elegant and consistent code path for handling both of these. :(

Regarding prices, I wrote my own code for price fetching (rationale in the header of the file):

Then for tax reporting you want to report the value of the proceeds in USD.  Take a look at the last entry in the Disposals table on page 5 of the example PDF report: https://github.com/ericaltendorf/magicbeans/blob/master/data/magicbeans_example.pdf  There was an exchange, where there was a disposal of 20 ETH and an acquisition of 4943.2960 USDT, but the "proceeds" (i.e., USD value on which taxes might be assessed) was 4946.26 (because 1 USDT ~= 1.0006 USD at the time).

hope this helps. i am sorry i haven't had a chance to get back to you on the other thread yet.


--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/a537f66b-f03b-4aac-bd50-deda8584a179n%40googlegroups.com.

CD

unread,
Mar 17, 2024, 11:44:38 AM3/17/24
to Beancount
Thank you for this.

I figured out the USD price importing (I downloaded price histories from Yahoo and put them all in a folder that my script references) but I am not clear on what the empty {} does


I understand if I want to book the price I purchased at in the database I want to use something like this...

 Assets:XRP   1107.10301990 XRP {0.66587 USD}

But in your example....


2020-04-10 * "Exchange 1483.9889 USDT for 9.4000 ETH"
  Assets:Account:ETH                              9.4 ETH {158.1869 USD}
  Assets:Account:USDT  -1483.988882235528942115768463 USDT {} @ 1.0020 USD
  Income:CapGains

What does the  USDT {} @ 1.0020 USD part do?


Thank you for the reply.  I saw that you replied in the other thread, I will be checking that out in the next few days once I get this sorted.

Eric Altendorf

unread,
Mar 17, 2024, 1:35:40 PM3/17/24
to bean...@googlegroups.com
TLDR: it's a hack to try to get beancount to carry cost basis along if that position is ever transferred to another account.

There have been a bunch of discussions about this and to be honest, I'm not 100% confident in the current state of affairs.

In general, beancount is not very reliable about carrying cost basis along with transfers.  Asset transfers are a very uncommon pattern in general beancount usage, it seems of concern mostly to crypto traders (who frequently transfer between exchanges and wallets).  So it's not a well-exercised or supported functionality.  See e.g.
(and many more crypto discussions on the list)

There have been a couple workarounds discussed.  It looks like what I eventually got working for me was inserting an empty cost spec:

It is possible this depends on this tweak I made to beancount core:

However like I said I have seen inconsistent behavior and so I don't have confidence in my mental model of what beancount is actually doing here.  It would be really nice to get this rigorously understood and supported.



CD

unread,
Mar 17, 2024, 10:19:45 PM3/17/24
to Beancount
Another question on your two examples...

If it's set to FIFO...

What if you have multiple Assets accounts for ETH?

For example - if you had 100 ETH in Assets:Coinbase:ETH and another 100 ETH in Assets:BItstamp:ETH  would the transactions below  still pull FIFO from both of those accounts or do they all have to be on the same account?

2020-06-10 * "Exchange 20.0000 ETH for 4943.2960 USDT"
  Assets:Account:USDT  4943.296022386568059164501299 USDT {1.0006 USD}
  Assets:Account:ETH                             -20 ETH {} @ 247.3131 USD
  Income:CapGains


Eric Altendorf

unread,
Mar 19, 2024, 2:37:52 PM3/19/24
to bean...@googlegroups.com
Hmm, i guess my example doesn't include any account transfers.

My understanding is cost bases are attached to lots which are tracked in accounts.  So if you have 100 ETH in account A and 100 ETH in account B, and you sell or transfer from Account A, it will FIFO the lots in Account A and ignore the lots in Account B.

IIRC the IRS issued some guidance last year saying that this is indeed how they expect cost basis to be accounted for, i.e., you can't treat all your ETH as fungible.  It sounds like if you have a more favorable cost basis in account B but you want to sell from account A, you actually need to physically transfer from B to A and then sell.  This is a bit silly since once the ETH is in account A, if that's an exchange, it's impossible to tell which ETH came from B or was previously in A anyway.  In fact I thought I heard some discussion of them expecting segregation and cost basis tracking even at the UTXO level, which strikes me as absolutely ridiculous, and which I think I also heard others write off.

Anyway, that gets into very murky areas.  This is not tax advice, but as for me, I'm following the guidance at the account level but not tracking individual UTXOs.

Simon Michael

unread,
Apr 26, 2024, 7:49:11 PM4/26/24
to bean...@googlegroups.com
On 2024-03-19 08:37, Eric Altendorf wrote:
> Hmm, i guess my example doesn't include any account transfers.
>
> My understanding is cost bases are attached to lots which are tracked in
> accounts.  So if you have 100 ETH in account A and 100 ETH in account B,
> and you sell or transfer from Account A, it will FIFO the lots in
> Account A and ignore the lots in Account B.


Hi Eric, I was just looking at
https://github.com/ericaltendorf/magicbeans/blob/master/data/magicbeans_example.pdf
, I must say it's rather lovely and as you say, practical for showing eg
to an auditor.

To be clear, if someone tracks lots in subaccounts and manually
preserves all costs when assets are moved around, magicbeans will
probably still be able to produce reasonably accurate reports ?

Eric Altendorf

unread,
Apr 26, 2024, 8:32:15 PM4/26/24
to bean...@googlegroups.com
Probably.  A big part of the issue I ran into was scale.  Both on the farming ("mining") side as well as on the trading side, there were tons of small transactions.  If you include the spam-dust (billionths of a cent that were sent to my address on a regular basis) I had a truly obscene number of transactions and lots.  Even if you filter those, I had many thousands because of some stupid pooling protocol issues and bad illiquid execution on an exchange.  So anything "manual" was simply untenable for me.  I wanted a fully automated pipeline, kind of like an old school "make" script, that would gather everything, apply my cleanups and tweaks, and reconcile it all.  I just kept adjusting the tweaks and cleanups until I handled all the mess, but then at least it's reproducible, and if i want to change something (e.g. lot selection, or I get some new info that was missing before) i can update and rerun the whole thing.  it's not the normal beancount way, but it felt most safe to me.

FWIW, magicbeans has basically two components: one, which is what I just described, a set of importer tools that I found useful, which produces a beancount file.  The second is the report generation, which takes a beancount file as input.  If you produce a beancount file by other means but containing the needed info, you should still be able use the second half of the tool to generate the reports.
 

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages