We have just deployed the second code version of our first Bitcoin protocol to the public testing sandbox environment.
We would love to hear about your experience with Bitcoin trading and our API keys in the sandbox!
The sandbox deployment is a testnet environment for testing API integration and the system as a whole. Accounts receive testnet funds on sign-up. Do not send real funds to the sandbox.
Please use this thread for general bugs. For security vulnerabilities contact us at: bugbounty@nash.io. Do not use this thread for suggestions or ideas for improvements – we will open another dedicated thread on Monday.
When reporting bugs, please try to include any errors displayed in your browser console or on network calls (the “Network” tab when you open the console).
During this week, we will perform daily resets and deployments to the sandbox, with several UI and system improvements reaching this milestone. On every reset users testing the system will need to re-create their accounts.
TL;DW:
Even though orderbook is sufficiently deep to support a market order of my total BTC balance, when clicking on 100% it goes crazy and switches from 8895% to 126% to 79% and back…
EDIT: I realized there is a typo (missing “i”) in the error message “Insufficient BTC”
EDIT2: Also, as you can see the buy orderbook starts at the bottom because I’m on Mac (on Windows that bug is fixed).
Orderbook is not refreshed after canceling my order. It is still there. Had to refresh my browser. (You cannot see it in this picture, but the order was confirmed cancelled)
Maybe this is intended behavior though and not a bug, but if so the link is not obvious to the user and this could definitely become an issue if it takes to long to confirm.
this function have a problem when it need to computes the quotient and the remainder regarding the order book.
For the case you have ETH and you sell ETH. compute % of that balance is easy.
when you have BTC & buy ETH: Compute % of BTC balance put it in “TOTAL” then computes “ETH Amount” regarding order book seems really weird. can be various reason.
I think validation is done by the format of Bitcoin mainnet addresses. It should start with a 1, 3 or bc1. Also the length of the fake address is different. If you remove two characters and put a 1 in front of the address, it will accept it.
As @Crome said @Oldsport this is not a valid BTC address, BTC has 3 types of addresses, starting with 1: P2PKH, starting with 3: P2SH and starting with bc: Bech32. We perform addresses validations to try to safeguard the user from inserting the wrong addresses into it.
Maybe for sandbox we need to add 2: Testnet SH as well.
@fischdenflo in the initial picture it was cropped to me, you are correct so no issues there .
I will clean the reports to make it more straightforward to follow.
@ImanvdMaas we are looking into it, It seems this is because on the new transfer flow we deffer to a background process to track and send transfers in proper order (instead of having the user to come back after a sync as we used to do for example). As I communicated before this is the frontend part of a two step final fix for transfers, instead of having the client tracking those in the short term we will have a backend process to do it.
So long story short: we are looking into this, could you try cleaning your local storage by clicking here this option in “More tools” > “Developer tools” and confirming it solves the issue ?
.
