So for all these mentioned above (and possibly more) they use bond instead of provide_liquidity. So what currently is happening is that every transaction towards these contracts is recognized as anchor.handle_bond which fails of cause.

After some debugging and working into the code it seems easiest just to label these as provide_liquidity. It looks like that handle_lp_deposit can handle these transactions just fine.

The current solution I found, is not the cleanest (so this issue instead of pull)

execute_type.py

# ...
def _execute_type(elem, txinfo, index=0):
    txid = txinfo.txid
    execute_msg = util_terra._execute_msg(elem, index)
    contract = util_terra._contract(elem, 0)
    try:
        addr = util_terra._lookup_address(contract, txid)
    except Exception:
        pass
     
    # ...
    elif "provide_liquidity" in execute_msg or "bond" in execute_msg and len(addr):
        return EXECUTE_TYPE_PROVIDE_LIQUIDITY
    # ...

This solution utilizes the fact, I observed so far, is that the only bond type tx which has no addr is the anchor bond itself. But well :shrug:

Hey! I'm having issues using this tool with Terra chain, I am getting "Unable to determine lp currency for addr". Any ideas what the reason could be?

INFO:root:localconfig: {'__module__': 'terra.config_terra', 'minor_rewards': False, 'lp_treatment': 'transfers', 'ibc_addresses': {}, 'currency_addresses': {}, 'decimals': {}, 'lp_currency_addresses': {}, '__doc__': None, 'job': None, 'debug': True, 'cache': False, 'limit': 20000, 'koinlynullmap': None}
INFO:root:max_txs: 20000, max_queries: 200
CRITICAL:root:Bad stage=default in ProgressTerra.report()
INFO:root:Querying FCD url=https://fcd.terra.dev/v1/txs?account=XXX&limit=100..
INFO:root:Wrote to _reports/debug.gettxs-XXX-0.json for debugging
INFO:root:{'message': 'Retrieved total 78 txids...'}
CRITICAL:root:Bad stage=default in ProgressTerra.report()
INFO:root:Querying lcd for contract = XXX ...
INFO:root:Requesting url https://lcd.terra.dev/wasm/contracts/XXX?
INFO:root:init_msg: {'name': 'Kuji', 'symbol': 'KUJI', 'decimals': 6, 'initial_balances': [{'address': 'XXX', 'amount': '150000000000000'}]}
INFO:root:Found symbol=KUJI decimals=6
INFO:root:Querying lcd for contract = XXX ...
INFO:root:Requesting url https://lcd.terra.dev/wasm/contracts/XXX?
INFO:root:init_msg: {'name': 'Kuji', 'symbol': 'KUJI', 'decimals': 6, 'initial_balances': [{'address': 'XXX', 'amount': '150000000000000'}]}, txid:XXXX
ERROR:root:Exception when handling txid=XXX, exception=Unable to determine lp currency for addr=XXX, txid=XXXX
ERROR:root:Unable to handle txid=XXXX with error_type=exception Traceback (most recent call last):
  File "report_terra.py", line 177, in <module>
    main()
  File "report_terra.py", line 42, in main
    exporter = txhistory(wallet_address, options)
  File "report_terra.py", line 125, in txhistory
    terra.processor.process_txs(wallet_address, elems, exporter, progress)
  File "terra\processor.py", line 29, in process_txs
    process_tx(wallet_address, elem, exporter)
  File "terra\processor.py", line 80, in process_tx
    raise (e)
  File "terra\processor.py", line 67, in process_tx
    terra.col4.handle.handle(exporter, elem, txinfo)
  File "terra\col4\handle.py", line 184, in handle
    return handle_lp.handle_lp_stake(exporter, elem, txinfo)
  File "terra\col4\handle_lp.py", line 156, in handle_lp_stake
    lp_currency = util_terra._lookup_lp_address(lp_currency_address, txid)
  File "terra\util_terra.py", line 359, in _lookup_lp_address
    raise Exception("Unable to determine lp currency for addr={}, txid={}".format(addr, txid))
Exception: Unable to determine lp currency for addr=XXX, txid=XXXX

Hi, I am trying to pull "myalgowallet" transactions into csv. It seems to work mostly, but there is one transaction with txid HAJARJ5DZ2M3N4YC2RT3CQHEAFRJCC4LHEUN3VKWWROLPCFTPOTA that errors out. It seems like this is an algofi inner transaction. Are you able to fix? You can see the error below

ERROR:root:Exception when handling txid=HAJARJ5DZ2M3N4YC2RT3CQHEAFRJCC4LHEUN3VKWWROLPCFTPOTA, exception=list index out of range
ERROR:root:Unable to handle txid=HAJARJ5DZ2M3N4YC2RT3CQHEAFRJCC4LHEUN3VKWWROLPCFTPOTA with error_type=exception
INFO:root:{'message': 'Processed 1 of 1 transactions', 'seconds_left': 0.0, 'time_elapsed': 0.4218597412109375, 'stage_name': 'default', 'stage_total_tasks': 1, 'stage_current_task_number': 1}

By digging a bit through the code it seems that it should be fairly easy to add support for older cosmos hub versions as well.

The API used to retrieve cosmoshub-3 txs is in fact the same as for hub-2 and hub-1. Cosmostation added this not too long ago (see e.g. here or here).

I think by removing the filtering in: https://github.com/hodgerpodger/staketaxcsv/blob/e35cae782467b28836b2fa85e88686a73fd80ad3/src/atom/cosmoshub3/api_cosmostation.py#L28-L29 you could actually return all Txs.

Is that sth you would consider adding (i.e. would you accept a pull request that extents this to hub-2/-1?) or is there a particular reason why this is limited to hub-3?

Koinly defaults the 'STARS' currency to some other token not the 'Stargaze' token on Osmosis. I was able to override this by setting the currency to ID:36899 in the CSV for import. It seems that tells it to use the Koinly internal ID: https://app.koinly.io/p/markets/36899

Not a huge deal to search/replace but figured it might be able to added like you did with the GAMM->NULL switch. Thanks!

This PR will:

• Add terraswap route swap support, initially with focus on supporting bPSI-DP-24M trades
• Add "events from log" helper to extract events from log messages

testing

Two random transactions picked up from the route-swap contract:

• https://finder.extraterrestrial.money/mainnet/tx/DB5A846ABE56585EF99906108C4251F508FCCDDCD15629D318B8AA8FF907CAE5
• https://finder.extraterrestrial.money/mainnet/tx/7090E0A61AFAF52D4597B853C8063FC5F33E87A215FCC7953C7D70DC83A289EE

Close #118

cointracking.info format does not include fees in sell amount. Sell amount should include the fees. https://cointracking.freshdesk.com/en/support/solutions/articles/29000007202-entering-fees

Sell amount 178 should be 178.287933

I just imported a new TERRA staketax file into Koinly and noticed that all BORROW transactions are misstating the gross total impact. There's sort of 4 components to a BORROW transaction with Anchor:

1. The usual Terra transaction fee -- the small fee charged to all transactions on the blockchain.
2. Borrow Amount: the total amount being borrowed and needs to be repaid.
3. Receive Amount: this is the amount deposited into the users wallet.
4. Anchor Borrow Fee: I'm not sure on the correct title or definition for this fee, but this fee is displayed to the user when they choose their borrow amount in Anchor Protocol, and is taken out of Borrow amount to result in the Receive Amount.

Right now it appears that staketax is disregarding (4), the Anchor Borrow Fee, resulting in no visibility to those costs.

To resolve, the Anchor Borrow Fee could be combined with the existing transaction fee amount.

Screenshots below of an Anchor Borrow transaction, highlighting the fee that's not being accounted -- it shows up in a a few locations:

Hello, and thank you for writing this tool. It's a lifesaver

I recently did an export of my wallet, and when looking at the exported data, it would appear that [Osmosis BTSG Pool 560] reward incentives or airdrop (https://www.mintscan.io/osmosis/txs/57E82EA67EA00C54EC6068F2860E0DA227532C5F5013745F7071808FD4786471) were reported as deposits into my wallet. The following line is repeated in the exported CSV 41 times.

2021-12-31 17:03:02,,,<AMOUNT-HERE>,BTSG,,,,,,,57E82EA67EA00C54EC6068F2860E0DA227532C5F5013745F7071808FD4786471-560

The issue is that I only received the amount just once, and this has resulted in nearly every tax tool thinking that I earned the entire USD value of the airdrop. 😧

I've been able to manually verify and fix the CSV locally, but wanted to bring this to your attention in case someone else runs into it 😅

Following basics outlined in https://github.com/hodgerpodger/staketaxcsv/pull/185

Happy to add any pieces if I missed something.

Do chains added here automatically get added as well to http://stake.tax website?

Cointracking.info output fees are duplicated when fees are in third currency.

As we have discussed (https://github.com/hodgerpodger/staketaxcsv/issues/31) cointracking.info requires fees in third currency to be on their own separate transaction.

But here they are in the trade line and also in the "other fee" line.

This causes the that the fee report in cointracking counts twice this fee

Lp rewards are showing correctly in stake.tax or api call through the 9th. However, after the 9th there is no record of lp rewards. Anyone know why or having the same issue?

Api call used in browser to see osmo lp rewards: https://api-osmosis-chain.imperator.co/lp/v1/rewards/historical/{wallet_public_address}/osmo

I saw some changes were made to the Juno transactions download. It now shows the received amount which is fantastic! Thank you very much, that has saved me a ton of time.

There is an issue I'm seeing where transactions prior to July 30th are no longer being returned. There is a note saying transactions prior to April 12th are unavailable on Juno chain, but I am seeing everything prior to July 30th missing.

I am actually seeing the same thing with Evmos as well. After you initially added support for Evmos, I was able to export all transactions for this year which went back to May. However as of 2-3 weeks ago, I can no longer return the earlier transactions. It also only goes back to July for Evmos.

Let me know if you need anything from me and happy to provide.

First off thanks for taking the time to make such a useful piece of software!

Everything works flawlessly except for a few issues. -Swapping from null tokens back to their base pairs seems to not be working, at least for the Osmo/UST pair -IBC transfer from OSmosis and secret appear not to be working

Regardless if you get to this message or not, stake. tax has made my life, and countless others' lives much easier. Kudos to you for putting your skills to work to help the less technically savvy.

Thanks again!

When closing a Solana token account or staking account, stake.tax categorizes this transaction as SPEND, the comment field says "fee for _CLOSE_ACCOUNT", and a debit of -0.00005 SOL is recorded.

When there is a balance in this account (as there often is in staking accounts), there are two problems with the results of this transformation:

1. The deposit for whatever was in the account is not shown in the stake.tax output at all.
2. This type of transaction removes the fee from the balance prior to transfer; it does not debit the main account's balance. This is a little unusual in the Solana world, but it's how it is when closing accounts.

Example transaction: https://solscan.io/tx/3onv4QuFKjBpB723XVmxhQD3TnocvnEqUd1RcJ8BqXEP4NfFWqDbEoJkP5eTPY9KnVe27naNyCyo4QbrLLiScYDC

Example CSV (row 7): https://stake.tax/?jobId=2c2a6e5969c749eabb276c3eb34313e4