# Understanding deposits

Your deposits are controlled by DeBets Smart Contract.
In DeBets when you make a deposit you are not sending your funds to a third party, instead you are injecting the funds into DeBets Smart Contract which acts as an escrow system. The immutability of the blockchain and the rules of the Smart Contract guarantee that nobody else can access your funds and that you can withdraw all your funds at any time.
When you make a deposit DeBets App uses your Wallet to make a transaction which consists in invoking the Smart Contract, injecting the funds you are depositing into it.
Each deposit you make is linked to a specific game provider and can be used to play all its games. The game provider is entitled by the Smart Contract to receive your losses and is responsible to pay for your winnings when you withdraw.
You can create as many deposits as you want, for the same or for different game providers.
You use DeBets App to manage your existing deposits.

The life cycle of a deposit is made of three phases:

• creation of the deposit: you deposit funds in the Smart Contract. The Smart Contract creates a unique ID for the newly created deposit and assigns your Wallet address as the owner of the deposit
• playing games: DeBets App let's you choose which of your existing deposits you want to use to play the game by activating. While playing, any time you bet and win the balance of the active deposit will be updated accordingly
• closing the deposit: generally deposits when you request a withdrawal. As it will be explained later in this page in some circumstances the closing of a deposit can also be requested by the game provider. Closing a deposit requires executing a blockchain transaction that is used to invoke the Smart Contract in order to withdraw the final balance.

Out of the three phases above, only the first and last one involve transactions on the blackchain (the Smart Contract is invoked). Instead, while games are being played no invokaction of the Smart Contract takes place. That is, in DeBets game play happens entirely off the blockchain.
This means that you will not be paying any fee when you bet or win while playing games and you can enjoy the same player experience as if you were playing the game in an online casino because there are no additional delays caused by having to wait for blockchain transactions to be mined.

We will now describe in details the three phases listed above.

You use DeBets App to create and to manage your deposits.The app shows up after you load a game.
Clicking on the NEW DEPOSIT button in the main screen of the app opens the following dialog:

This dialog shows the current balance in your Wallet for the cryptocurrency in use. You can use the slider or the numeric buttons to specify how much you want to deposit.
Under your balance you can see the minimum amount allowed for a deposit amount in red, more on this later.
After specifying the amount use the SEND to create the deposit. The app will interact with your connected Wallet in order to invoke the Smart Contract and create the deposit. This process involves doing a transaction on the blockchain. You will have to confirm the transaction in your Wallet App.

Once the Smart Contract receives the funds you are depositing it creates a new deposit with the following information:

1. the ID that uniquely identifies the deposit
2. the amount you deposited
3. the cryptocurrency in use
4. the creation timestamp
5. the address of your Wallet
6. the address of the game provider
7. your public key
8. the game provider public key for the cryptocurrecy in use
9. the minimum balance under which the game provider can request the Smart Contract to close the deposit if the player is in loss
10. how long after the deposit creation the game provider can request the Smart Contract to close the deposit if the player is in loss

Some of the points in the list above will not be clear to you at this stage.
Points from 6 to 8 will be explained in Payment Channel. For now what you need to know is that the address of the game provider is used to identify the provider as the owner of the games that can be played using the deposit, just like your Wallet address identifies you, the player, as the owner of the deposit. This means that the deposit can be used to play any game of the game provider with the cryptocurrency used in the deposit. The public keys are used by the Smart Contract to validate the signatures of you, as the player, and of the game provider when closing the deposit.
The last two points will be clear after you read Closing of deposit and withdrawal.

As mentioned earlier there is a minimum amount for creating deposits whose value can vary from cryptocurrency to cryptocurrency and from game provider to game provider. Besides reading it from the deposit creation page in DeBets App you can also find out what is the minimum deposit amount before launching any game, this is shown at the top of the game provider page for each cyptocurrency:

Once you have created a deposit you can use it to play games.
Newly created deposits are automatically activated in the game by DeBets App. As a result the balance shown in the game matches the amount you deposited.
You can create several deposits and you can use DeBets App to seamlessly activate the one you want to use, without having to reload the game (see Managing your deposits).
The deposit you activate is used to play the game and the balance displayed in the game matches the actual balance of the active deposit.
At any moment the balance of a deposit corresponds to the amount that you initially deposited, plus the amount that you have won, minus the amount that you have bet while that deposit was active.
You are now probably wondering what happens to your deposit each time you bet and win given that both these events result in a change of the balance shown in the game.
As already mentioned, while the game is being played there is no interaction with the Smart Contract and no transaction takes place on the blockchain.
Therefore the amount bet and the amount won while playing the game with a given deposit are not recorded on the blockchain, these information instead is mutually exchanged and agreed on by both parties: you and the game provider. DeBets implements a secure communication channel between the player device and the gameserver that enables you (as the player) and the game provider (as the game) to transact off the blockchain using a mechanism that is based on public-key cryptography.

What follows is a high level description of the inner workings of the Payment Channel.

Both the player and the game provider have a public key. The player public key is automatically generated by DeBets App and the corresponding private key is stored in the player device (your browser). The game provider public key is also generated by DeBets Server and its private key is stored securely on the server. DeBets generates one distinct public key for each cryptocurrency supported by the game provider.

The player public and private keys and the game provider public key can be obtained from the main view of DeBets App by clicking on the two buttons located inside the box labaled Off-chain protocol keys:

Each deposit is linked to the public key of the player that created it and to the public key of the game provider that corresponds to the cryptocurrency in use.
The Payment Channel mechanism consists in player and game provider to continuosly update and mutually agree on a message whose content represents the current balance of the player in the deposit. As already mentioned the balance of a deposit corresponds to the amount initially deposited minus the amount bet plus the amount won and therefore agreeing on the balance means agreeing on what has been bet and won up to any given moment.

But how does it actually work?
To better understand what will be explained you should have a basic knowledge of Public-key cryptography.
When the player bets (start of a new game round) DeBets App creates a message that reflects the change in the balance (the amount bet is deducted from the player balance) and then signs this message on behalf of the player using his private key. It then uses the communication channel to send the message to DeBets Server, which acts on behalf of the game provider. The server in turn knows the information inside the deposit that is being used (the deposit data is written in the Smart Contract and therefore it can be read from the blockchain) so it is aware of the public key of the player and it can use it to verify that the player signature is correct. If the verification is successful then the server has assured itself of the following:

• the signature could only be produced by the player, because only the owner of the private key can produce a valid signature that matches the corresponding public key. This process identifies the player as the signer of the message: nobody else could have produced such message
• the message correponds exactly to the amount that the player wants to bet, because this is the only amount that once deducted from the balance would yields to that specific message

In practical terms these two statements represent, with absolute certainty, the intent of the player to bet that exact amount and guarantee that the initiator of the bet is the player that owns the deposit in use.
After verifying the player message for the requestd bet, DeBets Server accepts the bet, signs the same message using the game provider private key and then sends back the message to the player.
DeBets App receives the message from the server and acts symmetrically: it uses the public key of the game provider in the deposit to verify the game provider signature. If the verification is successful then DeBets App knows that the game provider has accepted the bet because nobody else could produce such signature on its behalf given that the corresponding private key is securely stored on DeBets Server.

This is basically the end of the mutual verification process for the bet request: both player and game provider have agreed on the player balance after the bet has been deducted from it.

So far we have seen how a bet event is handled within the Payment Channel. But we know that the player balance also changes every time the player wins (end of a game round).
The win event is handled in the same way as the bet, with the only difference that the change of the balance originates in the server of the game provider. In this case DeBets Server updates the balance by adding the amount won to it and creates a message representing the new balance. It then signs this message on behalf of the game provider using its private key and then sends the message to DeBets App.
What happens from now on is the same as what we have seen for the bet event, but with the two parties inverted: DeBets App verifies the signature of the game provider, accepts the win, signs the message with the player key and sends it back to the server which in turn verifies that the player signature is correct: player and game provider have again mutually agreed on the new balance.

Now that you have a basic knowledge of the Payment Channel you are able to understand how the closing of a deposit works.
Let's first clarify what it means to close a deposit. In simple terms closing a deposit is the process of invoking the Smart Contract in order to request it to send the amount due to each of the two parties: player and game provider.
The amount due to each party depends on the final balance of the deposit which is given by:

balance = amount_deposited + amount_won - amount_bet

Where:

• amount_deposited is the amount initially deposited by the player when the deposit was created
• amount_won is the sum of the wins from all game rounds that were played under that deposit
• amount_bet is the sum of the bets that the player made using that deposit

Hence when the deposit is closed the player has either lost some or all of the funds he deposited or he has made a winning, in the latter case the balance will be higher than the amount he deposited.

In case of a winning the amount won by the player corresponds to the difference between the final balance and the amount deposited. Upon closing the deposit the Smart Contract sends to the player in a single transaction the amount that he originally deposited plus the amount that he has won, taking the latter from the funds that the game provider holds in the Smart Contract.

If instead the player has lost part of his funds then the final balance is lower than the amount deposited and the difference between these two is the winning of the game provider. In this case the Smart Contract in a single transaction sends to the player the amount
of the deposit that he has left and then it adds the amount lost by the player to the funds that the game provider holds in the contract.

From what has been explained it should be clear that the position of the player and the game provider in the closing of a deposit are symmetrical: both player and game provider can either make a winning or lose funds, when one party makes a winning it results in a loss of the same amount for the other party.
What instead is not symmetrical is the exposure of the two parties: the player can lose no more than the amount he orginally deposited because this is what is available in the deposit to be spent. Instead there is no limit for the amount that the player can win, and the winning is paid automatically by the Smart Contract using the funds that it holds for the game provider.

Game providers are required to hold funds in the Smart Contract for each cryptocurrency that they want to support. These funds are used by the Smart Contract to pay the player winnings automatically.
Closing a deposit that results in a winning for the player decreases the game provider balance because the Smart Contract uses part of it to pay the winning to the player. On the contrary, closing a deposit that results in a loss for the player increases the game provider balance in the Smart Contract because the amount lost by the player is added to it.

You may now be wondering what happens when upon closing a deposit the balance of the game provider in the Smart Contract is not enough to cover the winning of the player. In this case the Smart Contract sends to the player the amount that he deposited and the part of his winning which can be covered with the current balance of the game provider but then, instead of closing the deposit it marks the deposit as in DUE PAYMENT. This is a state that represents a deposit that is waiting for a payment from the game provider in order to be closed by the Smart Contract.
How does the game provider pay the amount due? The game provider must add funds to the Smart Contract and increase its balance.
As soon as the balance is enough to pay for the amount due then the Smart Contract immediately uses it to pay for the reminder of the player winning and then it closes the deposit.
This situation may seem to be an unfavorable for the player, given that he has to wait for the game provider to add funds to the Smart Contract before his winning is paid entirely.
The following factors guarantee that game providers not only will pay any pending amount, but also will expedite the process of adding funds to the Smart Contract so that players don't have to wait long for their winnings to be fully paid:

• DeBets uses a score system that ranks game providers based on their trustworthiness, fairness and expedition in pay player winnings. This forces game providers to keep enough funds in the Smart Contract in order to cover the player winnings, making it possible for the Smart Contract to pay the winnings immediately when deposits are being closed, thus avoiding to fall back to the DUE PAYMENT state. Anytime a deposit ends up in DUE PAYMENT state the score of the game provider decreseas and it continues to decrease until the game provider injects funds into the Smart Contract. A decreasing score deteriorates dramatically the reputation of the game provider.

• DeBets also displays the percentage of player winnings that have been paid by each game provider. It is crucial for a game provider to maintain this percentage at 100% so that players are assured that the winnings are always paid

• All information that makes up the game provider score and the data needed to compute the percentage of player winnings that have been paid by the game provider is stored in the Smart Contract and therefore it is publicly available. The immutability of the blockchain guarantees that such information cannot be counterfeit or altered by anybody. Thus anyone can verify that the information displayed on DeBets website is correct because the data needed for this purpose can be extracted from the blockchain by invoking the Smart Contract (all data in the Smart Contract can be read from the block explorer)

Therefore the event that a game provider has not paid entirely the winning of a player will immediately lower the score of the game provider and decrease the percentage of paid winnings to a value lower than 100% and all of this will be visible by the users in both DeBets website and in the block explorer.
The only way for the game provider to clear such negative information for its reputation is to pay the player winning as fast as possible.

There are multiple ways for you to know what is the balance of a game provider in the Smart Contract for a given cryptocurrency.
This is an important information that you may want to check when you are about to make a deposit if you want to be reassured that the game provider has enough funds in the Smart Contract to pay for your winnings immediately. Again, it is important to underline that even though the game provider balance is not enough to cover your winning at the moment you request the closing of a deposit your winning will still be paid entirely as soon as the game provider adds more funds into the Smart Contract after being notified.

You can get the game provider balance in one of the following ways:

1. from the dialog that shows up when you launch a game in DeBets website.
2. opening the game provider page in DeBets website by clicking on a game provider in the main page. At the top right of this page you can see all supported cryptocurrency for that provider and for each cryptocurrency a box shows the corresponding balance of the game provider in the Smart Contract, the game provider public key and other information like the minimum deposit amount.
3. opening the Smart Contract page in the block explorer by clicking on the Smart Contract button at the top of DeBets main page. Then from there you go to the Contract section and click on Read. Look for the method called getServerBalance and input the public key of the game provider that corresponds to the cryptocurrency you want to check (read the previous point to know how to obtain this key).

The following table summarizes the three cases that characterize the closing of a deposit: the first one results in a winning for the player, the second one results in the player losing entirely the amount that he deposited and the latter one results in losing part of it.

As already explained DeBets Smart Contract controls the closing of each deposit and regulates the final flowing of funds. We will now explain the underlying mechanism involved when closing the deposit which guarantees that:

• the player can withdraw his funds (amount deposited and amount won if any) at any time
• the game provider receives the amount lost by the player if any
• none of the two parties, player and game provider, can cheat by requesting the Smart Contract to close the deposit with a balance different from what the two parties have agreed through the Payment Channel

Both player and game provider can call the Smart Contract to request it to close a deposit. Being the owner of the deposit the player is allowed to close the deposit at any time. The game provider instead can only request the Smart Contract to close the deposit if certain conditions are met. First of all for the game provider can only request closing the deposit if the player balance is lower than the amount he deposited. That is, as long as the player balance is not below the amount deposited the game provider has no right to close the deposit, because no found is due to it. In addition to this one of the following conditions must be met:

• the player balance must be lower than the minimum balance allowed
• the amount of time passed since the creation of the deposit must exceed the deposit duration

The conditions above depend on two important parameters: the minimum balance and the deposit duration.
The minimum balance represents the amount below which game providers are allowed to request closing a deposit when the player is in loss. The minimum balance is set to a small value and you can find out what it is by looking at the cryptocurrencies box at the top of the game provider page:

The deposit duration represents a grace period during which the game provider is not allowed to request closing a deposit even if the player is in loss. This is to guarantee the player with a minimum duration for his deposit even in the case of a loss, giving him time to recover from the loss or time to play out of the full amount deposited.
When a deposit is created the minimum duration is set to one week. This initial duration of one week corresponds to the amount deposited initially when creating the deposit. Anytime you add funds to an existing deposit the deposit duration is extended by a time that correponds to the initial duration multiplied by the ratio between the funds you are adding and the inital amount deposited. When the amount of funds added is higher than what was deposited originally then the duration is only extended by a time equal to the initial duration. Example: if you are adding 100$ or you are adding 200$ to a 100$ deposit then the deposit duration is extended by one more week, if you add 50$ to a 100$ deposit then the duration is extended by half a week.
You can find out what is the remaining duration of your deposits from the Deposits list in the Player page on DeBets website:

To close the deposit the Smart Contract requires the closing party to provide the signatures made by each of the two parties for the message that represents the final balance of the deposit. If the player wants to close the deposit, DeBets App will have to provide on behalf of the player a message whose value represents the final balance of the deposit together with both signatures for that message: the one made using the player private key and one made by the game provider using its own private key. In the same way, in order to close the deposit with a given balance the game provider must provide not only its own signature for the corresponding message but also the one that it received from DeBets App representing the signature of the player.
This guarantees that none of the two parties can cheat by closing the deposit with a balance that does not correspond to the correct value. That's because none of the two parties can be in possession of the signature made by the other party without having received it from it. In fact public-key cryptography guarantees that only the possessor of the private key can produce the signature.
Therefore the Smart Contract only accepts closing the deposit with a balance that has been exchanged and agreed on by both parties, player and game provider, because only in this case the closing party will be able to provide both signatures. Upon receiving the close request the Smart Contract validates the two signatures and verifies that they correspond to the respective public keys stored in the deposit data on the blockchain.
But how does the Smart Contract guarantee that one party is not trying to close the deposit using a previous balance that is not the final one? Consider for example the case of a player that deposits 100 USDT and is winning 20 USDT after 10 minutes but then eventually loses all his balance. He could try to close the deposit using the signature that DeBets App received from the game provider after 10 minutes, when his balance was 120 USDT. This problem is solved with the introduction of two things:

• a Nonce is added to the message that represents the final balance of the deposit. The Nonce is a number that increases by one each time the balance is updated (as a result of a bet or a win taking place). Using the Nonce not only guarantees that the updates of the balance never results in the same message even if the balance goes back to a value that has previously occurred, but also introduces a criteria to distinguish between two messages which one corresponds to the most recent balance: the one with the higher Nonce. While the game is being played, player and game provider transact through the Payment Channel sending each other a messages that represent the current balance of the deposit and the current Nonce.

• the closing of the deposit by the Smart Contract is turned into a two steps process where each of the two parties has the chance to provide the message corresponding to the final balance (in doing this it is still necessary for each party to provide the signatures of both parties as none of the two parties can close the deposit with a balance that wasn't agreed by the other one).
  When one party requests to close the deposit the Smart Contract allows a grace period where the other party has time to close it in turn by providing the final balance and the two signatures.
  After receiving the close requests from both parties the Smart Contract will finally close the deposit accepting the balance message that corresponds to the highest Nonce. If the second closing party does not send the close request within the grace period then the Smart Contract allows the party that sent the initial close request to close the deposit accepting the final balance that was provided by it

To summarize, the introduction of the Nonce and the two steps closing mechanism guarantee that none of the two parties can cheat by closing the deposit with a previous balance and that none of the two parties can cheat by refusing to send the close request in order to prevent the deposit from getting closed.

At this point the closing mechanism of a deposit should be clear to you.
You might still be wondering one thing though: if a player opens a deposit and never plays any game then there is no message exchanged through the Payment Channel and no balance update agreed between player and game provider. In this case the deposit balance corresponds to the amount initially deposited and if the player wants to close the deposit and withdraw it then DeBets App is unable to fullfill this request because it does not have the game provider signature for the initial balance. So in this situation DeBets App in unable to provide the Smart Contract with the required information to request it to close the deposit. Of course this is not acceptable: the player is the owner of the deposit and therefore he should be able to get back his funds at any time, even without playing any game.
The Smart Contract solves this case by allowing only the player to request the closing of the deposit without providing the two signatures provided that the Nonce in the message that represents the balance is zero. A zero value for the Nonce means that no bet nor win took place for that deposit and therefore the player should be allowed to withdraw the balance. It's important to underline that even in this case the Smart Contract relies on the two steps closing mechanism, giving the game provider time to submit a close request with a higher Nonce (in this case the game provider will have to provide the signatures of both parties as usual) thus making it impossible for the player to cheat.