hot
, warm
, or cold
).To investigate the problem, the admin needs to check the status of the deposit on the Etherscan. If the deposit was successfully recorder on the Ethereum blockchain, the admin needs to compare the block height of the platform's node with the block height from the Etherscan. If the platform's node is unsynchronized, it means that the platform can not see new deposits and can't collect existing deposits. In that case, the admin needs to wait the node to synchronize. If the platform's node is fully synchronized and the deposit still not collected it means that something happened with the node during the deposit collection process.
In case, when the deposit recorded on the Ethereum blockchain and the platform see that deposit but it still is not collected, the admin can manually reinitiate the deposit collection process by pressing Collect
or Collect with fee
button.
auth.permission.invalid
error. The first thing you should do when the auth.permission.invalid
error appear is to check permissions for type of users that you want to have possibility to upload document. Depending on endpoint you are using to upload document permissions may vary.
Example: - { role: member, verb: all, path: api/v2/barong/resource, action: accept }
If error is persisting this might be a bug in nginx
, to work around it you should add another permission in addition to the previous one.
Example: - { role: member, verb: all, path: api/v2/resource, action: accept }
In case you have just redeployed to a newer versions with breaking changes you would want to clear cached permissions from the Barong container with next commands:
docker exec -it barong_container_1 bundle exec rails c
Rails.cache.delete('permissions')
400 Bad request
encryption key not foundFrom Peatio 2.4.0 Development mode of Vault does not supporting and you will need to follow the OpenDax Read me to setup Vault in Production mode (https://github.com/openware/opendax):
1. Change the `development` to `production` of Vault in app.yml
2. Start Vault `rake service:backend`
3. Perform next commands in console:
* `docker-compose exec vault sh`
* `vault operator init`
4. Save the output to a safe/secure place
Example of needed output:
```Unseal Key 1: 1UJw7sR98B6zGNwibegN2HQNCY/xewp3ycKeLCVS2VY0
Unseal Key 2: pGCc3bfNirg0tfVF3C73/PQ7JAtCCoY2Tsns/R+yzneR
Unseal Key 3: 38WOPLoywr+aIU0fcJuvSh4pm2hTt57NWCkjUecXr7ga
Unseal Key 4: jkag9sRu2yUb1i+YMS1oN8czEtYnQg6aS8x4EwPmBiKS
Unseal Key 5: VjPWSRIHxQP4UQWomIRSSWtfqxdD76Uv+vxCNl2qa/Uv
Initial Root Token: s.7u4s5YdP1QgGPZbu02wOvJag```
5. Unlock Vault with three different unlock keys by repeating next command in console - `vault operator unseal *unseal_key_1*`
6. Perform next commands in console:
* `vault login *initial_root_token*`
* `vault secrets enable totp`
* `vault secrets disable secret`
* `vault secrets enable -path=secret -version=1 kv`
* `vault secrets enable transit`
7. Add Vault Initial Root Token in `app.yml`
8. From this point Vault is setup in Production mode and you can run everything else by `rake service:all`
Keep in mind that in Production mode Vault will require Unlocking after each restart (step 5)
Non-platform checks
Try to verify that deposit was recorded on a blockchain. To check that you will need one of the next details about the deposit:
(e.g. Ethereum address 0x8EdE0c173A128727e219D57447dC012f43d159D6)
(e.g. Ethereum transaction ID 0xf92e4070f29eb4e47664e81c06d69db71ddaa103296c08dbaebcc3194ca6d791)
When you get an address or transaction ID, go to the official or the most popular blockchain explorer of the corresponding currency. For example, for Ethereum and ERC tokens it can be Etherscan and for Bitcoin it can be Blockchain.
Cases:
Case 1: If you search for an address or a transaction ID in a blockchain explorer and a search result shows no record of the expected deposit that means that deposit failed in blockchain. Be careful, check the type of blockchain network you are searching for a deposit. In the majority, it should be public mainnet network.
Case 2: If you search for an address or a transaction ID in a blockchain explorer and a search result shows a transaction with status pending (pending transaction is a transaction that is located in a pool of unconfirmed transactions and waiting to be validated and recorded in a block) it means that you need to wait for the transaction to be recorded into a block. Be aware that a transaction can stuck in the pool of unconfirmed transaction for a while. That can happen due to network overload or due to a very small transaction fee. Also, you should know that Ethereum transactions have an order system. When you send transaction and it gets stuck in the unconfirmed pool the next transactions in the pool will also stuck until the earlier transaction will be recorded in the block.
Case 3: If you search for an address or a transaction ID in a blockchain explorer and a search result shows that a deposit transaction was recorded in a block it means that the platform hasn't recognized the deposit and requires further investigation from the platform side. Be aware that deposits of Ethereum that is made with the use of smart-contract (internal transactions) won't be recognized by the platform. For Ethereum, the platform works only with regular deposits that don't use smart-contracts.
Platform checks
The first thing to check on the platform if a blockchain node is synchronized. Open Tower admin panel and go to the Settings
module, in the Settings
module choose the Blockchains
menu. From the list of blockchain nodes open profile page of the target blockchain node. Compare the block height (block number) from the field Height
in Tower with block height from a blockchain explorer.
If the block height in Tower is not increasing that means that something happened with a platform's blockchain node. The technical investigation is required.
If the block height in the Tower is significantly delayed but it keeps increasing that means that admin user needs to wait when the node is fully synchronized. After full synchronization of the platform's node admin can do check from the case when a node is synchronized.
If the block height in the Tower is almost the same (it will always display latest block - min confirmation
blocks number, so if in Tower block height is 5000 and Min Confirmation is 6, your current block is 5006) as a block's height from a blockchain explorer it means that node is healthy and keeps synchronizing. In that case, an admin can rescan blockchain from the block with deposit transaction minus 5 blocks.
If you see a deposit on a blockchain explorer, but it's not visible on the platform, check the min deposit amount
parameter in the currency settings.
If the deposited amount is equal or lower than min deposit amount
the platform skips it on purpose.
In the case of ECR20 check the smart-contract address to ensure that you are sending the right token to a correct wallet in the right network.
If after that deposit still invisible for the platform that means that technical investigation is required.
Technical checks
Check if deposit wallet exists.
Try to verify that a deposit address exists on the platform and belongs to the platform's user. To do that you must have access to Peatio Rails pod and to run the next command:
PaymentAddress.find_by(address: "wallet address")
Example when a searched deposit address exists in a database:
Example when a searched deposit address NOT exist in a database:
If a deposit address doesn't exist on the platform, it means that deposit was sent to some non-platform wallet.
Check the logs of a blockchain node
To check blockchain logs of Opendax deployment, use the next command:
docker-compose logs -f blockchain
Restart blockchain daemon
To restart blockchain daemon of Opendax deployment, use the next command:
docker-compose up -Vd blockchain
Don't forget to restart blockchain daemon whenever a new currency or blockchain was added to the platform. Also it is required to restart blockchain daemon, after all changes in the currency's settings.
In buy market order, due to its flouting price and expectations of alive market, the amount of expected balance (to be locked) is increased by 1.1 to increase chance to perform successful market order. So to perform a buy order with volume 0.1 user should actually have 0.1*1.1 = 0.11 .
Note: This rule applyed only for Buy side market orders.