Go to file
scoobybejesus 5b2bd175c4 Removed unneeded muts. Resolves #30. 2019-08-30 18:29:47 -04:00
src Removed unneeded muts. Resolves #30. 2019-08-30 18:29:47 -04:00
.gitignore Initial commit. 2019-08-25 19:57:07 -04:00
AUTHORS Initial commit. 2019-08-25 19:57:07 -04:00
Cargo.lock Changed Box<Erro> to Box<dyn Error>. Resolves #29. 2019-08-30 18:25:14 -04:00
Cargo.toml Initial commit. 2019-08-25 19:57:07 -04:00
LEGAL.txt Initial commit. 2019-08-25 19:57:07 -04:00
README.md Updated README. 2019-08-29 22:51:33 -04:00

README.md

cryptools-rs

Accounting library for cryptocurrency transaction activity.

(Currently runs as a binary, not a library)

The software measure one's cryptocurrency activity (i.e., denominates one's income/expenses/gains/losses) in their home currency. The default home currency is USD, but anything can be substituted. This type of tool may be useful, for example, when preparing to file taxes.

Given an input CSV file reflecting the user's entire cryptocurrency transaction history, the software will:

  • assign cost basis as of the date of purchase/exchange/receipt
  • track the original acquisition date and cost basis until the time of disposal
  • compute gain or loss from the sale/exchange/disposal (including whether short-term or long-term)
  • record income for incoming transactions and expenses for outgoing transactions

Reports (CSV file) may be exported that reflect income/expenses/gains/losses or cost basis of existing holdings.


The activity that gets imported must be in a prescribed form (a CSV file) that effectively looks like this:

txDate proceeds memo 1 2 3 4 5
Bank Exchange Wallet Exchange Simplewallet
USD BTC BTC XMR XMR
non non non non non
2/1/16 0 FIRST -220 0.25
3/1/16 250 SECOND -0.25 180
4/1/16 0 THIRD -90 90
5/1/16 0 FOURTH 90 -90
5/2/16 160 FIFTH 0.3 -90
6/1/16 0 SIXTH -0.3 0.3
7/1/16 200 SEVENTH 0.7 -90
8/1/16 0 EIGHTH 0.3 -0.3
9/1/16 400 NINTH -0.5 200
10/1/16 900 TENTH 1 -200
11/1/16 0 ELEVENTH -1.5 1.5
12/1/16 2000 TWELFTH* -1.5 400

* This last transaction is an example of how a user might reflect an exchange via Shapeshift or similar services, where one currency is spent from one wallet and a different currency is received in another wallet.


CSV file components

  • txDate is currently set to parse dates of the format MM/dd/YY.

  • proceeds This is the value transferred in the transaction. For example, if one spends 0.01 BTC at a time when BTC/USD is $10,000/BTC, then the user received value of $100, therefore the proceeds of that transaction would be $100. When transfering to oneself (i.e., not changing currencies), this value is irrelevant and ignored. This value is also ignored when the user's home currency is spent.

  • memo is useful for evaluating the final output but isn't important. Currently, commas in the memo are not supported.

After three columns of transaction metadata, the Account columns follow.

  • Accounts (1, 2, 3, 4, 5, ...): the top row reflects the account number (which currently must start at 1 and increase sequentially). The three other values are the name, ticker, and margin_bool. name and ticker should be self-explanatory. margin_bool is set usually set as 'no', 'non' (i.e., non-margin), or 'false.' To indicate a margin account, set it as 'yes', 'margin' or 'true'.
Margin accounts
  • Margin accounts must come in pairs, the base account and the quote account. The base account is the coin being longed or shorted, and its ticker is reflected like normal. The quote account is the market. The quote account's ticker requires a different formatting. For example, when using BTC to long XMR, the BTC account must be reflected with the ticker BTC_xmr.

  • Margin gain or loss is accounted for when there is activity in the 'spot' account. For example, you won't reflect a loss until you actually spend your holdings to pay off your loans.


Features

  • Two methods each of LIFO or FIFO (with intentions to add more)

  • Ability to perform like-kind exchange treatment

Constraints

  • All cryptocurrency-related activity for the user generally must be included in the input CSV file.

  • There can only be either one or two accounts used in a given transaction (i.e., if a Counterparty token or Ethereum token transaction must be recorded, the XCP or ETH transaction fee must be reflected in a separate transaction/row).

  • Manual adjustments may need to be made to the output files in cases, for example, when the user used aprpeciated cryptocurrency to make a tax-deductible charitable contribution.

Installation

  1. cargo build (or include --release for a non-debug build)

This will build ./target/debug/cryptools-rs.

Usage

Run ./target/debug/cryptools-rs with no arguments (or --help, or -h) to see usage. Alternatively, run cargo run, in which case command-line arguments for cryptools-rs may be entered following --, e.g., cargo run -- -h.

Running with no arguments will lead the user through a wizard, or all required arguments can be passed as command-line flags/options/args.

Development state

As of summer 2019, the code is "feature complete" in the sense that it does not require additional features in order for it to serve the needs of the original author. At the same time, there are plenty of bells and whistles, creature comforts, etc. that may be added at any time. Additionally, the code could use factoring or general re-working in several areas. In fact, it may be nice to use the business logic as a library instead of running a full binary.

Contributing

  • Contributors welcome. New authors should add themselves to the AUTHORS file.

  • Roadmap and todos: we're working through items in Issues; feel free to tackle or add issues.

See LEGAL.txt