Coin specific wallets causes sync and manual failures

So, I think I’ve run into this before, but it’s such a gotcha that it happens all the time. We know that when entering transactions manually, adding a new coin to an existing wallet yields no wallet for that coin (e.g. “Bitstamp XLM”) which is met with an error that prohibits entering the transaction. The work-around is to do an import, perhaps of one line where the exchange or wallet is listed along with the coin, but not the coin specific wallet. Then the coin specific wallet is listed, and new transactions can be entered.

However, the real gotcha is that this problem affects syncing as well! So the sync fails when I purchase a new coin on that exchange. This recently happened buying XLM on Bitstamp. Those transactions were mysteriously and silently missing after sync. Took me a while to figure out what was happening, but a silent failure like this is a REAL problem. I want to spend some time on what I think are design issues here.

So the first and obvious fix is to add logic in the sync which handle’s a new coin on that wallet. However, that doesn’t deal with the fact that manual transactions are blocked as well. Of course I ran into that because the sync failed, but I’ve run into it with other cases where I had to enter manual transactions. For example Celsius syncs with CoinTracker but it omits CelPay transactions (their fee-free Celsius to Celsius transaction facility). When a new coin is added due to a CelPay transaction, an import must be constructed in order to get CoinTracker to recognize the new coin and transactions.

However, a deeper question is why we have to enter coin specific wallets to begin with. I’m sure there’s some design decision you made early on that constrains you, however I’m going to suggest that the real fix is to get rid of this constraint. When a coin is listed with that side of the transaction, the coin information is there. For whatever situation in your computations that you need to the bucket of coin-specific wallet, you can simply construct it internally in the logic or on the DB (calculated DB column maybe). What’s interesting is that the migration could be relatively smooth because your just getting rid of unnecessary information/specification. You might need to add logic which allows existing users to add the coin information until they get used to it, maybe a friendly error message or just ignoring the coin part when it is accurate. I would automatically strip the coin off with a blue message that says, “You no longer need to enter the coin with the wallet/exchange most of the time.”

Of course there are some corner cases which caused you to do this in the first place. I’d suggest that you can use coin specific wallets only for those weird cases.

The other gotcha would be for your system to figure out the coin icon when it is unambiguous. That’s a similar confusing gotcha, but I mention it here to point out how much complication you’re thrusting on your users. And our failure to understand and remember the quirks of your system yield real black eyes for us. I’ve become quite a power user, yet even guys like me struggle with these issues repeatedly. High priority design bugs in my opinion.

Hi @cacortes,

These are great points. Two updates we have in our engineering pipeline right now are:

  • importing all transactions (even for tokens we don’t yet support)
  • adding a placeholder icon to distinguish when a token is now mapped correctly to the expected token

We really appreciate this feedback and will see how we can incorporate this into improving CoinTracker. We’re also hiring if it is taking us too long to fix!

1 Like