Hello,

First, some background information:

You should not expect the number of addresses to be the same as the number of users. Deposit addresses are generated lazily when users visit their wallets only. A deposit address is assigned a blog_id, based on which blog the user was on when they visited their wallet. Normally the blog_id column is not taken into account for network-active installations (but see below).

There are two issues here:

1. There is a bug in the code that selects data for the admin screens “Deposit Addresses” and “User balances” that only affects network-active installations. Data is filtered by blog id when it shouldn’t. I will be fixing this in wallets version 5.0.13. Please wait until I release the fix later today. Note that the fix only affects the way data (addresses and balances) are shown in the admin screens, it does not actually affect the ledger or balances.

2. Deposits are discovered by the turtlecoin adapter on cron job runs. There is a likely bug in the turtlecoin adapter that prevents the adapter from “walking” the block height upwards. This would cause deposits to not be discovered. I first have to confirm this issue and then will release a fix to the adapter and notify you here.

The first issue affects also the results you get in your other thread. More on that there.

with regards

Hello,

Check to see if your blockchain daemon AND your wallet-api are synced to the highest block.

If they are not, then your transaction would not show.

If the deposit address you sent funds to was generated by this ARMS wallet (whether via the plugin or by other means), then the wallet will eventually include the transaction once it’s synced.

with regards

Not sure. These are questions best directed to the TurtleCoin developer.

Are you certain that your wallet is synced (not just the blockchain daemon)?

Once the transaction shows up in your wallet but not reflected in the plugin, then this will be likely due to the bug that I am about to fix in the next patch release of the coin adapter.

with regards

Hello,

Ah! OK, thank you.

Even though the hot wallet balance is 22 ARMS, the user balance should be the sum of the user’s transactions, as they appear in the plugin’s ledger (Wallets -> Transactions).

It’s good to see that your wallet appears synced. I will upload today a patch where, if logging is enabled, the coin adapter will write to the logs the block height of the network, the wallet, and the coin adapter. While both the network and wallet heights are 0 it will also emit a warning that the wallet may not be syncing. This will hopefully help others trying to setup the adapter.

The reason that the deposit is not going through is that, as you say, there is a payment ID. For Monero transactions, the CoinPayments platform uses only one address for all Monero deposits, and distinguishes between its users via a payment ID. Therefore the plugin has to check the Payment ID too before determining that a deposit belongs to a user. You should instruct your users not to use a payment id for now, because it’s always considered part of the address, and this is true for all coins and all deposits.

I don’t consider this to be a bug. In many major exchanges, if you send coins with the wrong Payment ID, your deposit will not be debited to your account. Users should deposit to the address they see in the [wallets_deposit] UI. If they add a payment ID that is not shown in the UI, it’s as if they were sending to a different address. This is something that users should expect, but ideally you should warn about this in the deposit UI. If you want to output custom HTML over or under the deposit UI, you can use the actions: wallets_ui_before_deposit and wallets_ui_after_deposit.

In the upcoming wallets6, the architecture is inverted to improve on this: The wallet adapter itself creates the deposit and passes it to the plugin’s ledger. So each wallet adapter can decide how to match the address of the incoming deposit against known deposit addresses. The wallet adapter can then decide whether to match the payment ID, or just the base address, thus giving finer control to the adapter developer.

Your cron jobs are likely running or you wouldn’t have seen the first deposit either. The fact that your first deposit is discovered and is shown in the plugin’s ledger means that the plugin is behaving as expected.

Please let me know if you have any more questions or if you spot any other issues.

with regards

EDIT: The latest version 0.1.5-beta of the coin adapter only has better logging, it should behave the same as 0.1.4-beta (Logging must first be enabled in wp-config.php)

I see. Maybe you could reserve a different address altogether to track the mining rewards?