andreashuber69 / smart-trade

smart-trade

Development Environment

1. Download and run the Visual Studio Community 2017 installer.
2. Check Mobile Development with .NET and click Install.

smart-trade's Issues

Trade amount is much too high when Bitstamp fails to report latest transactions

Amounts should only be hidden if a service is disabled

Sometimes the sold amount is off by ~80 cents

From the code, it appears this can only happen when the exchange reports back the wrong price/amount.

TaskCancelledException disables trading

Add a separate screen for settings

Information to show on main screen

• Enable / Disable
• Last trade time
• Last result (EUR bough/sold, error message)
• Last balance BTC and EUR
• ETA of next trade

UI update frequency is too slow sometimes

This is visible when the last or next trade is less than a minute away. The point of update should match the need, e.g. right after the number of seconds/minutes/hours has changed.

Amounts in the overview are not updated when trades happen

Disable landscape mode

The UI is designed for portrait mode, landscape is not a priority.

Add a setting for what types of events should be notified

It's probably a good idea to only activate the LED when the second or third error happens.

It's probably also a good idea to show one when the phone boots, so that the user is aware whether the service is currently enabled or not.

Add a setting for buy vs. sell

In a subaccount we can trade continuously, without interference from manual trades, so supporting them is a must. However, it turns out that there is no way to easily distinguish a deposit form a withdrawal in a subaccount. Both are typed as subaccount transfers, and the amount is always positive.

In a subaccount it is therefore not possible to find the intended nature of the trade (buy or sell) as we can on the main account.

The Result field on the status screen is too long

• Messages are cut off
• Height should be increased to fit 3 lines

Add MainActivity

This should display a list of all currency pairs, along with limited status information, like:

• Enabled/disabled
• Last result
• Balance

Refactor IBalance & ITransaction implementations

These currently duplicate more than necessary.

Trade sometimes fails with an ObjectDisposedException

This leads to the service being disabled. According to the stack trace this might happen within CopyToAsync, possibly when the server closes the connection before we had a chance to download the response.

The app sometimes crashes when touching a popup and hitting the back button 3 times

This only seems to be the case when the app is already open and on a status screen.

Use the reduced amount to calculate trading times

Currently the reduced amount is used, which leads to shortened trade intervals towards the end of the trade period.

Sometimes the next trade time is not set correctly

This happens when a trade exceeds the forecasted value due slippage.

Add activity logging

Add support for non-fiat currencies

On Bitstamp, trading fees are always paid in the second currency of a trading pair. For currency pairs involving fiat, fees are always charged in fiat and rounded up to the next cent. For all other currency pairs, fees are always charged in BTC and rounded up to the next 0.0001BTC.

Currently, only BTC/EUR is supported. In order to support currency pairs not involving fiat, UnitCostAveragingCalculator has to be adapted to account for the 0.0001BTC fee steps.

Disable updates while trading

During a trade, due to the PropertyChanged notifications, the screen is updated several times. We should update once at the beginning of the trade to set the status to something like "Trade in Progress..." and once at the end with the result.

Add a setting for period length

The UI should also show when the current period ends.

Query the value of non-fiat currencies to determine the minimal trade amount

Service will fail if deposit is burried under more than 100 trades

Use the more efficient API to get the balance

The currently used API returns all balances, we need only the ones of the traded currency pair.

Trading ETH fails due to too many decimal places

Value sold is often higher than EUR 8, paying 50% more fees

Currently EUR 0.001 is subtracted before selling, which works fine when the market does not move between getting the price and issuing the sell order. In about 1/3 of the cases, the market moves higher in the mean time, pushing the value over the fee increment threshold.

Moreover, the calculation for buying is currently different. The fee is subtracted from the amount before putting in the buy order. While this keeps the price below the fee increment threshold in most cases, it does not make much sense to use different amounts for buying and selling. In either case, we should buy/sell as much as we can, without going over the fee increment threshold.

Color-code that last result into the overview

The last buy order fails due to the fee not being considered

All amounts should be formatted to 5 decimals

Add feature to automatically transfer to main account

This should automatically detect whether the provided API key is associated with the main account or a subaccount. There should be the option to transfer to main after every trade, after 10, 100, when the trade period ends or never.

Schedule new alarm before doing anything else

This ensures that the service runs again even if the user forcibly ends the app while trading.

Reduce minimal wait time

Use the current balance instead of the deposit balance to spread buys

This avoids waiting periods with no buys, when the user buys manually.

Time update is late when app was running with screen turned off

Touching a popup sometimes goes to the wrong status screen

Touching a BTC/EUR popup sometimes goes to the LTC/BTC status and vice versa.

A trade requires the transmission of too much data

This is most likely due to the full order book being downloaded for each trade. Doing so has some minor benefits, like e.g. being able to not buy more than what is being offered by a single order and thus save some fees. However, since we strive to trade in the smallest amounts only (e.g. EUR 8), a single order is most likely only ever executed anyway.

A trade therefore does not require the full order book but only the current bid and ask prices, which are included in the ticker. Downloading the ticker probably requires an order of magnitude less data than the order book.

While a trade is in progress, set Result to a value that makes this obvious

Bitstamp requests sometimes fail with an ArgumentException

Encrypted secret is logged

Not a security problem, because secret is always encrypted. I doesn't make the log prettier, however.

Take time units from resources

Look into removing notifications that are no longer relevant

Like e.g. when the last trade failed due to network issues but then the retry succeeds.

Trade calculation fails when the current date is incorrect

Shortly after completing boot it seems that some phones have the date 1970-1-1. If a trade were to start while this is still the case there will be a crash and the service will be disabled.

Reschedule, if the current date is smaller than 2017-1-1?

Move hard-coded labels to string resources

Make sure all formatting for the UI is done with CurrentCulture...

... rather than InvariantCulture.

ICurrencyExchange.TickerSymbol differs from ISettings.Ticker

The former comes without a slash while the latter does have one. For consistency, both should have one.

Align floating point numbers by the decimal point

Test what happens when 0.0045 cents are added to all EUR buy amounts

Depending on how amounts are added by the exchange, this could save more than 20% of fees.

Additional info to show on main screen

• Period start & end
• Section start & end

The result of a scheduled trade should never be "Nothing to trade yet."

Right now, when the price moves down even slightly, the trade service will not make a trade as originally scheduled but instead will postpone. This results in more requests to the server and distorts the overall schedule due to the 2 minute minimum interval between trades.

It would be better to always make the scheduled trade (no matter how the price has moved) but then calculate the time of the next trade according to whether we've executed the current trade too early or too late (wrt to the current price).