It’s been a while since our last update, so I wanted to give a quick run down of some of the improvements we’ve been making related to our web service.
First, since we continue to get emails on this issue, I’d like to announce that we will re-enable delegation sales some time in the next 2 or so weeks. We will not provide any more guidance on an exact time when this will happen. Note that the price for delegations has increased dramatically since its original introduction due to demand and also because of the increase in the price of Steem which it is tied to.
Many of the changes we’ve made fall into the “invisible” category. When they do their job properly, the user never has to know the mistake was caught and auto-fixed by the software.
One common error when people are sending Steem/SBD to us is to put their desired destination address in as their memo when they send to us. If our software can tell what specific coin type they are asking for, it will automatically fix such transactions and send the desired coin type to the requested address. Note that this is only possible when the formatting of the deposit address is unique versus other coins we support.
One common error is when the wrong coin is sent to a deposit address (Steem instead of SBD, for example). We can’t in all cases fix this problem, because we can’t always be sure of what is the “correct” destination to send to, but often we can, and in such cases our system will auto-correct the transaction and process it now.
If we’re unable to determine what the user wants to do when a bad memo is sent, our software will auto-refund the Steem/SBD to the sending address, unless the sending address is an exchange or steem service that might send a user’s funds to us. We don’t auto-refund in such cases, because the exchange wouldn’t know how to properly credit the funds we sent them to the originally sending user of their site.
If you operate or plan to operate a service that does do auto-refunds on customer errors in a similar way, please contact us and we will whitelist your service against auto-refunds. This will prevent our server and your server from ping-ponging the funds back and forth due to repeated auto-refunds (we saw one such case already before we whitelisted the service against auto-refunds).
If you get a deposit address from our system to buy a Steem account, you can now re-use that address to buy Steem for your account. Once the account is created by our system, any further funds sent to that deposit address will be treated as a regular deposit address for buying Steem for the associated account.
If a user accidentally sends litecoin to a bitcoin deposit address, or vice-versa, our support personnel can manually “fix” such transactions if you send us an email with the transaction hash. Previously this was a difficult undertaking, so we’ve automated the process somewhat.
Please note however that it’s not possible for us to do this in the case of bitcoin/bitcoin cash address mistakes because one uses SegWit and the other doesn’t. So these mistakes will continue to result in a user loss until enough exchanges implement the new Bitcoin Cash-distinct addresses (discussed in more detail in our previous post on Bitcoin Cash). If you use an exchange with Bitcoin Cash, you may want to consider recommending they make this switch to help their users avoid such losses.
We’ve also changed our default conversion from Bitcoin → Steem to ETH → Steem and requested that Steemit makes a similar change to the default web URL they specify when linking to our site, since this will force users to make a conscious choice between Bitcoin and Bitcoin Cash when making a purchase with these two coins (ETH addresses are incompatible with Bitcoin and Bitcoin Cash, so there’s no danger of sending BTC or BCH to an ETH address).
Our Steem account creation now recommends sending a sufficient amount to purchase 2 Steem beyond the base price required to create the account. This reduces the chance for a price fluctuation that would cause an insufficient amount to be sent to purchase the account.
We’ve made many improvements to the internal information provided to our support personnel to allow them respond to support requests more quickly.
We frequently update our web site as we make improvements like the ones above. We’ve added a “revision number” at the bottom right corner of the site beside our copyright notice so that we can verify what version of the site a customer is using. We’re also in the process of adding code shortly to notify users when there is an updated version of the site, in case there is an update while they are on the site.
This last task is a long term one, although we’ve recently made some important improvements in this area.
Currently our site has been able to handle the peak number of concurrent users without any problem and indeed our primary challenge has been to maintain our high-speed response to customer support issues (hence all the work above to reduce the number of customer support requests that require human intervention). But we also want to be sure that our site itself remains robust in the face of increasing numbers of concurrent users.
Since March of last year alone, we’ve seen the number of transactions processed by our site on an average day increase by roughly a factor of 30, and there’s every indication that we will continue to see such increases in the future, so we’re taking pro-active steps now to be sure we can handle future loads.
As some people have already discovered to their misfortune, some malicious accounts exist that attempt to mimic the name of a popular account such as bittrex, poloniex, blocktrades, etc in the hopes that a user will make a typo and accidentally transfer to their “phishing” account.
In order to help prevent this, we’ve been maintaining a list of such phishing accounts and warning users when they try to send to them. But the weakness of this approach was that we had to keep up with such phishing accounts as new ones were created. To better combat this problem, our software will now auto-detect names that are “similar” to known exchanges and similar services that we are aware of, and warn users they are about to send to a suspected phishing account instead of the account that they are likely trying to send to (to do this, we re-used some of the code that we previously wrote to prevent our Steem account creation service from creating such phishing accounts).
