- 1 Introduction
- 2 Overview of cxAdmin
- 2.1 Dashboard
- 2.2 Customer Overview
- 2.3 Liquidity Options
- 2.4 Markets
- 2.5 Reports
- 2.6 Balances
- 2.7 Currencies
- 2.8 Configuration
- 2.9 Security Configuration
- 2.10 Email CMS
- 2.11 Admin Tab
- 2.12 Maintenance
- 3 Use Cases
- 3.1 Use Case: User support request
- 3.2 Use Case: Look up customer details
- 3.3 Use Case: User withdraw request
- 3.4 Use Case: deep-freeze process
- 3.5 Use Case: Defrost request
- 3.5.1 Step 1: Receiving defrost request notification
- 3.5.2 Step 2: Chose cold storage to defrost
- 3.5.3 Step 3: Move funds from cold storage address to hot wallet
- 3.5.4 Step 4: Verify redeem key
- 3.5.5 Step 5: Create transaction
- 3.5.6 Step 6: Verify transaction script
- 3.5.7 Step 7: Vault keepers sign transaction script
- 3.5.8 Step 8: Broadcast the signed transaction
- 3.5.9 Step 9: Recreate paper wallet
- 3.5.10 Step 10: Insert new paper wallet into cxAdmin deepfreeze
- 3.6 Use Case: User deposit
- 3.7 Use Case: Create new market
- 3.8 Use Case: Edit market
- 3.9 Use Case: Configure market maker
- 3.10 Use Case: Create off-market deal
- 3.11 Use Case: Colored coin assets
- 3.11.1 Step 1: Introduction
- 3.11.2 Step 2: Backup your wallet
- 3.11.3 Step 3: Send Bitcoin to your Coinprism account
- 3.11.4 Step 4: Create a new assets
- 3.11.5 Step 5: Fund the asset
- 3.11.6 Step 6: Issue coins
- 3.11.7 Step 7: Create asset on your exchange
- 3.11.8 Step 8: Send assets to your exchange's market maker account
- 3.12 Use Case: Accept payments as merchant
- 3.13 Use Case: POS payment
- 3.14 Use Case: PayPal Setup
- 3.15 Use Case: KYC Setup
- 4 Use case: Managing customer KYC levels
- 5 Email encryption
Welcome to cxAdmin, the admin interface of the bleeding-edge cryptocurrency exchange software from skalex. This manual will help you to understand how the back end processes of our exchange software work and what you have to do to effectively run the exchange and make your customers happy.
We will first give you an overview of the cxAdmin interface and will show you what each section of the admin console looks like and what functions it contains. All processes that need your operative attention will be broadly described as Use cases and you will understand how the cxAdmin responds to user actions and how you can handle the user’s requests.
cxAdmin will help you to comfortably administer your skalex exchange and it allows you to interact with and to administer other skalex modules. cxAdmin is the only module the legal operator (you) directly interacts with, thus this is the only manual.
Overview of cxAdmin
We will give you an overview of the cxAdmin console first. You will see what areas are available and what they contain. In case you want to look at the processes in particular, you should go to the section Use cases.
When you log in to the cxAdmin console, you will start with the dashboard. It gives you an overview of your operative exchange requests.
Hot wallet status: Here you can see the amount of crypto funds that are stored in your hot wallet. At a glance, you are able to see the filling status, also giving you information about the configured thresholds of each cryptocurrency. The threshold attributes are explained in the currencies section.
The figures next to the Hot wallet status (in this example “(0/0)”) is an indicator for the current liquidity of your hot wallet, as the first figure describes the amount of wallets with too few funds and the second figure the amount of wallets with too much funds.
(0/0) means: There are 0 wallets (or cryptocurrencies) in the state “Critical wallet underrun” which means that no transfers are suspended. Suspended transfers will be shown in the next tab and occurs when a withdrawal exceeds the current account balance of the hot wallet. The administrator would then be notified to clear a deep freeze storage.
(0/0) means: There are 0 wallets (or cryptocurrencies) in the state “Critical wallet overrun” which means that the defined, maximum threshold of the hot wallet has been exceeded. This happens when all deep freeze storages are completely filled. The administrator will then be notified to create more deep freeze storage addresses so the system can automatically put the exceeding funds into multi signature cold storage.
Suspended transfers: If requests show up here, a hot wallet underrun occurred: a user wants to withdraw more Bitcoin (or another Alt coin) than is currently available in the hot wallet. A suspended transfer is the result, telling you that you have to “unfreeze” Bitcoin from the cold storage and put them in the hot wallet in order to enable the user to withdraw his full amount of funds. The deep Freeze process is described as a separate process. The defrost request process is described as a use case.
Withdrawal requests: Here, you will find all requests from exchange users that want to withdraw fiat money (for example: USD, EUR or GBP). Every request will be listed and can be clicked in order to see the details and to mark the request as done.
Support requests: In this tab you see all support requests that were entered by users. By clicking on the support request you will see the chat history, containing the last problems the user reported to your support team. You can also mark single or all conversations as done, so it will not be shown as an active support request anymore.
If the "unconfirmed trades" feature is implemented on your exchange, you will have a slightly different dashboard. Unconfirmed trades is the feature that requires each trade to be manually confirmed by the administrator before the actual execution happens and both parties will receive the content of the trade.
It contains the "Unconfirmed trades" queue that contains all trades that need to be confirmed by the back office employee. This queue provides detailed information about every trade, such as:
- Order # (The order ID)
- Execution # (The execution ID)
- Seller (User ID of the seller)
- Buyer (User ID of the buyer)
- Type (The type of the currency that was traded)
- Quantity (The nominal of the trade)
- Price (The average limit of the trade)
- Date (When the trade was initiated)
The administrator can then either confirm the trade (by clicking on "confirm") or revoke the trade (by clicking on "revoke"). Until the administrator confirms the trade, it will be shown as "trade not confirmed" (and a spinning arrow) for both parties.
If a trade is confirmed it gets finally executed and both parties receive the traded goods booked on their account balance. Revoking the trade results in the trade being cancelled for both buyer and seller, and they receive their initial offer back (showing as revert).
In the Unconfirmed trades queue you can use the filter to make a selection of only specific trades, e.g.:
- Order #: Show only the trade with a specific order number.
- Execution #: Show only the trade with a specific execution number.
- Seller: Show only the trades of a specific seller.
- Buyer: Show only the trades of a specific buyer.
- Type: Show only specific currencies.
- Date: Show only trades from a specific period.
The customer overview gives you a list of all customers that are registered on your exchange. When clicking on a customer in the list, you will see his customer details. This will help you to see the relevant information about your customers.
When clicking on the customer menu item, you will get an overview of all registered customers on your exchange. You can either filter by username, or more reliably (because it is the main identifier) by e-mail address. The list will give you an overview of the ID, the username, the email address as well as last login and the creation date of the account.
When clicking on a customer you will see his details:
The customer details are sorted in different tabs:
Basic data: This shows the username, preferred language, activated flag (did the user activate his account, did he click on the link in the confirmation email?), deleted flag (did the user delete his account?), newsletter flag (did he accept the opt in to receive newsletters?), Google Authenticator seed (did the user add a Google Authenticator flag) and secret flag (which is required for withdrawals of crypto funds).
Accounts: Here you have an overview of all fund accounts that the user owns. You will see each currency as well as the user’s current balance. You can filter for particular accounts and see a history of the particular currency accounts. The transaction history lists every deposit, withdrawal, trade or trading fee. You will also see if a change on the account has been performed by an administrator of the cxAdmin console.
You can also export the transaction of each customer after the relevant filters have been set. The export can either generate .CSV or .XML files. All entries will be exported independent from your selection how many lines you want to see in the admin interface.
Fiat Crediting: The fiat crediting tab enables your back office administrators to increase or decrease (credit or debit) the account balance of fiat currencies. By clicking the fiat crediting tab of a user, you can select the currency and insert a value that should be either added to or subtracted from the user account. Also, a note can be added that will be shown in the user’s account history.
Fiat withdrawals: Here you will see all open fiat withdrawal requests. When open fiat withdrawal requests exist, you can click on them and set them as done as soon as you manually wired the money transfer to the user’s bank account.
Support: This tab shows the open support requests. You also can see a full history of the chat between the support employee and the particular user. "You can either set individual requests as handled by clicking "Set handled" below the respective user request, or mark all the user's open requests as handled when replying, by marking the checkbox "Mark all messages as handled". By checking "Send e-mail to user", your reply will be sent as e-mail, additionally to being shown in the user's support view."
Export of customer data
In the “Customers”-menu you may use the “Export to csv” option to export your customer data.
The data of your customers can be exported as .csv file for additional processing, such as sending newsletters or simply generating an overview of your current customer base. To export your customer data, you can make a selection by using different attributes:
Only confirmed: This selects customers user that have confirmed their e-mail address.
Only KYC verified: This limits to customers that have been KYC confirmed.
Only with newsletter request: This limits to customers that have requested the newsletter when registering on the exchange site.
The exported .csv list will contain following columns:
Any additional information such as Firstname, Lastname etc.
If your exchange has certificates implemented, you will also see the "Certificate crediting" tab.
This allows to directly creddit certificates to a user. Select the type of certificate, the amount of certificates to credit (or deduct).
Then click on the "Credit certificates" Button to make the changes. You will receive a notification.
An exchange operator faces the problem of negative network effects. Without orders in your recently started exchange, traders are not motivated to register and start filling your order book with bids and asks. By using one of the multiple liquidity options provided, the growth of your exchange can be boosted.
Market makers facilitate a very simple solution of providing liquidity on your local exchange. The exchange can receive current prices over a ticker and use this reference price to fill the order book. While some currencies do not provide reliable exchange rate tickers, the exchange administrator can manually set an exchange rate in cxAdmin. Market makers will use their available funds to create orders as configured, while takers will randomly create executions as configured.
External liquidity provider
You can connect your exchange to another, external exchange via the API. After you created an account on this external exchange, deposit a certain amount of funds. This amount defines the orders that will be pulled from this external exchange order book and displayed on your local exchange. You may also specify a spread percentage that allows you to further monetize this feature. If a user on your local exchange wants to match the order from the external exchange, this will be done after a matching confirmation from the external exchange has been received.
Distributed Shared Orderbook
The DSO allows you to publish your orders on more than one external exchange. You may tap into a network of multiple exchanges and broadcast your orders on other exchanges while drawing liquidity into your exchange. This allows you to act as taker on local orders that have been received by other exchanges or as maker on other exchanges. When using the DSO, you will need to create an account with Trust Deposit UG at (https://www.trust-deposit.net) and deposit a credit line there.
You can administrate the available trading pairs by using the market section in cxAdmin. Here, you can pause or resume markets as well as edit their settings such as minimum nominal or the trading fee. You may also create new markets (trading pairs like BTC/USD is a market) by using the “create” menu and entering the needed details.
The market overview will also give you additional information of external liquidity that flows in your market or if your market publishes orders also on other markets or exchanges via the DSO. There are three ways to provide liquidity:
- Market Maker
- Liquidity Provider (can be seen as in the overview)
- Distributed Shared Orderbook (in short DSO, can be seen as
in the overview)
- : Start a market. Market must currently be stopped so you can start it.
- : Stop a market. Market must be running so you can stop it.
- : Edit a market configuration. Described in "Edit Market" use case.
- : Delete a market. Market must not have any trades in the past so you can delete it.
- : Configure the market maker of a market. Must have market maker add on so you can use it. Described in "Configure market maker" use case.
- : Create an off-market deal. Must have off-market deal implementation so you can create an off-market deal. Described in "Create off-market deal" use case.
The fee structure of the cxSuite exchange can be freely defined. Administrators have the choice of various fee models:
- Maker/Taker: Define the fees depending on the fact that one trader is a maker and the other one is a market taker.
- Buyer/Seller: Define the fees depending on who is the buyer and who is the seller. Can be found in the section "Activate market" use case.
- Nominal/Limit: Select the currency in which you want to generate the fees. You can set fees on both currency sides to receive both (e.g. 0.1 in nominal and limit will generate 0.1% fee on both sides).
Nominal and limit settings
You can edit a market to set certain nominal and limits.
- Buyer minimum nominal: Set a minimum nominal that buyers need to enter. Described in the "create market" section.
- Seller minimum nominal: Set a minimum nominal that sellers need to enter. Described in the "create market" section.
- Minimum limit: For each market, you can set a minimum limit. Setting this limit to e.g. 0.5, the exchange will not accept orders with a price below 0.5. Described in the "create market" section.
The "Report" section of the admin interface allows you to get a good overview of whats happening on your exchange. Most reports allow to navigate to the involved customers or orders when clicking on the customer ID or order ID (displayed in blue).
The Orderbook report shows you all orders that are currently available on your exchange or have already been executed. You can specify order numbers or filter after various attributes:
- Order #: the number of the order you are looking for.
- Market: Filter after a specific market.
- Type: Filter after the type of the order (Buy or Sell).
- State: You can filter following states:
- Open: Show only open orders.
- Executed: Show only executed orders.
- Cancelled: Show cancelled orders (These are revoked orders and not orders cancelled by the user itself).
- Paused: Show orders that are paused (These are orders that are open but the customer does not have enough account balance - allowed by Optimistic Fund Locking).
- Matching: Show orders that have been confirmed by the administrator and are in the process of being matched. (If you have the trade confirmation enabled on your platform).
If you have off-market deals enabled on your platform, you will also see following states:
- Off-market pending: Off-market deals that were created but not confirmed by the other user. The pending state will be shown for the user that has created the off-market deal.
- Off-market requested: Shows the off-market deals of users that received those.
- Off-market rejected: Off-market deals that were rejected by the receiving user.
You can cancel specific trades by clicking on the X that is next to this order:
A popup will ask you to confirm the cancellation of the order:
After the order was cancelled, you will receive a confirmation.
The executions report gives a broad overview of all executions that happened on the exchange. You may define filters and export the result after filtering to CSV by clicking on "Export to CSV".
Following filters can be used:
- Execution ID: The ID of the execution.
- Buyer: ID of the buyer
- Seller: ID of the seller
- Buy order ID: ID of the Buy order.
- Sell order ID: ID of the Sell order.
- Nominal currency: Filter after the nominal currencies to display only certain market executions.
- Limit currency: Filter after the nominal currencies to display only certain market executions.
- Nominal: Amount of nominal of the order (can not be filtered but sorted).
- Rate: The rate of the trade (can not be filtered but sorted).
- Price: The price of the trade, which is nominal * rate (can not be filtered but sorted).
- Execution time: Put in a time, either a day-month combination such as 03-20 (which is 20th of May) or a time such as (13:28, which is 1:28 pm) to filter executions that happened exactly at this point of time.
The Transactions report helps you to get an overview of the transactions (e.g. deposits and withdrawals) that have been done on your exchange. After filtering you can export the report as CSV (click on "Export to .csv"). Following filters are available:
- Customer: Show transactions of a specific user.
- ID: Show a specific transaction ID.
- Credited: Select "uncredited only" (e.g. Bitcoin deposits that did not receive the necessary amount of transactions yet) or "credited only".
- Created: Filter after the creation time of the transaction.
- Account: Filter after the currency.
- Type: Filter after the type of the transaction:
- Trade: Show only the trades.
- Trade fee: Show only the trading fees.
- Transfer: Show only the transfers.
- Transfer fee: Show only the transfer fees.
- Redeem: Show only the redeems of a user.
- Value: Sort after value (no filtering possible).
- Description: Filter after certain descriptions (e.g. Deposit).
- TxID: Filter after specific transaction IDs from the network.
- Admin: Filter after specific administrator names (e.g. search for "Joe" if you want to see all transactions that have been done by the administrator Joe).
The balances tab displays the user balance for each currency listed on the exchange. Data can be filtered by user ID and KYC level and can be sorted according to the User ID KYC level and according to the user balance for each currency. This data can be exported in csv format.
This gives you an overview of all currencies that are implemented in your exchange.
Every currency has a list of attributes that can be edited and effect the behavior of this currency:
*Currency ID: The Identifier of the currency. For example: BTC
*Currency Name: The name of the currency: For example: Bitcoin
*Type: Can be either Fiat, crypto currencies or crypto assets. Please see below for the description of each currency type.
*Sort: You can sort the currencies. The currency with sort 1 will be shown as first in the account page of the user, the currency with sort 2 will be shown second etc.
*Actions → edit: This allows you to edit each currency. Depending on the type, the currency has different edit options.
There are different types of currencies that have different attributes:
Crypto: A crypto currency like Bitcoin or Litecoin and needs an additional set of attributes that can be chosen for each crypto currency:
- Wanted confirmations: Amount of confirmations by the network that are needed before the user account balance will be updated.
- Minimum Threshold: Defines the minimum balance that needs to be held in the hot wallet at any time. If the hot wallet contains less funds than defined by minimum threshold and minimum tolerance, a hot wallet underrun occurs, prompting the exchange operator to unfreeze deep freeze storage, until at least the minimum threshold is reached.
- Minimum Tolerance: Defines the percentage, which the hot wallet balance may fall below the minimum threshold, before action must be taken by the vault master. When the current filling status is between the minimum thresholds but in the defined tolerance, the hot wallet status is “low wallet”.
- Maximum Threshold: Defines the maximum amount of crypto funds that may be stored in the hot wallet. When the system swaps away funds from the hot wallet to deep freeze storage, it will do so until the hot wallet balance is at the maximum threshold.
- Maximum Tolerance: Defines the percentage, which the hot wallet balance may reach above the maximum threshold, before the system will swap out to deep freeze storage. Setting the Maximum threshold to 10 and giving 10% maximum tolerance means that if 11 crypto tokens are in the hot wallet, 1 crypto token will be swapped to deep freeze, so the amount of crypto tokens stored in the hot wallet equates the maximum tolerance of 10.
- Deep freeze transfer fee account: Moving crypto currencies from hot to cold wallet (and vice versa) requires transaction fees for the network. This account will provide the funds for the transaction fees and will be subtracted by the amount of missing funds from the defrost process.
- Deposit text: Here you can edit the deposit text that will be shown for users that want to deposit this particular fiat currency on your exchange banking account. You can have different deposit texts for each fiat currency and also put in tokens that will be processed before the text is displayed to the users. This gives you the opportunity to allocate the payment of the user by using specifically generated reference codes.
Cryptoasset: Assets that can be created, funded and issued on Coinprism.com and then transfered to the exchange to be traded.
- Asset ID: After the CoinPrism asset has been created, you will receive an Asset ID. Put this Asset ID in the currency definition field so the exchange can accept this particular type of currency.
The configuration panel lets you edit basic settings for your exchange.
mailFromEmail: System emails will be sent from this email address. This includes registration confirmation emails and emails for password reset. This does NOT include the sending of support emails!
mailFromName: This is the name for the sender of the system notifications such as register confirmation or password reset emails.
mailToSupport: This attribute defines the email address for receiving support requests.
mailToTech: This will be the receiving address for emails that are sent from the system for technical notification purposes. Only skalex will receive technical notification emails that inform about the technical performance of your exchange.
mailToVaultmaster: Here you can put in the email address of the vault master. He will receive the notification emails given the case that one of your crypto fund hot wallets has a change in status. For example, if a user wants to withdraw more Bitcoin than are available in the hot wallet, you will receive a message that tells you that the Bitcoin transfer has been suspended and you need to clear wallets before the user can receive his withdrawal.
merchantSysUser: The merchant payment module requires you to set up a merchant system user that provides liquidity for merchants that use the No Risk option. Put in the email address here.
merchantFeeNoRisk: This field contains the % fee for merchant payments with the “No Risk” option.
merchantFeeRisk: This value defines the % fee for the merchant payment option “Risk Option”
merchantFeeSellRisk: This field contains the % fee for merchant payments using the “Sell Risk Option”
merchantTimeout: The number of seconds to wait until the merchant payment timeouts.
notifyKYCUpload: If this is checked, the exchange operator will automatically receive a notification email every time a user uploads new KYC documents.
notifyRegistration: This setting will automatically send the operator an email every time a new user successfully registers on the exchange.
notifyWithdrawal: Check this setting to receive emails every time a user wants to withdraw money (for manual banking wire).
If you have implemented the functionality of expiring assets on your exchange there are two additional fields:
expireAssetsAfter: This attribute defines the time how long an asset is valid. Put in the value in the formats "1y" (one year validity), "1m" (one month validity) or "1d" (one day validity).
expireAssetsWarnBefore: Before assets expire you can automatically send the owner an email. Put in the period in the format "1y" (one year after asset was created, the user receives an email).
There are two additional email templates to be edited in the "Email CMS" section:
- Your assets are about to expire: This email will be sent to the user depending on the configuration of the "expireAssetsWarnBefore" variable.
- Your assets have expired: The user will receive an email notification telling that assets have expired, depending on the configuration of the "expireAssetsAfter" variable.
Set to an integer followed by a letter. The letter is:
- y - years
- m - months
- w - weeks
- d - days
- h - hours
- i - minutes
- s - seconds
In the Security Configuration section, Admin can set compulsory 2FA (2 Factor Authentication for all users)
Email 2FA can be set for all users while Google Authenticator can be set only for users who have activated Google Authenticator by seeding the key to their phone.
The “CMS” section offers to change the content of emails which are automatically sent by the exchange, such as registration emails for users that create an account.
Every email consists of two parts: the template and the content.
Click on “E-mail templates” to edit the salutation, the valediction and the signature. Content of emails can be edited at the “E-mail content” section.
You can use the filter to select certain languages or “Idents”. Idents are events such as “Password change”, “registration” or “welcome mail”.
If you want to edit all English E-mail templates, choose “English” and then pick the relevant E-mail content from the filtered list:
Either click on the edit button to edit content or use the preview (click on the eye signal) to have a read-only access to the E-mail content.
After editing, you can click on “Apply” to quick save your changes while staying in the editing mode. If you want to save the changes and close the editor, click on “Save”.
You will receive a confirmation after the new content has been saved:
Multiple admin users can be created for accessing the admin panel with specific privileges for each of them.
User groups are created by defining the different privilege/rights for that group and the users are assigned to that group.
The Export/Import function allows system settings to be exported from the platform and then imported into a new system setup.
Main Switch allows you to bring all exchange activity to halt.
User login, trades, withdrawals, everything comes to a halt if exchange is switched off.
Use Case: User support request
This use case handles the support handling of the skalex crypto exchange. Users use the support tab in the skalex exchange software to create a support request by simply typing into a chat form. The back end operator will see a new support request in the dashboard and can click on it to respond to the user support request. The exchange user will then see the reply in the same support chat.
Step 1: User initiates support request
The user is logged in on your exchange site and has a problem that needs the attention of one of your back office agents. He initiates the support request by going to the support tab and by entering a chat message. Hopefully, he states the problem in a clear manner so the support employee is able to allocate the problem and respond adequately. He simply enters the text in the support chat and then clicks on “Send” and the message is stored in the exchange system.
Step 2: Back office agent sees new support request
After the user submitted the support message, the back office agent can see the new support request on his dashboard under “support requests”. When he clicks on the username he will see the support request.
Step 3: Fix problem with cxAdmin
After your back end operator clicked on the username, he is able to see the support history that contains the new support request. It might contain some relevant information that is connected to the user’s problem.
Now your back office agent is able to see the support context and act adequately. He can browse through the tabs of the customer to effectively help the user and to process the support request.
After the problem is fixed, the next step is to notify the user by entering the response text in the “send message” field.
Step 4: Notify user
“Mark all messages as handled” will remove the support request from the stack that is shown on the dashboard. By clicking the “Send mail to user” checkbox, the respective user will also receive an email with the response text in it.
After clicking on „send“, you will receive a notification that your support response was accepted.
Step 5: User sees notification and is happy
Use Case: Look up customer details
Master data of users can be looked up by accessing the cxAdmin “Customers” area. After clicking on the customer area, you will see a search filter for users. You may search either for the username or the email address of the user. In the results list you will see the username, email address, last login and registration date. When clicking on the user, you can see the details that are broadly described in “customer overview”.
Step 1: Enter Customers area
You now have an overview of all current customers that are registered on your exchange. You may see the ID, email address as well as last login and the date when the account was registered. You may also sort the user list according to one of these attributes.
If you are searching for a user in particular, you can use the search field for either the user name or the email address. You may also combine name and email address for more exact search results.
Step 2: Enter customer data to search
Now you have to enter the search data for the user you are looking for. When you entered the details, you can now click on the “Search” button.
After the search was completed, you will see the results below:
You can now click on the customer to show the details.
Step 3: Click on the customer to show details
After clicking the name of the customer, you will be able to see numerous details which are described in the overview section.
Use Case: User withdraw request
When a user wants to withdraw fiat money, he needs to go to the exchange account and click on “Withdraw <fiat currency>”. He then can enter an amount of currency that he wants to withdraw so that it will be wired to his banking account. After he submitted the withdrawal request, it will be shown on the cxAdmin dashboard of your exchange. Your back office agent then is supposed to click on the request and verify it. After verification, the back office agent can then wire the money to the banking account of the user. The user will receive his money in the banking account and is happy.
Step 1: User wants to withdraw money
The first step of a withdraw request is a customer that wants to withdraw fiat money from his exchange account. Please notice that the user has to be verified first (go through the KYC process) before he can withdraw funds in case your exchange has the standard configuration regarding KYC. He goes to account and clicks on withdraw. He then has to enter the amount that he wishes to withdraw. After he clicks on “withdraw”, the withdraw request will appear on the cxDashboard.
Step 2: Withdraw request will be shown in cxAdmin
Step 3: Back office agent sends wire transfer
The back office agent can see the amount of the withdraw request under “Fiat withdrawals”. He is supposed to then manually wire the sum to the user’s account. He is able to see the bank information of the customer under “Base data”. It is advisable to check each wire with the “dual control procedure”, meaning that one back office agent has to start the wire and the other one has to check/verify it in order to avoid errors.
Step 4: Back office agent closes withdraw request
After the wire has been sent, the back office agent can close the withdraw request. He can do so by clicking on “set done”. After he marked the withdraw request as done, it vanishes and will no longer be shown in the dashboard.
Step 5: User receives money on bank account
The user now receives the money on his bank account and is happy.
Use Case: deep-freeze process
The deep-freeze process works not only for Bitcoin but for any alternative crypto currencies. Not every alternative crypto currency supports multi signature, so deep-freeze may require operation without multisign. The deep-freeze process will check if the balance stored in the hot wallet exceeds a certain threshold. If so, it will automatically swap Bitcoin (or any other Alt coin) from the hot wallet to the multisign paper wallets.
Before being able to use the deep-freeze feature, you will have to create addresses – or paper wallets. Depending on the size of your exchange staff, you can either appoint 3 or fewer vault keepers. Vault keepers are responsible for the management of the private keys which are needed for unfreezing the coins from the cold storage. A vault admin is needed in every case; he coordinates the unfreezing of the coins by mailing the public keys, multi signature addresses as well as redeem scripts for the unfreeze process. When you have 3 vault keepers, you will create multi signature addresses with a 2 out of 3 procedure. This means that you need two out of three vault keepers to initiate the unfreezing of the coins. After each vault keeper created 20 paper wallets, they will be used to generate multi signature addresses that can be used for storage and unfreeze.
Step 1: Create vault keepers pub keys
Your vault keepers (the vault admin being one of them) create 20 paper wallets each. We only need the pub keys (uncompressed public keys from the address) so we can generate multi signature addresses. The paper wallets can be generated on https://coinb.in/multisig/ or https://yourexchange/multisig:
The pubkey will be sent to the vault admin so that he can create the multi signature addresses. The private keys need to be printed on a separate, numbered paper each. After the 20 pub keys from each vault keeper were generated and sent to the vault admin, the private keys are stored by each vault keeper.
The vault admin can now use the pub keys from the vault keepers to generate the multi signature addresses.
Step 2: Create multi signature addresses
Go to https://coinb.in/multisig/ and click on New and then “Multi Signature Address”. Now you can start creating your first multi signature address.
This is the process for three vault keepers: You should now have the list of the 20 pub keys of each vault keeper as email. Put in the first pubkey from the first vault keeper into the first field, then put the first pubkey from the second vault keeper in the second field and finally put the first pubkey from your third vault keeper in the third field.
Leave the “amount of signatures needed required to release the coins” at amount “2”, because we want a 2 out of 3 authorization where we need two out of the three vault keepers in order to unfreeze the funds.
Address: This is the address of the first address you generated from the pub keys of your vault keepers. The skalex exchange software will automatically send funds to this multi signature address, where your vault keepers will be able to redeem the coins to fill the hot wallet.
Redeem Script: Send this script to all vault keepers. They need to save this for the time the first defrost action needs to be taken. Commence with this address generation until you used all 20 different pub keys from each vault keeper to create those 20 multi signature addresses as well as redeem codes. The next step is to insert the addresses into cxAdmin.
Step 3: Information management
Now it is important that every vault keeper saves the 20 multi signature addresses together with the public keys of every vault keeper, his own private keys and the redeem scripts. In the case that any of the vault keeper loses his keys (this might occur in the event of a fire, theft or inattention) he MUST immediately inform the others. To avoid permanent loss of funds, all funds should be moved to a newly created storage using the remaining two private keys.
Step 4: Insert the multi sign addresses in cxAdmin
Go to cxAdmin console and click on “Create” under the “Deep Freeze” nesting.
Insert the newly created multi sign address, select the appropriate currency and define a target balance. The target balance defines the maximum amount of funds that will be moved to this address by the system. Addresses with smaller target balances will be filled first. You may change the target balance for every address later.
Your multi signature address will now be shown in the overview of deep-freeze addresses:
Your deep-freeze addresses will now be automatically filled with Bitcoins (maximum of 50) that exceed the maximum size of your hot wallet.
Use Case: Defrost request
It might occur that a user from your exchange wants to withdraw more Bitcoin that are in your current hot wallet. This will trigger a “defrost request” that will pop up in the dashboard of your cxAdmin interface. This tells you that you need to unfreeze Bitcoin from your cold storage to be able to process the user withdrawal. Besides the created defrost request, you will also receive an email to email@example.com that contains the size of the withdrawal that cannot be handled and the current size of the hot wallet. You will also receive an email notification when another user just transferred funds to your hot wallet – or you cleared a paper wallet to increase the size of the hot wallet – so the user withdraw can now be successfully processed.
If there are still not enough Bitcoins available on the hot wallet, your vault admin now has to verify the redeem code from the multi sign address he wants to clear and create a transaction that clears all funds from the paper wallet and has to be signed by each vault admin. After the transaction has been signed by all vault admins, the transaction can be broadcasted into the network. The paper wallet has now been cleared and a new paper wallet has to be created in order to sustain the amount of 20 paper wallets. The process is described in Use Case: deep-freeze process.
Step 1: Receiving defrost request notification
You will either receive an email to firstname.lastname@example.org (you can edit the email recipient address under “configuration”) or see that there are suspended transfers on the dashboard of your admin interface.
You now have to decide which paper wallets you have to clear in order to be able to serve the user withdrawal. The amount of crypto funds that need to be cleared in order to be able to serve the user withdrawal is displayed in the email notification that you will receive when a hot wallet underrun occurs. After deciding which paper wallets to clear, you initiate the process of clearing the multi sign paper wallets (or standard cold storages).
Step 2: Chose cold storage to defrost
Go to “Deep Freeze” in the admin interface and have a look at the overview of all cold storage addressed that are used by Deep Freeze.
Choose the cold storage address that you want to clear and click on the defrost icon.
You will now see a summary of the deep freeze address you are about to defrost and you will receive a hot wallet address that shows you where the cleared funds need to be transferred to.
If you are sure that this is the right one, click on “Start defrost process”. You will now see that the Deep-freeze address has been highlighted as it is in the process of being defrosted.
Step 3: Move funds from cold storage address to hot wallet
If you are using not a multi signature paper wallet for the address that you are about to unfreeze, simply send the funds from the cold storage to the hot wallet ID provided in Step 2.
Please notice that the defrosting process requires you to make only one transaction to the displayed hot wallet ID. If the amount of crypto funds contained in the defrost transaction is smaller than the original amount of funds stored in the deep freeze address, the difference will be subtracted from the “deep freeze account” that is supposed to procure the mining fees for the defrosting of the deep freeze address.
The process of clearing a multi signature paper storage is a bit more complex and can be seen in this chart:
The vault admin uses the redeem script to generate a transaction script which contains the information where the funds from the cold storage should be sent to and how much miner fee is needed to ensure a swift processing by the Bitcoin network. He then signs the transaction script with his own private key and then gives the transaction script to another vault keeper. The vault keeper also signs this transaction script with his own private key. With every signature, the transaction script gets bigger. The vault keeper provides the transaction script to the vault admin, who can now broadcast the transaction (which has been signed by two out of three private key holders) to the bitcoin network.
Step 4: Verify redeem key
Now we need to verify the redeem key to be sure that we are about to clear the right paper wallet. Go to exchangeurl.com/multisign and click on verify.
Enter the redeem script of the first paper wallet to and click on submit.
You will see a confirmation of the multi signature address as well as the pub keys that will have to provide the signature so you can successfully sign the transaction to clear the paper wallet.
Verifying helps you to ensure that you are unfreezing the correct paper wallet. It should be done after creating transactions or after you signed the transaction with one of the private keys.
Step 5: Create transaction
After you verified the redeem script you can now create a new transaction from the paper wallet. Go to yourexchangeurl.com/multisign on New -> Transaction.
After you filled in the redeem script, you will see the current balance of this paper wallet. You may now insert an address and wait for the balance to show up.
After the balance has been updated, you may insert addresses where the coins will be sent to after the paper wallet has been-cleared. Do not forget to include a miner (transaction) fee.
Insert the address where to send the cold storage coins, insert the amount (minus the transaction fee) and click on-submit.
You will receive your transaction script that now has to be signed by 2 out of 3 vault keepers.
Step 6: Verify transaction script
Step 7: Vault keepers sign transaction script
As you can see in the verification of the transaction script, it has zero signatures. You will have to sign the transaction with 2 out of 3 signatures so you can broadcast the transaction to the network and clear the paper wallet. Go to “Sign”.
Now enter the transaction script and your private key (as you are the vault admin, you are supposed to have one of the three keys for the cold storage wallet) and click on „submit“ to sign the transaction script with your private key.
After you submitted the signature, you will receive a transaction script that contains your signature.
You can also verify the transaction script that contains the signature from your private key under „verify“. Just enter the transaction script, click submit again and you will see that your transaction already contains one of the needed two signatures:
Now, send the new transaction script to another vault keeper so he can sign it.
After he signed it, he sends you the transaction script that contains both your signatures. You can verify the signed transaction script to see if all needed signatures are available.
Step 8: Broadcast the signed transaction
The next step is to broadcast the transaction script that contains your signature and the signature of another vault keeper. Go to Broadcast and enter the transaction script:
After you entered the script and clicked on submit, you will receive a txid – the transaction Id is the confirmation that the coin network accepted your transaction. You can use it to search for the transaction on blockchain.info.
Just go to blockchain.info and type into the search field the transaction Id provided. You will see that the transaction is on the way:
Step 9: Recreate paper wallet
Now it is important to recreate these paper wallet(s) because we need to have 20 paper wallets at all times. You can use the process description of Use case 4: deep freeze process to create new paper wallets so the amount of cold storages is always 20.
Step 10: Insert new paper wallet into cxAdmin deepfreeze
The last step is to put the recreated paper wallets into the cxAdmin deep freeze console. This step is described in the Use case: Insert into cxAdmin
Use Case: User deposit
Step 1: User wires bank transfer
The first step is that the user that wants to trade on your platform and needs to fund his account first. He wires a transfer to the account that will be shown by the exchange site.
After the user has sent the wire, the back office agent then has to allocate the payment.
Step 2: Back office agent allocates user payment
The back office agent now has to look up the wires that arrived on the bank account and has to allocate the payment to the user. The user has included a reference when making the transfer, this reference will be used for the allocation. When the allocation is confirmed, the back office will update the user’s account balance in the next step.
Step 3: Back office agent updates the user’s account balance
Now, the back office agent has to look for the customer that wired the transaction. He can use the Use case that describes how to search for a user.
After he found the user, he can click on him and click on “Fiat crediting”.
He then choses the type of currency, enters the amount of money that has been wired to the account (minus any wire fees that will be applied as a policy from the exchange) and clicks on “Credit Money”.
Step 4: User receives new balance
The user now has an updated account balance and will be able to execute orders. He receives a notification that informs about the account credit.
Due to the optimistic fund locking, the user is able to create orders even before he did the first wiring. The order will not be shown in the order book. As once as balance gets updated and he has funds, the orders will then be shown in the order book and can be executed.
Use Case: Create new market
Creating a new market on your exchange is easy. Prerequisite for this is that the currencies that will be traded on your new market were both added to your exchange by the skalex team. Please inform us if you want a new currency added into your exchange system.
Step 1: Market concept
First, you need to prepare a small concept of your market. The cryptocurrency trading pair that you are aiming for should have a decent activity so you will most likely generate a good amount of traffic on your exchange.
Comparing the trading activity on other exchanges is a good idea. Also, the understanding of the maker taker fee as well as nominal and limit structure is important because it will influence the way people are trading on your exchange.
The Maker is the person that creates orders that are limited and will not get executed immediately and stay in the order book. Hence they create the market, they are market makers.
The Taker is the person that creates unlimited orders or limited orders that automatically get matched. He is taking orders from the market and also is called the market taker. Because he decreases the liquidity on your exchange, it might be a good idea to increase the taker fee.
Spread can be applied to generate additional revenue by inflating the prices in orderbook. Its value is defined in %
The order book is the biggest asset of every exchange. The more orders are in the order book, the higher the liquidity of the exchange is. Our fee structure in cxAdmin allows you to stimulate your market activities by setting higher taker fees and lower maker fees. This will incentivize people to rather create market making orders than to create market taking orders. As a result your order book will grow and the liquidity of your exchange will increase.
Step 2: Create market
We decide to create a new BTC LTC market that has the usual minimum nominal and a fee structure that incentivizes market markers. We enter the cxAdmin console and click on Markets > create. We are now able to fill in a lot of market attributes which will now be explained:
The first two attributes that you need to enter defines the trading pair of the new market you are about to create. If you chose LTC as nominal currency and BTC as limit currency, you will create a LTC/BTC market where LTC is the leading currency. This means that your users will be able to buy Bitcoin with Litecoin as leading currency. We will create a LTC/BTC market in this example, therefor we pick LTC as nominal currency and BTC as limit currency.
After defining the trading pair, we need to enter the minimum nominal and the minimum limit. The minimum nominal defines, what the lowest acceptable input for the creating of orders is. In this example, setting the minimum nominal to 0.01 would result that buy orders for Litecoin need to be at least 0.01 BTC so the system accepts the order. The minimum limit defines what the minimum amount of Litecoin has to be so the system accepts the order. Setting it to 0.1 would mean that users cannot create sell orders that contain fewer than 0.1 Litecoin.
We will set the minimum nominal to 0.1. Orders have to be at least 0.1 LTC so they will be accepted. Also we need to specify an account holder for price difference. As order matching engines bear the problem that it is not known in advance how much transaction fees the user will pay, making the fee deduction impossible to calculate in advance. A price-difference account is needed, this one will be used to deduct fee differences that might occur. This will affect only a few transactions, the amount of fee differences is very low (around 0.01 USD) but still needs to be compensated by a price difference account so the integrity of the accounting system is ensured.
The next step is to define the sorting for the created market. Each new market will be automatically put on the last position. If you want to have the new market on position 1, change the value in the “sort order” field to 1.
Now we need to adjust the fee structure of your exchange. We will give three different examples to show you that you can choose from a variety of different trading fee structures.
We can adjust the fees by using following criteria:
Maker/Taker fee structure: Market makers are traders that create limited orders. These are orders that only get instantly filled if a matching partner is found. In contrary to an “execute best” order which will always be instantly filled, the limited order will most likely stay in the order book. Every order in your order book increases the liquidity of your exchange. Because the liquidity in your exchange is a critical mass for new traders, it would make sense to increase the liquidity (amount of limited orders in your system) by using a trading fee structure that incentivizes market makers. With skalex’s exchange software, you can adjust the maker and taker fees for each trading pair. Market makers can receive lower trading fees (or you may even give them 0% trading fee) while market takers receive higher trading fees.
Fee on nominal or limit side: You may also choose the currency side where the trading fees should be subtracted from. If you edit a LTC/BTC market, Litecoin is the nominal currency and Bitcoin the limit currency. Given the case that you want to receive your trading fees in Bitcoin, you can do so by setting the trading fee on the limit side and make a distinction between maker and taker. Leave the nominal fee side empty to just generate trading fees on the limit side (Bitcoin).
Market Taker Checkbox Taker active checkbox is to be checked if the admin wants to enable Taker function. By enabling this function the Taker user will start executing orders from the Orderbook, if the Taker probability is set to 20% then the Taker will execute 20% of the existing orders from the Orderbook
Example 1: Plain 0.3% trading fee on Bitcoin side
In this example, we will set the trading fee for the LTC/BTC market to a plain 0.3% factor. We decide to receive the fees in the form of Bitcoin so we will have to adjust the fees for the limit side. We do not make a distinction between maker and taker model.
You will now receive 0.3 % of all trades on your platform in the form of Bitcoin. Market makers and takers will receive the same trading fee.
Example 2: 0.1% for makers, 0.4% for takers
In this example, we will make a distinction between the market makers and market takers. On our LTC/BTC market, we want to generate trading fees in form of Litecoin. Also, market makers should receive 0.1% trading fee and market takers 0.4% trading fee. We need to adjust the settings accordingly:
We will now receive our trading fees in Litecoin (they will be booked on the account of janedoe), while market takers get a reasonably lower fee than market takers.
Example 3: Maker/taker distinction, 50% of each currency
Now we want to make a maker/taker distinction while receiving all trading fees on both sides. We want to receive our trading fees in Bitcoin as well as Litecoin and need to adjust the trading fee structure accordingly:
We will now receive 0.1% trading fee on the maker side and 0.4% trading fee on the taker side. The maker will pay 0.05% trading fee in Litecoin (nominal side) and 0.05% trading fee in Bitcoin (limit side). The market taker will then pay 0.2% trading fee in Litecoin (nominal side) and 0.2% trading fee in Bitcoin (limit side).
After adjusting all attributes, we need to decide if the market should be activated immediately. If yes, the flag can stay. We click on “create market” to create the market after all.
You will see a success notice that the market has been created.
Step 3: Activate market
After you created the market (and did not activate it yet), you need to activate it. Do so by going on markets:
Click on the “play” icon to start your market. You will receive a notification if it has been successfully activated.
If the exchange software has buyer and seller nominal implemented you can define additional minimum nominals.
- Minimum nominal for buyers: If set to 0.1 on a Bitcoin to Fiat market, Buyers need to put in a minimum of 0.1 BTC for each order (Buy at least 0.1 BTC). The system will not accept the order if the nominal is below the minimum nominal.
- Minimum nominal for sellers: If set to 0.1 on a Bitcoin to Fiat market, Sellers need to put in a minimum of 0.1 BTC for each order (Sell at least 0.1 BTC). The system will not accept the order if the nominal is below the minimum nominal.
If the exchange software has buyer and seller fees implemented, the fee model is extended. There are four more options to set as exchange operator:
If the buyer seller fee model is used, the maker taker fee will not be charged.
Put in the value e.g. as the format "0.1". 0.1 means 0.1% of traded volume will be charged as fee. If you put in two values for the Buyer fee, such as 0.1 in both fields, the Buyer will pay 0.2% fee - 0.1% in the limit currency and 0.1% in the nominal currency.
- Buyer Fee (nominal currency): Set the fee for the buyer which will be subtracted in the nominal currency.
- Buyer Fee (limit currency): This is the fee for the buyer which will be subtracted in the limit currency.
- Seller Fee (nominal currency): The fee for the Seller on the nominal currency side.
- Seller Fee (limit currency): Set the fee for the Seller which will be subtracted in the limit currency.
It is not possible to specify the account holder for the buyer and seller fee. The fee will be automatically booked on the account holder for the maker taker fee.
Use Case: Edit market
If you want to edit a market, you need first to pause it, then edit the settings and test if those were successful. If your tests were successful, you can then activate the market again.
Step 1: Market overview
First, go to the market overview in cxAdmin. You need to find the market that you want to edit first.
You may use the sort column to change the sorting of your markets. Simply click on the to increase the market order (move the market up one position) or click on the to decrease the market order (move the market down one position).
Step 2: Pause market
First, you need to pause the market you want to edit. Finding your market should be easy, either look out for him in the market overview or use the search interface to find him. You can now see if the market is running or is inactive. If the market is active, press on the square to pause it.
After clicking on the square, you will receive a message if the market has been successfully deactivated. You will also see this in the overview of the market.
Step 3: Edit market
After you paused the market, you can now edit the settings. Click on the edit symbol to edit the settings of a market. All settings are described in the use case to create a market.
Step 4: Activate market ====
After you edited all settings you should briefly verify them in a short test. If everything went well, you can now activate the market again. To do this, simply go to the market overview and click on the “play” button on the market.
Use Case: Configure market maker
Market maker can be edited via admin panel by click on the target symbol at the actions area in market overview.
Set Base price
Base price set by: Select how you want to set the base price. It can be set manually (Fixed price) or automatically pull price from a Live Chart/Ticker.
a) If base price is set to Fixed price mention the fixed price in this field. b) Here a price ticker can be used to set the price base price. We can use BNC price index at www.bravenewcoin.com which shows the weighted average price over all exchanges for the particular market. We can also use price from a particular exchange for that market. e.g. for USD/BTC market we can either use the weighted average price as per BNC price index or the price from a particular exchange like Bitfinex, Bitstamp, BTC-e, etc.
Order offset strategy
Offset is the price difference between two orders placed by the market maker. Define how you want to set the offset. It can be set in percentage or in absolute value.
Percentage points If you have selected to define offset in percent then mention the offset in percentage (e.g. 0.2 for 0.2 offset). Offset in limit currency: If you have selected to define offset in absolute then mention the offset in absolute.
Orders per side
Number of orders that will be inserted by market maker on the bid and ask side
ATTENTION: The market maker can only place as many orders as the available funds can cover.
Minimum volume for orders in limit currency
Mention the minimun volume of order in the limit currency.
Cancel probability is the probabilty in % per minute when an order is cancelled.
If for a BTC/USD market we set Fixed base price of $1000/BTC Absolute offset = 2 Orders per side = 5
The the following orders will be inserted into orderbook by market maker.
- 1 BTC @ 998 USD
- 1 BTC @ 996 USD
- 1 BTC @ 994 USD
- 1 BTC @ 992 USD
- 1 BTC @ 990 USD
- 1 BTC @ 1002 USD
- 1 BTC @ 1004 USD
- 1 BTC @ 1006 USD
- 1 BTC @ 1008 USD
- 1 BTC @ 1010 USD
Use Case: Create off-market deal
The exchange software is able to handle off-market deals that are not being processed directly over the order matching engine that connects matching orders.
Either customers or administrators can create off-market deals. As administrator go to the market section and choose the off-market deal for a specific market:
- Trade partner 1: The first user of the off-market deal. Depending on the exchange you need to put in the unique user ID (either E-mail address or username)
- Trade mode: Describes the relationship between both users. Either "buys from" (Trade partner 1 buys from Trade partner 2) or "sells to" (Trade partner 1 sells to Trade partner 2).
- Trade partner 2: The second user of the off-market deal. Depending on the exchange you need to put in the unique user ID (either E-mail address or username)
- Nominal: The nominal of the trade.
- Rate: The exchange rate for the off-market deal.
After filling in the attributes click on "Validate trade". The system will no validate if both users exist and do have the necessary account balance to perform the trade.
Use Case: Colored coin assets
Step 1: Introduction
Colored coin assets are created on the website https://www.coinprism.com. The exchange administrator
- sends Bitcoin to his Coin prism account
- creates a new asset
- funds the asset
- issues coins on the asset and
- send the coins to his market maker account
Creating colored coin assets allows you to emit your own currency or stocks. In contrary to using a separate, own cryptocurrency to establish the blockchain network, the colored coin approach allows to use the Bitcoin blockchain infrastructure. This allows you to save infrastructure costs for miners or nodes while still receiving all benefits of the Bitcoin blockchain.
Step 2: Backup your wallet
Step 3: Send Bitcoin to your Coinprism account
Funding an asset, issuing coins and sending the coins each costs Bitcoin transaction fee (0.0001 BTC). Issuing coins and sending the coins each costs “dust” of 600 Satoshi.
All together a new coin costs you 0.000312 BTC. To provide for 160 new coins send 0.05 BTC to the main address of your new CoinPrism account.
On the “Home” page of the coinprism menu choose “Receive Bitcoins” and send 0.05 BTC to the address given.
Step 4: Create a new assets
On the “Addresses & Colors” page of the Coinprism menu click the button “New color”.
Choose the name of the new color and address type “Regular address”. Then click “Create”:
On the “Edit color” page enter the short name of your currency together with the issuer name.
Choose “Divisibility: Indivisible”
And asset type “Stock”.
Then click “Save”:
Step 5: Fund the asset
This will bring you to the “Send coins” screen with preselection of the Main address as sender and your new color's funding address as receiver.
Confirm with your Coinprism password.
Step 6: Issue coins
After creating the color it may take some hours for Coinprism to publish your new color's metadata. It is not necessary to wait until it's published, only you will not see the asset name in Coinprism's sign transaction dialog.
On Coinprism's “Addresses & Colors” screen choose your new color. In the color tools click on “Issue coins”:
Enter the amount of coins you wish to issue. The amount has no effect on the BTC cost. Issuing will always cost 0.0001 BTC transaction fee plus 0.000006 BTC “dust” that contains the coins:
If you see that your transaction says “Unnamed colored coins” your coin's metadata weren't published yet. You can still issue the coins, because only the address is important. Enter your Coinprism password to confirm:
Step 7: Create asset on your exchange
In the admin panel of your exchange click on “Currencies – Create”.
Enter the same Short Name, Full Name and Asset Id that you have used to issue the coin on Coinprism to create the new asset and click “Create asset”:
Step 8: Send assets to your exchange's market maker account
Send Assets from your new color's Coinprism account to the Market Maker account of your exchange:
Enter your Coinprism password to sign the transaction and see its confirmations on your exchange's Market Maker account:
You will now see the transaction of colored coins in the market maker account by clicking on “Account”.
Please notice that colored coins transactions are propagated and acknowledged by the network slower than usual Bitcoin transactions. It might be the case that it takes several minutes until the transaction will be seen in your exchange account and/or the colored coin block explorer at https://www.coinprism.info/ which can be used to track transactions. Transactions from one exchange user account to another’s’ should be seen almost immediately. It is also necessary to understand that each transaction of colored coin assets to other external non-exchange wallets can only be done if the Bitcoin transaction fee is available (currently 0.0001 BTC) on the respective local colored coin wallet of the exchange. This is due to the fact that colored coins are based on the Bitcoin blockchain which only processes transactions if the mining fee is attached and paid by the sender. Kindly inquire for more information of how the necessary funds can be provided.
Use Case: Accept payments as merchant
No Risk Option: Bitcoin payments will be directed to an intermediary merchant system user of the exchange operator. You will receive the payment equivalent in fiat currency on your account of the exchange once the Bitcoin payment received the necessary amount of confirmations from the network. After the Bitcoin payment was received and confirmed on the exchange, it will be liquidated into fiat currency. While the exchange provider takes the risk of exchange rate fluctuation, you will receive the appropriate exchange rate at the point of time the user has been conducting the Bitcoin payment. Receiving payments with this risk option will result in a payment fee of approx. 2.5%.
Sell Risk Option: Bitcoin payments will be directly booked on your exchange account. After the confirmations from the network are available, the amount of Bitcoin will be instantly exchanged to fiat currency (liquidation via market sell). When accepting payments with this risk option, you take the risk of exchange rate fluctuation. You will also pay a fee up to 1%.
Risk Option: Bitcoin payments will be directly booked on your exchange account. After the confirmations from the network are available, the received Bitcoin will be credited to your exchange account and you can decide when to liquidate the funds by simply selling them. Also a minor fee will be applied for payments conducted with this type or risk option.
- Callback URL payment received: forwards the customer to the specified URL after the Bitcoin payment has been received.
- Callback URL payment confirmed: redirects the customer to the specified URL after the Bitcoin transaction of the payment has received the necessary confirmations (6) by the network.
- Callback URL payment canceled: if the user cancels the payment process, he will be redirected to this page.
- E-mail address payment notifications. the merchant can enter an e-mail address that will receive notifications for certain events:
- E-Mail notification payment received.
- E-Mail notification payment confirmed.
- E-mail notification payment canceled.
- E-Mail notification payment received.
The callback URLs will be receiving a callback request from the exchange. Depending on the circumstances, not every callback will be sent, e.g.
- If the customer sends the Bitcoin from an external wallet, the exchange will first send the callback for "payment received" at the point of time the user transacts the Bitcoin. After the 6 confirmations by the network have been received, the exchange will send the callback request for "payment confirmed".
- If the customer sends the Bitcoin from a wallet that is located on the exchange where the merchant payment is sent to, the exchange will only send the "payment confirmed" callback request. This is due to the fact that the receival and confirmation of payment happens at the same time.
You can test the callback requests by using an external website such as [request.bin|https://requestb.in/]. Go to the website, create a requestb.in URL and then put this URL into the profile of commercial options. The website will display all callbacks that have been received.
The "payment received" callback has following format: type=paymentReceived&riskOption=NoRisk&amountBTC=0.14705882&cryptoCurrencyCode=BTC&amountFiat=20.00&fiatCurrencyCode=CNY&transactionId=4ff9cd0da37634326c7cc997505797dd64261223c1b5d8cf746c510daf92c229&confirmations=0&wantedConfirmations=6&receivedTime=1478350783&referenceId=testID The "payment confirmed" callback has following format:
Step 1:Register on the exchange
If you want to accept Bitcoin and other Cryptocurrencies as payment, you need to be registered on the exchange that has the merchant plugin module available. Go through the KYC process of the exchange to ensure that you are able to withdraw funds.
Step 2: Configure the commercial options
After you have registered on the exchange and you are good to go, log into your account.
Click on your “Profile” and go to “commercial options”.
Select one of the three possible risk options described in the Introduction.
No Risk Option
Sell Risk Option
Select the appropriate distribution of payment fees between you and your customers. Moving the slider to the left side will make the user pay 100% of the fees, while the slider on the right means that you will pay 100% of the payment fees produced by the merchant plugin.
Define the Callback URLs if necessary.
Save the options by clicking on the “save” button.
Click on “Create payment button” and put in the necessary information:
- Price: The price for the payment you want to create the button for, e.g. “20 USD”. Please note that the base currency is depending on your exchange markets as some exchanges only have USD or EUR markets available.
- Vendor name: The name of your vendor that wants to receive the payment, e.g. “SloppyJoe Industries”.
- Order reference: To allocate your payment with your internal order systems, e.g. “2016-03-20-10002”.
- Description: Description of the payment, e.g. “Payment for ordering 20 Bitcoin Miner”.
Step 4: Test the payment process
After the code has been implemented in your website or extracted in a local folder you can test the payment process.
border|Pay with Bitcoin button
Click on the “pay with Bitcoin” Button and send the required amount of Bitcoin to the provided address.
After the payment has been conducted by the customer, it will be checked for double spending. It takes around 3 seconds for the payment layer to confirm the payment.
Once the payment of the customer has been accepted, he will be forwarded to the success page and the payment is complete. You will receive the funds depending on the Risk Option you have selected.
Use Case: POS payment
The POS payment allows brick and mortar merchants to accept Bitcoin payments directly or to sell Bitcoin to customers.
POS Pay enables you to directly create Bitcoin invoices out of your exchange account.
Go to your profile page, access the commercial options and click on “POS payment”.
Once you enter a price for the payment, the “pay with Bitcoin” button shows up. The POS pay works fine if you only enter the value for the price, but can be extended with various additional information:
- Vendor name
- Order reference
After you have entered the relevant information you click on the button to initialize the payment. Show the customer that wants to pay with Bitcoin this QR code and wait for the payment to be confirmed.
Similar to the merchant payment plugin, each POS payment will be checked for double spending attacks.
The POS sell features allows you to directly sell Bitcoin to your customers. After procuring the necessary amount of Bitcoin that your customer wants to buy, you collect the cash from your customer and then send the Bitcoin to his wallet ID.
Step 1: Stock required Bitcoins from exchange
Fill in the amount of Bitcoin that your customer wants to purchase and click on either the blue arrow to start buying the necessary Bitcoin.
You will receive a confirmation after the buy was successful and you can go to the next step.
Step 2: Cash in from customer
Step 3: Send Bitcoin to customer
Use Case: PayPal Setup
1. Use case : Setting PAYPAL Payment Processor
(You must have the merchant paypal account to proceed further.)
All PayPal API requests require API credentials to verify the call is being made through a valid PayPal account. Calls to the sandbox testing environment are no different but they require that you use the test credentials assigned to one of your sandbox Business accounts.
Tip: The PayPal sandbox and live environments each use different sets of API credentials. Use the correct set of credentials for the endpoints you're addressing.
1.2. View and manage your API credentials
1.2.1 The AppID for the Adaptive APIs
In addition to the API credentials, the Adaptive APIs (Adaptive Payments, Adaptive Accounts, Invoicing Service (SOAP) and Permissions Service) make use of an AppID value. The sandbox uses a global test App ID value that remains constant.
You need create a PayPal application in the My Apps & Credentials tab in Paypal account. To start creating an application, click the Create App button.
You will be redirected to the creation page of the application on which you need to enter a name of an application, select your created account for business and click the Create App button.
After the application is created, the client ID and Secret will be generated, these tokens are used to get accesses to your application and will be used later.
Client ID and Secret need to be inserted into the admin panel for test and production, to do this, you need to click the edit button on the desired setting and you will be redirected to the page with the configuration edit form in which you need to insert the client ID or Secret value and click the Save button.
1.3. Sandbox accounts
Use sandbox accounts to generate mock transactions to test your app. The PayPal sandbox supports these account types:
To test a typical PayPal transaction, you must use both types of accounts.
When you register as a PayPal developer on the developer site, the PayPal sandbox creates these sandbox accounts:
A business account and associated NVP/SOAP API test credentials. For example, email@example.com.
A default personal account. For example, firstname.lastname@example.org.
You can create additional sandbox accounts on the developer site or directly on the sandbox site, https://www.sandbox.paypal.com.
Some PayPal transactions require more than one buyer-and-seller pair. For example, parallel payment calls and Adaptive calls each require two different business accounts but for different reasons. In these cases, you must create additional sandbox business accounts to play the roles of the entities in your transactions.
For information about sandbox account roles, see plan your sandbox accounts.
1.3.1 Create a personal sandbox account
Create a personal sandbox account to represent the buyer in a transaction. The PayPal sandbox automatically creates your first personal sandbox account when you sign up for a developer account on the developer site. To generate the personal sandbox account name, PayPal appends -buyer to your email address.
When you create a sandbox account, you assign an email address and password to it. You use the email address to reference the sandbox account in your test API calls. You also use the email and password values to log in to the sandbox accounts page to view and configure the sandbox account.
To create an additional personal sandbox account:
Log in to the developer site sandbox account page.
Click Create Account.
Set the Account Type to Personal.
Enter an email address. This address can be a fake email address.
Enter the account password.
Under Payment Methods, enter the test buyer's PayPal account balance.
To test credit card transactions, enter a test credit card number.
Click Create Account.
Tip: To simplify the testing process, use the same password for all your sandbox accounts.
1.3.2. Create a business sandbox account
The PayPal sandbox automatically creates your first business sandbox account when you sign up for a developer account on the developer site. To generate the account name, PayPal appends -facilitator to your email name. PayPal assigns a set of NVP/SOAP test API credentials to the account. Use the account to create mock PayPal transactions in the PayPal sandbox.
To create an additional business sandbox account:
Log in to the developer site sandbox accounts page.
Click Create Account.
Set the Account Type to Business.
Enter an email address. This can be a fake email address.
Enter an account password.
Under Payment Methods, enter the test merchant's PayPal account balance.
Click Create Account.
Tip: To simplify the testing process, use the same password for all your sandbox
1.3.3. Manage sandbox accounts
On the developer site sandbox accounts page, you can:
Change a sandbox account password
Delete a sandbox account
Link a sandbox account to your developer account
1.3.4. Change a sandbox account password
To change the account password:
Log in to the developer site sandbox accounts page.
Click the expand icon associated with the account you want to manage. The Profile and Notifications links appear.
On the Profile tab of the Account Details dialog box, click Change password.
Enter a new password and click the Save link, located just below the password text box.
1.3.5. Delete a sandbox account
To delete an account:
Log in to the developer site sandbox accounts page.
Tick the box in the left column of the account(s) to delete.
Click Delete. A message confirms the successful deletion of the account(s).
Note: You cannot delete the default -facilitator and -buyer sandbox accounts that the PayPal sandbox creates.
Link a sandbox account to your developer account
To link a pre-existing sandbox account to your developer account:
Log in to the developer site sandbox accounts page. Click log in with PayPal. Then, enter your sandbox account credentials. A message confirms successful log in. Your sandbox account appears on the developer site.
Note: If your sandbox account is already linked to another developer account, you cannot link it to your developer account.
In order to login into paypal sandbox as buyer and facilitator you need to change the password in your test accounts
This is a test buyer’s account.
When you create email@example.com account, you are given $ 10,000.
The same operation for login facilitator.
This is a test facilitator’s account:
After creating the PayPal application and sandbox accounts and setting up the admin panel, the user can withdraw funds via PayPal. After the user withdraws money through PayPal, you will see a withdrawal request in the admin panel in the Dashboard / Withdrawals requests tab,
you need to click on the user's email. If the user has not confirmed the operation via email yet, you will see the option «user confirmation» -> not yet,
and if the user has not confirmed the operation for more than 1 day, the administrator can delete this request in the Actions option by clicking the Delete button
if the user has confirmed the operation user confirmation -> confirmed.
Then you need to press paypal-withdrawal, and go to the Paypal Withdrawals tab. Press status button of the needed transaction, to request the status of the operation from the PayPal application.
If the operation is successful you will see a notification, and the status will change to SUCCESS
On the account in PayPal for which money has been transferred in the Sandbox -> Notifications tab, notification of the transfer of funds will come
To replenish your account through Paypal, you need to go to your account in the skalex and select a currency, then click on Deposit Paypal, then enter the amount you need in the form. And click on Deposit Paypal.
You will be redirected to the login page in PayPal where you need to specify an email address from the sandbox account firstname.lastname@example.org.
After authorization, you need to confirm the operation.
After confirmation, you will be redirected to the page indicating the status of the operation. You can request the status of the operation by clicking on the Handle in the admin panel - Dashboard/Paypal_Deposit requests
Notification of the transaction will be available in your Buyer's Sandbox Account.
Withdrawals in auto mode works through cron, the admin panel prompts for status after a while.
On deposits in automatic mode, another command via cron in the case of confirmation credits money to the account.
In order to be able to withdraw or replenish an account using the PayPal you must have the parameter in your license that gives you this opportunity.
Use Case: KYC Setup
Use case: Managing customer KYC levels
Know your customer (KYC) is the process of a business identifying and verifying the identity of its clients. The term is also used to refer to the bank and anti-money laundering regulations which governs these activities. Know your customer processes are also employed by companies of all sizes for the purpose of ensuring their proposed agents, consultants, or distributors are anti-bribery compliant. Banks, insurers and export creditors are increasingly demanding that customers provide detailed anti-corruption due diligence information.
skalex KYC system’s main idea is to divide users to groups (KYC levels) with different privileges and limits. There are also abilities to create unique limits for users and for currencies. This creates a lot of abilities for managing and administrating the customers.
The main feature of KYC system is KYC levels. If you need the levels for KYC process, the license should be generated including this necessary number of the levels. Please inform your project manager about the number of levels in order to include this parameter. Your exchange admin will be able to create the KYC levels and limits via an admin panel. To access KYC areas, you admin must have required rights. You can edit them in admin right group edition/creation.
1.14.2. Create KYC Level
There is a special interface in admin panel to create KYC levels. You need to select 'KYC levels' option in menu and click on 'Add new kyc level' button.
Please look at the screenshot below:
Then you need to enter level number and description.
184.108.40.206. Adding information restriction/limits
Each level has its own limits and required fields. To edit them, go to KYC levels overview and click on «Limits» or «Fields» button. Then you may edit, delete or create new limits or fields. In the form of limit creation you need to choose type of limit(Deposit/Withdrawal), type currency(Crypto/Fiat), amount, currency, time(number) and period(Year, month, week, day, hour, minute). You can combine for Deposit/Withdrawal with Crypto/Fiat currency types; the only combination that is not available is crypto deposit limits.
Please look at the screenshot below:
220.127.116.11. Adding fields
You can also set personal limits for customers in their details. These limits become active only after user reaches needed level.
1.14.3. Setting KYC level limit to customer
There is also an option to set limits for currencies. Go to currencies overview and edit one of them.
Then click on «Add new limit» button.
Choose needed options and click «Save»
General Setup: Encrypt and decrypt Mails
Emails may contain confidential information that should not be visible to everyone, especially when sending login information. skalex requires each exchange operator to install S/MIME encryption for their email programs so encrypted email communication can be used to exchange logins and other important information. A guide how to receive an S/MIME certificate and how to install and use it can be found below.
Step 1. Get InstantSSL certificate
Go to https://secure.instantssl.com/products/frontpage?area=SecureEmailCertificate¤cy=USD®ion=North+America&country=US&entryURL=https%3A//pac.instantssl.com/ and follow the instructions. Remember the password for certificate revocation. When you receive the confirmation e-mail open it in Firefox. Internet Explorer and Chrome work too, but the process to export the certificate is different. The main steps are to put in the right e-mail address and create the certificate.
Step 2. Export the certificate
When the installation of the certificate is confirmed, click Firefox – Settings – Extended – Certificates – Show Certificates, choose your new certificate from the Tab „Your Certificates“ and click on Save... Now encrypt it with the same password you used for certificate revocation (like this you only have to remember one password). Remember the file name you save the certificate to.
Step 3. S/MIME in Outlook
Follow these step to get S/MIME running in Outlook:
1. Right click the e-mail account you have requested the certificate for and choose account properties.
2. Select Options – Security Center – Settings and click on E-Mail Security. In the Digital IDs area choose Import, select the certificate file you have saved during the Export step in 1 Get InstantSSL certificate, enter your backup password and confirm. After the import you are back in Settings – E-Mail Security.
3. You are still in Select Options – Security Center – Settings – E-Mail Security. In the Encrypted E-Mail messages area click the Settings button. Select your new certificate for signatures and encryption and tick the checkbox „Add these certificates to signed messages“.
4. To always sign or encrypt outgoing mail tick the checkboxes „Encrypt outgoing messages“ and „Add signature to outgoing messages“ in Select Options – Security Center – Settings in the Encrypted E-Mail messages area. This setting can be individually changed per e-mail via the Options – Sign/Encrypt buttons in the New Mail window.
You are now ready to send and receive encrypted mail in Outlook.
Step 4. S/MIME in Thunderbird
Follow these step to get S/MIME running in Thunderbird:
1. Select your e-mail account and click account settings – S/MIME (in some installations Security) – Manage certificates – Import...
2. Select the Certificate file you have saved during the Export step in 1 Get InstantSSL certificate, enter your backup password and confirm.
3. After closing the certificate manager select your new certificate for signing and encryption and, if desired, choose to always require encryption when sending message. This setting can be individually changed per e-mail via the S/MIME button in the Send E-mail window.
You are now ready to send and receive encrypted mail in Thunderbird.
Step 5. S/MIME in Windows Live Mail
Follow these step to get S/MIME running in Windows Live Mail:
1. To import the certificate you have to open Internet Explorer – Internet Options – Content – Certificates. Click Import and choose the *.p12,*.pfx file type. Select the Certificate file you have saved during the Export step in 1 Get InstantSSL certificate, enter your backup password, tick the Include Extended Properties checkbox and confirm. Select to Choose the Certificate Store Automatically and import to certificate.
2. Back in Windows Live Mail choose the e-mail account you have requested the certificate for and click on accounts – properties.
3. Open the Security tab and select the previously imported InstantSSL certificate for signing and encryption.
4. To always sign or encrypt outgoing mail choose file – options – security options. Click the security tab and click “Sign all messages and Encrypt all messages” and confirm. This setting can be individually changed per e-mail via the Options – Sign/Encrypt buttons in the New Mail window.
You are now ready to send and receive encrypted mail in Windows Live Mail.
Step 6. Delete old certificates
To make your e-mail client use the latest certificates of your partners you need to delete old certificates from the storage. Here's the way how to do that:
Thunderbird: Click on the e-mail account - account settings - S/MIME security - manage certificates - Persons, choose on the old certificate and click Delete.
Outlook and Windows Live Mail: Open internet explorer, choose internet Options - Content - Certificates - Other Persons, choose on the old certificate and click Delete.