[alexg]

@LeinAd

Hello,

The upcoming wallets6 is not about providing any new features: It is a consolidation effort of the existing features, into a new codebase that will be of higher quality in terms of UI performance, documentation, readability, maintainability, better unit testing, better static code analysis, automated integration testing, etc.

So, at this time, I am not able to work on any new features. Here is my plan going forward:

I am currently completing the core plugin, and beginning changes to the extensions.

When this is done (around summertime), I will release the changes and I will allocate some time towards bug fixing. With any new software release there are always integration issues that are not discovered until after release, and it should take about a month to sort these out.

Hopefully by autumn time the first bugs will be ironed out.

Then I will focus my efforts towards an ERC-20 adapter which is what everybody is waiting for.

So it is unlikely that I will be able to look at other coins or other features this year.

This is why I am only responding to defects and other issues with the existing products, as they arise.

with regards,

[alexg]

Hello,

Thank you for your interest in the plugin and its extensions.

Since you are situated in the USA, the EU business plan is not for you.

I will cancel your membership and refund your payment.

You can then sign up with a non-EU plan if you wish.

with regards

[alexg]

@boza44 Thank you for opening a new thread. I will reply to you there.

[alexg]

Hello Adrian,

Here’s what to do:

1. Go to Wallets -> Rates.

2. Follow the on-screen instructions to add a Fixer API key. It’s free.

3. Also check the “Fixer” box.

4. Click “Save changes”.

5. Click “Clear/refresh data now!”.

6. Set the default fiat currency to EUR. There should now be a EUR option in the dropdown.

7. Again, hit “Save changes”.

Hope this helps.

with regards

[alexg]

Hello,

This is normal. The user balances do not correspond 1-1 to wallet balances. Any POS rewards are gained on the hot wallet balance, which is owned by your site.

If you wish, you can calculate roughly what percent on your balance you gain via POS mining daily, then set up a recurring Airdrop, to distribute this percentage daily on that coin to users.

Or you can choose to only pay out a part of the POS rewards and keep the rest. It’s up to you.

If you have any more questions about the plugin I am happy to answer them.

with regards

[alexg]

Hello,

Thank you for your feedback.

This is not enough information for me to understand the issue you are facing, but here’s a few facts about the matching engine (maybe relevant):

– All fees are charged on the base currency, same as on all exchanges. The maker fee is the fee paid by the participant who placed the first limit order on the order book. The user who placed the second matching limit order, or a market order, pays the taker fee. This is again subtracted from the base currency balance.

– In both cases, the balance, and thus the available balance, of both users, decreases by the fees paid. This is to be expected.

– The exchange will only allow users to place an order that leaves them with positive balance, assuming that the largest of the two fees is paid (maker or taker).

– As the matching engine is running, if the base balance or quote balance of the user who places the order goes negative, the trade is cancelled and any trade is reverted.

The thread is titled “negative available balance”. To be clear, are you saying that, after users trade on the exchange, and without other manipulation of the DB, the users get negative available balances? If so, was there a problem with the balance of the market maker, or with the balance of the market taker?

Could you give me a complete example that I can follow, to reproduce the problem? If possible, please send me the following information:

1. Initial example base and quote balances of two hypothetical users.

2. What orders were placed? Let’s agree on some example amounts, prices, and also whether these were both limit orders, or a limit and a market order.

3. Go to Wallets -> Transactions. After a successful match, there should be four trade transactions related to the trade. Can I see these four rows?

4. What are the base and quote balances of the two users after the trade?

5. Does this occur on the unmodified latest version of the exchange?

Please test with the unmodified exchange, and that includes the templates and all other code in the exchange, parent plugin, and coin adapters. Better to do this on an integration server, not a production server.

I ask for all these details, because the last time we discussed a similar issue, I could not find a problem with the matching engine. I was also unable to spot any errors in the code.

If there is such a serious error, I need some more information to find it. I also ran some additional tests before writing this reply, and could not reproduce such an issue, so I don’t know where to look. Looking forward to your reply with additional details.

Thank you.

with regards

[alexg]

Hello,

I understand the problem. Hadn’t thought about it.

As an admin, you can cancel a user’s transaction at their request from Wallets -> Transactions.

A user unfortunately cannot cancel a transaction at the moment. It is not feasible for me to develop a solution for this right now. Perhaps something for later on, I am adding it to the backlog for after the wallets6 release.

In the mean time there is this setting:

“Wallets” -> “Cron job” -> “Old Transactions” -> “Cancel old unconfirmed/pending transactions”.

The value is in minutes. For example, if you set it to 60, then any unconfirmed/pending transactions will be cancelled when they are older than 1 hour.

Hope this helps.

with regards

[alexg]

Hello,

Thank you for the additional details. This is a lot clearer.

As you pointed out, this is expected behavior:

A “market sell” order sells against the most favorable buy orders on the orderbook (for more information see here: https://www.investopedia.com/terms/m/marketorder.asp). The price field that you’ve set is for limit orders, but it is not used because you issued a market order.

In the UIs that come with the exchange this would be apparent. But with these modified UI templates, it is not apparent that the price is only for limit orders and not for market orders. This is because the two UIs are joined into one (market sell and limit sell).

I think you should aim to redesign the UI, so that your users are not confused. It should somehow be clear from the UI, that the “price” field is for limit orders only, and that market orders are not related to the price field.

with regards

[alexg]

Hello,

Ah yes, good point, this is somewhat clumsy. However, it works as expected.

The fee in this case is the fee reported by CoinPayments, not the blockchain fee.

I know this is not consistent with other uses of the fee column, but there’s not much I can do about it.

The IPN “fee” is actually “The fee deducted by CoinPayments (only sent when status >= 100)” (see here).

So, in case of CoinPayments deposits, the fee column holds the fee retained by CoinPayments, not the blockchain fee.

For Bitcoin, the platform retains a fee of 0.05%, and therefore the fee of 6000 satoshi is 30 satoshi. This is on the amount remaining after the blockchain fee is paid to the miners.

I guess you could hack something together that, when seeing a deposit, contacts a bitcoin wallet and finds out the network fee for this transaction and replaces this column. But this would be difficult, error-prone, and would only work for a few coins, it would require the ability to contact a different full node wallet or block explorer for each coin, and would require a lot of maintenance. Moreover, it would defeat the whole purpose of using CoinPayments, which is to not use a wallet. This is why the value reported by the IPN is used.

Consider this: Your deposit could theoretically be a transaction to multiple outputs (such as the transactions originating from another exchange). The blockchain fee belongs to the entire transaction, not just your deposit.

Hope this is clear. Let me know if you have any more questions.

with regards

P.S. I am moving this to the CoinPayments forum.

[alexg]

Hello,

I am aware of this issue.

In the upcoming wallets6 the issue with decimals is dealt with more correctly, so the parent plugin will give you more control on this via the admin interface.

In the meantime, check to see how you define your NIMB coin in the wallets_turtle_coins filter. The default is:

		// An sprintf() pattern for displaying amounts. If unsure, leave to '%01.8f'.
		'amount pattern' => '%01.2f',

		// Number of decimal points allowed. If you set this to 2, also set the amount pattern to "%01.2f". For 8 decimals, set the amount pattern to "%01.8f".
		'decimals' => 2,

If you want to modify the number of decimals used for this coin, you should modify both the decimals AND the amount pattern. The amount pattern is an sprintf pattern.

with regards

[alexg]

Hello,

You should have access.

Can you please tell me which download you cannot access?

thanks

with regards

[alexg]

I don’t know. First check the points 2, 3, 4, 9, and 10 above and state clearly what you found on each step, so I know what’s going on.

thank you

[alexg]

Hello,

Even though you say that you have received some deposits and not others, I would still tell you to check this troubleshooting article:

HOWTO: Debug an incoming deposit (CoinPayments adapter)

You can skip checks 1, 5, 6, 7, 8, and 11 which are not relevant to you, since you already had some deposits work. See the checks numbered 2, 3, 4, 9, and 10.

Since there are two deposits that were not confirmed by coinpayments at the time, you wouldn’t see them yet in the plugin’s ledger. This is as expected.

Most likely your friend paid fees that were too low for the current congestion in the Bitcoin network. If the transactions are still not confirmed (CoinPayments requires 2 confirmations for Bitcoin) then maybe your friend can do a replace-by-fee.

TL;DR You should check to see if these two transactions that appear stuck in CoinPayments correspond to your friend’s deposits.

Hope this helps.

with regards

[alexg]

When you get a chance to test with the unmodified exchange, focus on the following:

1. Did you place a limit order or market order? Market orders will not execute unless the entire order can be matched against existing open limit orders.

2. Check the orderbook after placing the order. Also check the user history. Click the refresh button to make sure the data is fresh.

Hope this helps.

with regards

[alexg]

Hello,

I have tested the situation you describe with USD_BTC on my end and the exchange appears to function correctly.

In your example, user A has placed an ask order for 10 BTC at a price of $10, with a total order amount of $100.

User B has $1000 in their balance. The current USD_BTC price is $10. User B clicks on the “max” button in the limit buy form, and then clicks on “limit buy btc”. Α bid order is placed on the orderbook for 100BTC at the same price, i.e. for a total of $1000. The order from user A is filled. User B gives $100 to user A. User A gives 10 BTC to user B. The orderbook now has an unfilled bid order for 90 BTC at a price of $10, for a total of $900.

To inspect the orderbook, see the shortcodes: [wallets_exchange_bids] and [wallets_exchange_asks].

Please check a couple of things:

1. Is it possible that, when creating the markets, you mixed up the base and the quote currencies?

https://www.investopedia.com/terms/q/quotecurrency.asp
https://www.investopedia.com/terms/b/basecurrency.asp

The ordering is different from that of most exchanges, for historical reasons that are hard to change right now. “Buy” means buy the quote currency by paying its value in the base currency, and “Sell” means sell the quote currency and get its value in the base currency.

So let me know if you are certain that you’ve set the base and quote coins correctly. I tested with a “USD_BTC” market.

2. Additionally, I see that you are using modified templates. What other code is modified? What version is your copy of the exchange based on? The latest version is 1.3.7.

I can try to help, but it’s very hard to provide support without knowing what was modified (See FAQ under “I want to do changes to the plugin’s code.”)

3. Is it possible for you to test if this occurs with the unmodified exchange 1.3.7?

with regards

[Author]

Posts