Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Coming Soon
Loading...
Six Sigma Sports is a licensed sports betting application and takes its responsibilities seriously. In order to use the application you must register an account and successfully complete the KYC process. The KYC process includes:
Liveliness check
ID Verification
Proof of Address
Users must not be present or reside in certain countries, including The United States and The United Kingdom ("Excluded Locations"); Please reference the T&C's for full details and note this list may be updated from time to time.
House mode allows the user to be “The House”. “The House” refers to the role of an operator of a casino establishment, of a sportsbook, or any "house" where gambling activities are hosted. Implicit in the definition of “the House”, is the operator’s role in setting the rules, providing the games, and holding a stake in the betting outcomes.
The term also reflects the casino's inherent advantage in almost all games, known as the "house edge". This advantage ensures that, over time, the casino will make a profit, as the odds are slightly tilted in its favor across various games.
Conceptually, the house edge represents the operator’s built-in advantage to secure its profits over time. The game is structured so that, even though players make their decisions and can employ strategies, the rules inherently favor the house. This slight advantage ensures that, while individual players might win in the short term, the casino will come out ahead in the long run. The house edge is designed in a way to maintain a balance between providing an entertaining experience, offering players a chance to win and ensuring the casino's profitability.
Six Sigma Sports is excited to unveil a new innovative platform, providing users with a unique opportunity to engage in sports betting as "The House," taking advantage of the inherent "House's Edge". The Six Sigma Sports application affords users the flexibility to either place bets using a familiar sportsbook interface or to participate across betting markets in the capacity of "The House." This seamless transition between roles is facilitated by a user-friendly toggle switch within our application, ensuring a smooth and intuitive experience.
In order to engage as the House, first a user must identify a specific market within a fixture they feel is attractive to participate in. Once identified, the user contributes liquidity and takes their place in a queue managed by the application. When the user selects to participate in a market, they accept all bets from bettors, up to the payout capacity contributed, at the prevailing market odds. Users should monitor odds and any other news developments that may happen leading up to a match, just as a sportsbook operator would. House users will have the option to withdraw unused liquidity at any time.
Example:
A user wants to participate as the House in the English Premier League Match - Fulham - Manchester United. In order to participate, the user selects “View Bets” to enter the House mode on this specific fixture.
Upon selecting “View Bets”, all bets that are available to participate as the House are listed. The user selects the individual market to participate.
In this particular scenario, the user has opted to engage in the "3 Way Result" market.
On the interface, three key pieces of information are displayed: "0 / 0 SGE / 154.9225 SGE."
The first value, "0," indicates the total number of bets that have been placed in this market.
The second value, "0 SGE," represents the cumulative value of all the bets that have been placed in this market.
The third value, "154.9225 SGE," signifies the amount of SGE (the platform's native currency) that all users have committed to the market in order to participate as the House.
To proceed, the user is required to deposit a sum of SGE into the market, with the minimum deposit currently set at 10 SGE. By selecting the “Be The House” option, the user will be directed to the House Slip, which summarizes the details of the transaction and prepares it to be signed and recorded on the blockchain.
The user must select “accept all odds and line changes” as a condition to participate as the House. Once selected, the user can deposit their SGE tokens into the market by selecting “Be The House”.
Upon selection, this will bring up the wallet transaction confirmation display. (This example displays a Keplr wallet). Once the user selects approve, the transaction will be processed via the SGE Network and the user will be placed into the order book for the house.
Now that the user is positioned in the order book, they will accept bets alongside other
participants as “the House”.
When a user participates as The House, the user is essentially an active liquidity provider. When they deposit SGE into a market, the user is committing to take the other side of all bets placed in the market at the prevailing odds. The allocation of bets, examined in more detail later, is dependent on the user’s position in the order book and any existing bets they have taken.
It is important to note that participating as the House does NOT guarantee a positive result nor does it guarantee offset risk. In reality, sportsbooks often do not see balanced flow and do experience the gain and loss volatility associated with any single or small group of events. The performance of a sportsbook should be measured over large number of bets and an extended period of time.
The deposited amount determines the user's maximum risk exposure (maximum loss) when participating as the House. To illustrate, if a user deposits 50 SGE into a market as The House, their potential loss is strictly limited to 50 SGE. This maximum risk exposure represents the potential payout, and therefore is likely to be reached while accepting bets that amount to less than 50 SGE.
User deposits into a market as The House are organized in a sequential order, based on the time at which each deposit was made, adhering to a first-come, first-serve principle. When a user occupies the “top” position in the order book, they are allocated all incoming bets across the various outcomes within the market, until their capacity is used. After fulfilling this initial capacity, the user’s “re-usable” capacity is calculated, before moving them to the back of the queue. This systematic approach ensures a fair and orderly distribution of bets among users participating as The House.
Odds Source: The application uses a data provider that supplies odds which we expect to be in-line with the broader market.
First let’s start with some relevant definitions:
Break-Evens: A break-even percentage, also referred to as Implied Odds, is the percentage of time a bet must win for you to neither win nor lose money making the bet over time at the odds in question.
True-Odds: True Odds, in theory represents the actual probability of an event happening. In practice, bettors and sportsbooks utilize various proprietary methods to arrive at what they believe are the “True Odds” of an event. One can also estimate the True Odds implied in a set of published odds. The first version of the House functionality on Six Sigma Sports utilizes the equal margin method to do so, which simply applies the total margin equally to each betting outcome to arrive at the True Odds.
Summing the Break-Even (Implied Odds) percentages across outcomes on a market will typically add up to >100%. We know the probabilities of an event cannot be greater than 100%, and the difference between the observed implied probabilities of the odds offered by a sportsbook and True Odds represents the Vig (House Edge) of the Sportsbook.
Applying the above concepts to the Six Sigma Sports House:
At the time of contribution to the House, the user’s submitted amount is split and allocated across the potential market outcomes in what we refer to as a “True Odds Ratio”. Mathematically speaking, if the sportsbook were to accept bets at those odds and in the True Odds Ratio, it would yield a risk-free positive result; No matter the event outcome, the sportsbook would earn the Vig implied in those odds; the House, including a user’s house deposit, would be a winner in any scenario. It is important to note, odds change and betting flow is unlikely to be “perfectly” balanced. The chances of achieving offset risk is highly dependent on one’s position in the House order book, the amount of betting flow in the book, and the volatility of the odds.
The order book further optimizes the process for every participant by treating each “outcome vertical” independently, even when evaluating overall risk and capacity. Once House participants start engaging in bets, this benefits users by maintaining their position in the queue to accept offsetting risk.
Let’s look at an illustrated example:
· Here we have a hypothetical SouthHampton (H) v. Manchester United (A) football match. For the provided odds, we can calculate the break-evens and estimate the True Odds. As you see here the House Vig is approximately 7.6%.
· The first House User contributes 2,000 SGE into the order book, which net of a 50bps fee, creates a capacity of 1,990 SGE. Remember, this represents the user’s max loss and payout capacity.
· In order to ensure the supplied payout capacity cannot be exceeded, the capacity calculation is first “anchored” to the outcome with the longest odds. Here we see that the bet capacity implied by a max payout of 1,990 SGE, if fully engaged on a single outcome, would be most limited by the 4.2 odds for Southampton to win, allowing House User 1 to accept a maximum of 622 SGE in bets for Southampton. From there, the available capacity for each other “outcome vertical”, Draw and Away (ManUnited), is calculated based on the True Odds ratio previously discussed.
· As you can see in the box titled House User Exposure, the red line illustrates the max loss if a user took only single-direction bets in each outcome. The P&L line below illustrates how the House wins under any scenario (+199 SGE), if the sportsbook accepts bets in the True Odds Ratio with the odds unchanged.
· The last section titled House Order Book, illustrates what happens in an order book of 3 House Users that is engaged by 2 different bettors. In particular, note that when Bettor 1 takes all the capacity of House User 1 for the Home team, the order book is updated to reflect this reduced capacity, but maintains House User’s 1 position under the other outcome verticals (Draw & Away) in order to be prioritized to benefit from offset risk.
· The allocation of capital across outcomes is updated for both executed bets and changing odds.
· This positioning is maintained until the user’s remaining capacity in the other outcomes is engaged OR the odds change to such a degree that capacity is reduced to 0 because taking additional bets on those outcomes would no longer be risk-reducing. At the realization of either of those 2 outcomes, the user is recycled to the back of the order book with any remaining capacity they have, thus creating capital efficiency and the opportunity for the House user to engage additional bets. [Note this capacity calculation is equal to the user’s original contribution, less the max loss possible from the bets they have engaged. Hypothetically, if perfectly offset risk was achieved in a true odds ratio, the user would be able to re-use 100% of their original contribution).
· A few notes regarding withdrawals of House liquidity:
o A house user will be able to withdraw unused liquidity at any time.
o There are no partial withdrawals. Currently, if withdrawing, it must be for 100% of unused liquidity.
o Once a user’s capacity has been fully engaged, and is therefore “recycled” to the back of the queue, withdrawal is no longer possible.
Participating as the House is still betting; It is not guaranteed to be risk free, but you can never lose more money than your deposit.
First come, first serve. Those who deposit first receive the first bets.
Odds changes can limit or reduce the value of bets allocated. Odds changes are unpredictable. Our design ensures our first principle is always maintained, even if this reduces the maximum amount of risk allocatable to each user.
You can, and are likely, to end with some directional risk. Flow is rarely perfectly balanced, even if you are early to contribute liquidity to a market.
It is the user’s responsibility to monitor odds changes and market news just as a sportsbook operator would.
The more often and earlier a user engages as the House and the more bets are placed, the more profitable a house depositor can be over the long term. The key to success is to participate frequently and to encourage bettors to bet in markets where you provide liquidity.
Good luck !
SGE blockchain application bet module description
The Bet module receives and processes requests to accept wagers and settles bets. In the case of wagering, it validates the request and places the bet.
For the settlement, the blockchain automatically queries resolved markets and then for each of these markets, checks the result of the market, and determines the betting result, then the order book
The module responsible for the participation and fund management distribution will transfer the calculated values to the participants and the bettor accounts according to the settlement status.
SGE blockchain application specification and main concepts explanation
In the SGE Network chain, a bet is an entity that represents the details of a wager being placed on the system by the bettor. A bet is placed when a user wager tokens on particular odds of an event.
A bet is defined by:
Bet Fee: If in force, tokens may be deducted from the total number of wagered tokens as a bet fee. The purpose of deducting the betting fee from the wagered amount is to facilitate the expenses of the background operations that take place to complete an entire bet life cycle.
Payout: This is the number of tokens to be given back to the bettor if he wins the bet. For detailed calculations, have a look at
Max Loss Multiplier: This is a coefficient that is being used while calculating the available liquidity to be assigned for a bet to be fulfilled. In other words, this is the worst-case multiplier for a house that all of the bets get winner and the house should pay for all of them. This is different for each odds of a market.
A market is a registered sporting event that takes place in the real world and has been added to the blockchain from an authentic source.
Every Market has multiple odds on which the user can bet. For example, in a match between two teams and a 3-way result bet, the odds can be for Team A to win, Team B to win, or a draw. These odds determine the value of the payout to the user if he wins the bet.
The house is a representation of a betting house that is responsible for paying out the winner's profit. this module takes care of guaranteeing the final payment of the odds and prevents the SR pool module account to be bankrupt. Users can participate in the market as a house and get rewards according to their deposit amounts.
The order book is responsible for the management of the participation of depositors of a market and the payout of the bettor's winning amount from the participant's deposited amounts. All of the calculations regarding participation and payouts are taking place in this module.
The OVM module is responsible for the validation and unmarshalling of the JWT tickets used by the blockchain modules. The trusted public keys are stored in the OVM module parameters and can be replaced with a proposal and voting mechanism.
A ticket or a JWT ticket is used as an origin verification mechanism for pushing data to the blockchain. It is used to verify that any transaction made to the blockchain, such as a market addition, bet placement, etc, contains data from an authentic source. A ticket has an issued timestamp and an expiry timestamp, between which the ticket will be valid and can be used to make the transactions in the system. For more details on the ticket, visit the Guide/JWT ticket.
In the SGE Network chain, a payload is JSON data that contains the details of an entity. A payload can be useful for making transactions. The transactions related to the market
, bet
, and, the house
modules require a JWT ticket. The creation of a JWT ticket requires JSON data related to the transaction, which we call a payload. Apart from the data required for the transaction, every payload should have fields named, iat
means issue timestamp, and, ext
means expiry timestamp. The payloads, if required, are stated in the CLI
section of each module.
It is the unique identifier of an entity in the blockchain. The entities which can be uniquely identified by a UID are:
Bet
Market
Odds
Order Books
The format of UUID (or unique universal identifier) accepted in the blockchain is the format of a UUID. UUIDs are a sequence of digits equal to 128 bits. It accepts hexadecimal digits, i.e., 0-9 and a-f. The hexadecimal digits are grouped as 32 hexadecimal characters with four hyphens:
SGE and the Six Sigma Sports application
The SGE token serves several purposes:
· It is the native token of the SGE Network that helps secure the PoS blockchain and facilitate on-chain governance.
· It is the initial denomination for all activity in the Six Sigma Sports application.
· It is the Key to access the House functionality of the Six Sigma Sports application.
Important Notes to the illustrations and figures
· It is important to observe that the following illustrations are not 100% fixed as there are dynamic inputs which could impact the figures and are unknown at this time.
· The lock (and corresponding unlock) figures represent the most accelerated path possible. Token locks may be extended in the future.
· Application Rewards are primarily reserved for user acquisition and will be offered to bettors in the Six Sigma Sports application.
· The Strategic Reserve (SR) is the Six Sigma Sports House actor. We will use the SR to be the first and last line of liquidity for the sportsbook. Once the sportsbook is live, the size of the SR will also be variable depending on results. Please see the Six Sigma Sports GitBook for further details (https://six-sigma-sports.gitbook.io/docs/)
· Other definitions as used in the illustrations:
o Total Supply = Tokens that have been minted by the blockchain.
o Inflation = Max Supply - Total Supply (& is automatically distributed to validators/delegators)
o “Circulating Supply” = Total Supply - Locked Tokens
o “Circulating Supply” includes the Strategic Reserve (100M) and Application Rewards (up to 511M) as they are not locked on chain. However, the initial distribution of Application Rewards (betting incentives) will be variable and correspond to the engagement and reward programs of the application. As the application scales, so will reward token distribution, but this is not on a fixed schedule.
The token distribution at genesis can be categorized as follows:
Bet Amount: This is the remaining number of tokens after the deduction of the betting fee from the total wagered amount. This is the amount for which the wager is actually placed.
Payout Profit: This is the pure winning amount of a bet that represents the profit portion of the payout only.
Bet module, module accounts definition.
There is one account in the Bet module.
Bet Fee Collector: This account holds the betting fee transferred from the bettor to the bet_fee_collector
module account.
During bet wagering, the betting fee is transferred from the bettor's account to the bet module account of the Bet module.
Name of the account: bet_fee_collector
The main logic of the Bet module definitions and methods.
There are several steps for an incoming bet to be placed:
Check for duplicate UID
Validate the Ticket and unmarshal it to the wager payload type types.WagerTicketPayload
KYC validation according to the creator address in the message and the KYC address of the ticket if required.
Get the corresponding market from the market module and validate the odds existence.
Validate the minimum bet amount according to the module parameters.
Calculate and set the betting fee.
Validate and calculate the payout profit according to the odds type, bet amount, and odds value.
Call ProcessWager
method of the Order Book module. this method handles the lock/unlock of the payout, participations, and bet fulfillments and transfers the payout and fees to the corresponding module accounts.
Set the initial Status
, Result
,CreatedAt
, and BetFulfillments
attributes.
Calculate the sequential ID, Set bet statistics, and bet to the bet module state.
There are several steps for an incoming bet to be settled:
Check UUID validity
Get the corresponding bet object
Validates the bet creator stored in the state with the incoming bettorAddress
of the settlement message.
Check the bet status not to be canceled or settled before.
Get the corresponding market from the market store and check if it exists, and is not aborted or canceled. If it is, calculate the payout and refund the bettor using RefundBettor
method of the Order Book module keeper then sets the bet status as settled and finalizes the method.
Sets the proper bet result according to the WinnerOddsUIDs
.
According to the bet result determined in the previous step, call BettorWins
or BettorLoses
of the Order Book module keeper.
Set the settled bet in the bet module state.
This is being used in the bet module end blocker in order to settle the bets automatically in batch.
Bet module CLI.
This section specifies the queries, transactions, and required payloads. By following this section, one can get a deep understanding of the functioning of the bet
module in the SGE Network chain.
This section elaborates on the transaction message handler methods being exposed by the Bet module.
When a wager transaction is processed, the following things happen:
If KYC is not ignored, KYC validation of the user should be approved and KYC ID should be equal to the creator's address.
Then, invoke the OVM module to validate the ticket.
After the ticket validation, the Order Book module is invoked to manage the transfer of funds involved in the process and distribute the participation exposures.
Then, a new bet will be created with the given data and stored in the bet module's KVStore, in the following way:
The RPC for adding a market is as follows:
The request message for Wager
is MsgWager
. The proto for the request message is as follows:
The response message Wager
is MsgWagerResponse
. The proto for the request message is as follows:
Bet module parameter types and definition.
The Bet module has the following parameters:
Batch Settlement Count: this is the count of bets to be settled automatically in each block.
Max bet by UID query count: is the max count of bets to be returned in the bets by UID list query.
Constraints: contains the bet wagering constraints.
The proto for the params is as follows:
Constraints define the constraints that will apply while accepting bets. The following constraints can be applied to the bet acceptance criteria:
Min Amount: Blockchain should not accept bets with a bet amount (after the deduction of the bet fee) less than the value stored in this field.
Fee: Blockchain should set a fee for every bet it accepts.
The proto for the constraints are as follows:
Bet module CLI queries.
Queries of this module can be used to get the data of bets placed in the blockchain and params. The following queries have been exposed by the Bet module:
Queries of this module can be used to get the data of bets placed in the blockchain and params. The following queries have been exposed by the Bet module:
The below table explains the details of the argument required for the above query:
The below table explains the details of the argument required for the above query:
The below table explains the details of the argument required for the above query:
The below table explains the details of the argument required for the above query:
The creator:uid pair is separated by a colon :
and each pair is separated by a comma ,
from other pairs.
Defines the way in which the state of the Bet is being stored in the chain.
The Bet message is used to store the data of a particular bet placed in the blockchain. The bet entity consists of the following fields:
uid
: It is the unique identifier of a bet.
market_uid
: It is the unique identifier of a market.
odds_uid
: It is the unique identifier of an odds.
odds_type
: It denotes the type of odds.
odds_value
: It is the value of odds
amount
: It is the total wager amount for a bet.
bet_fee
: It is the number of tokens deducted from the amount (or total wager amount) as the betting fee.
status
: It denotes the status of the bet that whether the bet is placed or settled, etc.
result
: It is the result of the bet after the bet settlement.
creator
: It is the creator of the transaction, which means the Bettor.
created_at
: It is the timestamp at which the bet was placed on the system.
settlement_height
: is the height at that the bet will be settled.
max_loss_multiplier
: is the multiplier coefficient of the maximum loss.
bet_fulfillment
: is the fulfillment of the participation item and payout amount.
The proto for the Bet messages is as follows:
It states the various types of the state a bet can have throughout its lifetime.
It states the various types of states the result of a bet can have after the bet settlement.
It states the various types of odds that the system supports.
The Bet message is used to store the map of UIDs and sequential numeric IDs generated by the blockchain:
The active bet holds the information required for the bets that are not settled yet.
The active bet holds the information required for the bets that are settled.
The Bet message is used to store any statistics that need to be tracked by the blockchain, currently, it tracks the total count of bets only.
The fulfillment data structure for the participation and payout amount.
Note: Let bet_amount be 3564819
Decimal(European): Calculated as bet_amount * oddsValue
ex. 3564819 * 1.29 = 4598616.51
.
Fractional(British): Calculated as bet_amount + (bet_amount * fraction)
ex. 3564819 + (3564819 * 2/7) = 4583338.71
.
Moneyline(American): Calculated as:
Positive odds value: bet_amount + (bet_amount * |oddsValue/100|)
ex. 3564819 + 3564819 * |+350/100| = 16041685.50
the result will be rounded to floor.
Negative odds value: bet_amount + (bet_amount * |100/oddsValue|)
ex. 3564819 + 3564819 * |100/-350| = 4583338.71
the result will be rounded to floor.
Some of the Online Calculators round the division result to two-digit precision in Fractional and Moneyline calculations. In other words, these online calculators try to convert Moneyline and Fractional odds to Decimal odds and then calculate the payout according to the calculated rounded decimal value. This approach makes a big difference in the resulting payout. SGE-Network is accepting bets with usge that may have a high value in the market. For this kind of value, it is better to have a high-precision calculation in the blockchain code.
Note: The final calculated payout amounts are rounded to 2-digit float values, so we have a small portion of lost benefits/payouts.
Params | Description | Type | Validation | Example |
---|
Params | Description | Type | Validation | Example |
---|
Params | Description | Type | Validation | Example |
---|
Params | Description | Type | Validation | Example |
---|
creator | creator account address | string |
| sge1059gavv45jdp0l7c4kkskr0jae02j9cxmjr3f3 |
uid | UID of market | string |
| 0435e5b6-635f-11ed-90a6-bb470175dfce |
creator | creator account address | string |
| sge1059gavv45jdp0l7c4kkskr0jae02j9cxmjr3f3 |
UID | UUID of the bet | string |
| 0435e5b6-635f-11ed-90a6-bb470175dfce |
creator:uid | creator account address and UID pair list | string |
| sge1059gavv45jdp0l7c4kkskr0jae02j9cxmjr3f3:0435e5b6-635f-11ed-90a6-bb470175dfce |
House module, module accounts definition.
There is one account in the Accounts module.
House Fee Collector: This account holds the participation fee of all participants.
Name of the account: house_fee_collector
House module parameter types and definition.
The House module has the following parameters:
Min Deposit: minimum allowed amount of deposit.
House Participation Fee: the fee that the depositor needs to pay to become the house of a market
The proto for the params is as follows:
Defines the way in which the state of the House is being stored in the chain.
The Deposit message is used to store the data of a particular deposition in the blockchain. The deposit is allowed on the markets that are in Active
status. The deposit entity consists of the following fields:
creator
: The address of the deposit message creator account.
depositor_address
: The address of the depositor.
market_uid
: It is the unique identifier of a market.
participation_index
: The index of the participation of the market.
amount
: The amount of the deposit.
fee
: The amount of paid fee for the deposition.
liquidity
: The amount of available liquid amount for participation (amount - fee).
withdraw_count
: The count of withdrawals on a deposit.
total_withdraw_amount
: The total amount of withdrawal value till now.
The proto for the Deposit messages is as follows:
The Withdraw message is used to store the data of a particular withdrawal in the blockchain. The withdraw entity consists of the following fields:
creator
: The withdrawal message creator address.
id
: The sequential ID of withdrawal generated by the blockchain.
address
: The address of the depositor account.
market_uid
: It is the unique identifier of a market.
participation_index
: The index of the participants created when deposited.
mode
: The mode of withdrawal.
amount
: The amount of withdrawal.
The proto for the withdrawal messages is as follows:
House module CLI.
This section specifies the queries, transactions, and required payloads. By following this section, one can get a deep understanding of the functioning of the house
module in the SGE Network chain.
This section elaborates on the transaction message handler methods being exposed by the House module.
When a deposit transaction is processed, the following things happen:
Validate the incoming deposit message.
Call the Deposit
method of the keeper.
The RPC for adding a market is as follows:
The request message for Deposit
is MsgDeposit
. The proto for the request message is as follows:
The response message for Deposit
is MsgDepositResponse
. The proto for the request message is as follows:
When a withdrawal transaction is processed, the following things happen:
Validate the incoming deposit message.
Call the Deposit
method of the keeper.
The RPC for adding a market is as follows:
The request message for Withdraw
is MsgWithdraw
. The proto for the request message is as follows:
The response message for Withdraw
is MsgWithdrawResponse
. The proto for the request message is as follows:
The exposed transactions CLI commands and ticket payloads by the Bet module.
The below transaction can be used to place a bet on the blockchain.
The below table specifies the details of the arguments used in the above transaction:
The payload for the place-bet transaction is as follows:
The values in the payload should be changed according to the data.
The details of the payload parameters are stated in the below table:
House module CLI queries.
The below table explains the details of the argument required for the above query:
The below table explains the details of the argument required for the above query:
The below table explains the details of the argument required for the above query:
The below transaction can be used to deposit on the blockchain.
The below table specifies the details of the arguments used in the above transaction:
The below transaction can be used to withdraw on the blockchain.
The below table specifies the details of the arguments used in the above transaction:
The main logic of the House module definitions and methods.
There are several steps for a deposit to be made:
Set participation fee.
Initiate participation in the market by order book module.
Set the participation index generated by the order book module.
Check the authz grant to be available for the message creator and depositor address in the ticket.
Update authz spend limit or delete if is zero.
Set the deposit in the state of the blockchain.
There are several steps for a withdrawal to be made:
Get the corresponding deposit.
Check the amount and validate if it is possible to pay.
Call the order bookkeeper to liquidate the participation.
Check the authz grant to be available for the message creator and depositor address in the ticket.
Update authz withdrawal limit or delete if is zero.
Set the withdrawal in the state.
Modify and set the deposit and put the withdrawal info.
Argument | Description | Type | Validation | Example |
---|---|---|---|---|
Params | Description | Type | Validation | Example |
---|---|---|---|---|
Params | Description | Type | Validation | Example |
---|
Params | Description | Type | Validation | Example |
---|
Params | Description | Type | Validation | Example |
---|
Argument | Description | Type | Validation | Example |
---|
Argument | Description | Type | Validation | Example |
---|
uid
Unique Identifier of a the bet
string
Required
Valid UUID
0435e5b6-635f-11ed-90a6-bb470175dfce
amount
It is the total wager amount (contains bet fee also)
Integer
Positive
Should be greater than the minimum bet amount for the market
100000000
ticket
Used for market verification.
String (JWT token)
Cannot be empty
Cannot contain space (More validations will be added in the future)
1eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1aWQiOiI5OTkxYzYwZi0yMDI1LTQ4Y2UtYWU3OS0xZGMxMTBmMTY5OTkiLCJ4aWQiOiJCZXRPZGQiLCJuYW1lIjoiMSIsImJldF9ldmVudF91aWQiOiI1NTMxYzYwZi0yMDI1
selected_odds
The selected odds for the bet
Odds Value will be validated according to the OddsType selected in the bet placement message. there are three types of validation according to the Decimal, Fractional and Moenyline odds
{ "uid": "9991c60f-2025-48ce-ae79-1dc110f16990", "market_uid": "5531c60f-2025-48ce-ae79-1dc110f16007", "value": "2.0"}
uid
Unique identifier of the odds on which the bet should be placed
Cannot be empty
Cannot contain space
Should be a proper UUID (https://www.uuidtools.com/decode)
"uid": "2231c60f-2025-48ce-ae79-1dc110f16444"
value
Value of the odd selected by the bettor
sdk.Dec
Cannot be <= 1
"value": "5.0"
market_uid
Unique identifier of the market on which the bet should be placed
Cannot be empty
Cannot contain space
Should be a proper UUID (https://www.uuidtools.com/decode)
"market_uid": "5531c60f-2025-48ce-ae79-1dc110f16001
kyc_data
Data related to the user kyc
KycData
{ "ignore": true, "approved": true, "id": "userID" }
kyc_ignore
If indend to disable the KYC validation should be set as true
boolean
false
kyc_approved
Tells whether KYC is approved for the user or not
boolean
true
kyc_id
Account address of the user
string
A valid address
sge1na4f4c8m9hzlxqttl4jfnnyhsd94hsg9ykqxez
max_loss_multiplier
A coefficient for maximum loss prevention
string
should be less than one
0.5
odds_type
Type of the odds
uint32
1
iat
Epoch timestamp for issuance of the ticket by oracle in seconds
int64
1657270827
exp
Ticket-expiration epoch timestamp in seconds
int64
1657270827
iss
Issuer of the ticket
string
“Oracle”
sub
Subject of the payload or mostly the name of the transaction
string
“Place Bet”
account | depositor account address | string |
| sge1059gavv45jdp0l7c4kkskr0jae02j9cxmjr3f3 |
account | depositor account address | string |
| sge1059gavv45jdp0l7c4kkskr0jae02j9cxmjr3f3 |
depositor-addr | creator account address | string |
| sge1059gavv45jdp0l7c4kkskr0jae02j9cxmjr3f3 |
market_uid | UUID of the merket | string |
| 8483cc8a-d4c8-44ef-9f06-971ec7afe059 |
participation_index | participation index of the orderbook participation | uint64 |
| 1 |
id | sequential id of the withdrawal | uint64 |
| 1 |
market_uid | Unique Identifier of a market | string |
| 0435e5b6-635f-11ed-90a6-bb470175dfce |
amount | is the deposit amount (contains bet fee also) | Integer |
| 100000000 |
ticket | ticket data of deposit | string |
|
market_uid | Unique Identifier of a market | string |
| 0435e5b6-635f-11ed-90a6-bb470175dfce |
participation_index | The index of the participation when creating deposit | uint64 |
| 10 |
ticket | Ticket data of the withdraw | string |
|
mode | Mode of the withdrawal (full or partial) | uint32 |
| 1 |
amount | is the deposit amount (contains bet fee also) | Integer |
| 100000000 |
Overview and Concepts
The Market module serves the following purposes in the SGE Network chain:
The market module pushes the verified data of the sports events onto the SGE Network chain from off-chain sources. This way the sport-event is added to the blockchain and becomes readily available for the bettors to wager on it.
It stores the markets pushed to the blockchain.
It also resolves the markets when the market is finished and the winner odds are passed to it, hence declaring the result of the market.
It can update the markets as and when the update request is made.
It can activate or deactivate the markets, thus making them available or unavailable, respectively, for placing bets.
Market module parameter types and definition.
The Market module do not have any parameters.
Market module CLI.
This section specifies the queries, transactions, and required payloads. By following this section, one can get a deep understanding of the functioning of the house
module in the SGE Network chain.
This section defines the way in which the state of the Market is being stored in the chain.
A market is an entity being stored in the SGE Network chain to hold the data related to a market that has been verifiably pushed to the blockchain. It contains the following fields:
uid
: It is the unique identifier of a market.
start_ts
: It is the timestamp when a particular market will start.
end_ts
: It is the timestamp when a particular market will end.
odds
: It is a list of all the odds for a particular market. the meta
is a human-readable description of the odds, it can be a JSON string to be used by oracle services.
Ex: { "uid" :uid_win_event, "meta": "tam A wins" }, { "uid": uid_draw_event, "meta": "draw"}, { "uid": uid_loose_event, "meta": "team A loose"}
winner_odds_uids
: It is a list of all the UIDs of odds that have won the market. This should necessarily be a subset of the above-provided odds_uids.
status
: It defines the current state of the market.
resolution_ts
: It is the timestamp when the market came to a resolution i.e. when the system received a resolution request for a market.
creator
: It holds the account address responsible for the addition of the market to the blockchain.
meta
: It is a human-readable description of the market, it can be a JSON string to be used by oracle services.
book_id
is the ID of the order book created and assigned to the market, this is the same value as market UID.
The proto for the market is as follows:
The status of a market in the chain can be defined in either of the five following ways:
The exposed transactions CLI commands and ticket payloads by the Market module.
The below transaction can be used to add a market to the blockchain.
The payload for the add-market transaction is as follows:
The values in the payload should be changed according to the data.
The below transaction can be used to update a market stored in the blockchain.
The payload for the update-market transaction is as follows:
The values in the payload should be changed according to the data.
The below transaction can be used to resolve a market to the blockchain.
The payload for the resolve-market transaction is as follows:
The values in the payload should be changed according to the data.
The below transaction can be used to update a market to the blockchain.
The payload for the update-market transaction is as follows:
The values in the payload should be changed according to the data.
This section elaborates on the transaction message handler methods being exposed by the Market module.
When a transaction of adding a market is processed, the following actions take place:
The creator address and the ticket format are validated in the market module.
The OVM module is invoked to retrieve the ticket's contents and validate it.
If the ticket is valid, it is checked if the market already exists.
If the market does not already exist, a new market is created with the provided data and added to the market module's KVStore. The market is created as shown below:
The RPC for adding a market is as follows:
The request message for Add
is MsgAdd
. The proto for the request message is as follows:
The response message of the MsgAdd
is MsgAddResponse
. The proto for the response message is as follows:
When a transaction of resolving a market is processed, the following actions take place:
The creator address and the ticket format are validated in the market module.
The OVM module is invoked to retrieve the ticket's contents and validate it.
If the ticket is valid, it is checked if the market already exists.
If the market already exists, the market status should,types.MarketStatus_STATUS_ACTIVE
so that the market can be resolved now.
Then the market is resolved as per the provided odds value and status and stored in the KVStore of the market module.
The RPC for resolving a market is as follows:
The request message for Resolve
is MsgResolve
. The proto for the request message is as follows:
The response message of the MsgResolve
is MsgResolveResponse
. The proto for the response message is as follows:
When a transaction of updating a market is processed, the following actions take place:
The creator address and the ticket format are validated in the market module.
The OVM module is invoked to retrieve the ticket's contents and validate it.
If the ticket is valid, it is checked if the market already exists.
If the market already exists, the market status should be types.MarketStatus_STATUS_Active
or types.MarketStatus_STATUS_Inactive
Then the market is updated as per the provided data and stored in the KVStore of the market module again in the following way:
The RPC for updating a market is as follows:
The request message for Update
is MsgUpdate
. The proto for the request message is as follows:
The response message of the Update
is MsgUpdateResponse
. The proto for the response message is as follows:
The mint module is responsible for calculating and minting SGE tokens that will be distributed among validators as block rewards. The SGE mint module implements the concept of phases which defines the inflation curve of the SGE Network chain over its lifetime. Refer to the Token Economics section to know more about the inflation curve.
The Mint module is responsible for minting tokens to reward validators and delegators for helping secure the chain. The Mint module is responsible for the inflation in the chain.
Unlike the default Mint Module of the Cosmos, which can vary the inflation rate dynamically based on the ratio of the bonded and the unbonded tokens at any point in time, the Mint module of the SGE Network chain follows a strict regime of inflation rates defined by the phases.
Phases are nothing but specific discreet time frames during which a certain inflation rate holds for the chain. Phases have two components:
duration
: The duration is defined as the year_coefficient. It defines the time in years for which a phase will hold. For example, a year_coefficient of 0.75 means that the phase will last for 9 months, that is, 3/4th of a year.
inflation
: This parameter defines the inflation rate of the chain for the phase in question. Inflation is defined as a decimal. That is inflation of 0.10000 means an inflation rate of 10%.
The duration and inflation rate of phases can be modified via governance. For more details about phases, visit phases.
If all the specified phases are over, the chain enters a special phase called the
final_phase
, where the phase duration is infinite and the phase inflation is zero. Note that the inflation rate does not depend on the number of bonded and unbonded tokens
Market module CLI queries
Queries of this module can be used to get the data of markets and params. The following queries have been exposed by the market module:
Gets a single UID and returns the corresponding market, the following table explains the details of the argument required for the above query:
Gets a list of comma-separated UID and returns the list of markets. The below table explains the details of the argument required for the above query:
Params | Description | Type | Validation | Example |
---|---|---|---|---|
Params | Description | Type | Validation | Example |
---|---|---|---|---|
uid
Unique Identifier of a market
string
Required
Valid UUID
0435e5b6-635f-11ed-90a6-bb470175dfce
uid
A list of unique identifiers of markets separated by ,
string
Required
Valid UUID
0435e5b6-635f-11ed-90a6-bb470175dfce
The Minter message is used to store the data of the current inflation in the blockchain. The Minter entity consists of the following fields:
inflation
: current inflation rate of the chain.
phase_step
: Phase of inflation that the chain is working with.
phase_provisions
: Expected provisions of the current phase.
truncated_tokens
: Holds the truncated value of the mint calculations of the phases.
The proto for the Order Book messages is as follows:
The Phase message is used to store the data of a particular phase in the parameters in the blockchain. The Phase entity consists of the following fields:
inflation
: The inflation rate of the phase.
year_ocefficient
: The coefficient of a year (ex. 0.75 == 9 months).
Bet module parameter types and definition.
The Mint module employs two types of parameters-
Genesis parameters
Minter parameters
These parameters determine the inflation curve of the SGE Network chain over the lifetime of the chain. These parameters define the basic configuration of the chain. These parameters can be modified only via governance.
blocks_per_year
: This parameter determines the average number of blocks that will be generated over a year. In the above example, every 51840 block will be considered as 1 year.
mint_denom
: This value represents the coin denomination of the minted coins
phases
: This is an array of phase durations and their corresponding inflation rates. A detailed explanation of the Phases can be found in the concepts section.
exclude_amount
: By default, inflation is calculated over the total supply of coins. This parameter is used to exclude some amount of tokens before calculating the inflation amount. This is in accordance with Token Economics.
Minter is an entity that holds the fields required for the functioning of the minting mechanism. These parameters are used to store the current state of the minter. The minter parameters are automatically calculated during the operation of the chain. These can't be influenced directly via governance.
phase_provision
: This value calculates how many tokens are to be minted in the current phase. The value is recalculated at the end of every phase.
inflation
: This parameter defines the inflation rate for the current phase.
phase_step
: This parameter determines which phase the minter is in currently.
truncated_tokens
: The block provision equals the current annual provision divided by the number of blocks per year, the result needs to be converted to sdk.Int
as it is used in the MintCoins method of the bank module of blockchain. So the decimal part of the value will be truncated from the actual value, so we store truncated values in the minter and add this value to the annual provision in the next block.
This section specifies the queries, transactions, and required payloads. By following this section, one can get a deep understanding of the functioning of the mint
module in the SGE Network chain.
Adding automatic execution of certain logic at the beginning of each block is being done in the Mint Module. The section elaborates on all the begin-blocker executions in the Mint module. Minting parameters are recalculated and inflation is paid at the beginning of each block.
Checking if the chain has moved from one phase to another, including the final phase, and re-setting the minter in case the phase has changed, is a begin-blocker operation implemented in the Mint module. It is implemented as follows:
If the phase has changed, set the minter with the changed parameters:
Since the SGE Network chain is predominantly reliant on phases for its inflation model, the phase_provision keeps track of the total amount of tokens to be distributed in the current phase. This value is calculated every time there is a phase change.
Calculate the provisions generated for each block based on the current phase provisions. The provisions are then minted by the mint module's ModuleMinterAccount and then transferred to the auth's FeeCollector ModuleAccount.
The Order Book is a module for the order book and fund management over module accounts and actors.
Defines the way in which the state of the Order book is being stored in the chain.
The OrderBook message is used to store the data of a particular order book in the blockchain. The OrderBook entity consists of the following fields:
uid
: The UID of the order book.
participation_count
: The count of participation in this book.
odds_count
: Count of odds registered in the market related to this book.
status
: the status of the book.
The proto for the Order Book messages is as follows:
The BookParticipation message is used to store the data of a particular participation in the OrderBook in the blockchain. The BookParticipation entity consists of the following fields:
index
: The sequential index of participation in a book.
order_book_uid
: The uinque identifier of the OrderBook.
participant_address
: The account address of the participant.
liquidity
: The amount of participation minus fees.
current_round_liquidity
: Participations are calculated in multiple rounds depending on the payout amount.
exposures_not_filled
: The count of exposures that are not filled till now.
total_bet_amount
: Total value of bet amount that is calculated from the payout.
current_round_total_bet_amount
: Total value of bet amount in the current round calculations.
max_loss
: Maximum possible loss of participation.
current_round_max_loss_odds_uid
: UID list of odds with maximum calculated loss.
actual_profit
: The pure profit that goes to the participant account balance.
is_settled
: Show whether the participation is settled or not.
The proto for the Order Book messages is as follows:
The ParticipationBetPair message is used to store the data of a particular participation and bet in the OrderBook in the blockchain. The ParticipationBetPair entity consists of the following fields:
order_book_uid
: The uinque identifier of the OrderBook.
participant_index
: The index of participation in a book.
bet_uid
: True unique identifier of bet that payout was done from participation.
The BookOddsExposure message is used to store the data of a particular exposure of odds in the OrderBook in the blockchain. The BookOddsExposure entity consists of the following fields:
order_book_uid
: The uinque identifier of the OrderBook.
odds_uid
: The unique identifier of the odds.
fulfillment_queue
: The queue of bet fulfillment for the odds exposure.
The ParticipationExposure message is used to store the data of a particular exposure of participation in the OrderBook in the blockchain. The ParticipationExposure entity consists of the following fields:
order_book_uid
: The uinque identifier of the OrderBook.
odds_uid
: The unique identifier of the Odds.
participation_index
: The index of participation in the Order book.
exposure
: The exposure is the payout that should be done.
bet_amount
: The calculated bet amount of the expected payout.
is_fulfilled
: Fulfillment status of the exposure.
round
: Current round of calculation of exposures.
The OrderBookStats message is used to store the statistics data of Order Books in the blockchain. The OrderBookStats entity consists of the following fields:
resolved_unsettled
: The list of resolved markets that have unsettled bets.
Purpose
The purpose of this lock is to maintain idempotency in the system. The payout lock checks for idempotency whenever an exported keeper function of the module is invoked by any other module. It follows the following conditions:
While wagering
If a payout lock (or bet UID) exists in the store, then the wager request is rejected, inferring that the bet has already been placed in the blockchain with the same bet UID.
If the payout lock does not exist, then the wager request is accepted and a payout lock with the bet UID of the bet is stored in the blockchain.
While bet settlement
If the payout lock does not exist in the store, then the bet settlement request is rejected.
If the payout lock exists, then the bet settlement request is accepted, the settlement is processed, and the payout is deleted from the store.
Order book module, module accounts definition.
The Order Book module has one module account which is as follows:
Book Liquidity Account
Name: orderbook_liquidity_pool
This account holds the liquidity of the books and bets amount and payout of all accounts.
Order Book module CLI.
This section specifies the queries, transactions, and required payloads. By following this section, one can get a deep understanding of the functioning of the orderbook
module in the SGE Network chain.
The below table explains the details of the argument required for the above query:
The below table explains the details of the argument required for the above query:
The below table explains the details of the argument required for the above query:
The below table explains the details of the argument required for the above query:
The below table explains the details of the argument required for the above query:
The below table explains the details of the argument required for the above query:
The Order Book module has the following parameters:
Max order book participation: maximum allowed participation count of an order book.
Batch Settlement Count: Automatic batch settlement count in each block.
Requeue Threshold: This is a defined value for resetting the fulfillment queue if liquidity is less than this value.
The proto for the params are as follows:
Params | Description | Type | Validation | Example |
---|---|---|---|---|
Params | Description | Type | Validation | Example |
---|---|---|---|---|
Params | Description | Type | Validation | Example |
---|---|---|---|---|
Params | Description | Type | Validation | Example |
---|---|---|---|---|
Params | Description | Type | Validation | Example |
---|---|---|---|---|
Params | Description | Type | Validation | Example |
---|---|---|---|---|
order-book-id
uuid of the order book
string
Required
Valid UUID
0435e5b6-635f-11ed-90a6-bb470175dfce
order-book-id
uuid of the order book
string
Required
Valid UUID
0435e5b6-635f-11ed-90a6-bb470175dfce
order-book-id
uuid of the order book
string
Required
Valid UUID
0435e5b6-635f-11ed-90a6-bb470175dfce
participation-index
index of the participation
uint64
Required
Positive Number
1
order-book-id
uuid of the order book
string
Required
Valid UUID
0435e5b6-635f-11ed-90a6-bb470175dfce
order-book-id
uuid of the order book
string
Required
Valid UUID
0435e5b6-635f-11ed-90a6-bb470175dfce
odds-uid
uuid of the odds
string
Required
Valid UUID
0435e5b6-635f-11ed-90a6-bb470175dfce
order-book-id
uuid of the order book
string
Required
Valid UUID
0435e5b6-635f-11ed-90a6-bb470175dfce
The main logic of the Order Book module definitions and methods.
There are several steps for a deposit to be made:
Create an Order Book for the market.
For each odds UID of the market, Set exposures for the order book in the state
Set order book in the state.
There are several steps for a deposit to be made:
Get the market and order book and validate if it is allowed to add more participation.
Transfer the fee to the house fee collector module account.
Transfer liquidity to the order book liquidity pool module account.
Set participation for the order book in the state.
For each odds exposure of the order book:
Append the index to the fulfillment queue of the order book odds exposure item.
Set the order book odds exposures in the state.
Set participation exposure in the state.
Set the order book in the state.
There are several steps for a deposit to be made:
Get order book participation and validate it.
Calculate the maximum amount that can be transferred:
According to the withdrawal mode, transfer the requested amount from the liquidity module.
Set participation currentRoundLiquidity
and liquidity
in the state.
For each odds exposure, set the fulfillment queue item at the start of the queue and set it in the state.
There are several steps for a deposit to be made:
Get the OrderBook, Participations, Odds Exposures, and Particpation Exposures.
Refine book exposures fulfillment queue one by one:
Get queue item participation.
Calculate available liquidity by multiplying the maxLossMultiplier of the selected odds by the current round liquidity amount minus participation exposure.
If there is no available liquidity:
Set the participation exposure as fulfilled.
Remove queue item.
If the available liquidity is less than the payout that should be paid:
Fulfill the bet with available liquidity (all of the liquidity will be consumed).
Set the participation exposure as fulfilled.
Remove queue item.
There is more liquidity available than the payout that should be paid:
If the requeue threshold is not being met:
Set the participation exposure as fulfilled.
Remove queue item.
Fulfill the bet with the payout amount that should be paid.
Set Participations exposures in the state.
Set the updated fulfillment queue into the book exposure.
Transfer bet fee to bet fee collector module account.
Transfer the calculated fulfilled bet amount to the order book liquidity pool module account.
Origin Verification Module
The Origin Verification Mechanism (OVM) is used to verify the origin of any off-chain data when they are pushed into the chain. This module ensures that no corrupt or unauthenticated data can make its way into the chain.
OVM module CLI.
This section specifies the queries, transactions, and required payloads. By following this section, one can get a deep understanding of the functioning of the ovm
module in the SGE Network chain.
The OVM module has only one state table consisting of a list of strings that are the trusted public keys.
The Public Keys is an entity that stores the public keys of the registered oracles which can verifiably push data to the blockchain. It contains:
public_keys
: A list of allowed public keys.
The proto for the PublicKeys is as follows:
The public keys change proposal is store in the state to be used to change the compromised public keys.
The vote tracks the votes for the proposals.
The proposal statistics are stored to keep track of the count of proposals.
A subaccount is a unique account variant wherein the subaccount module regulates both its balance and permissions.
The SGE Network chain relies on external off-chain data of matches and other markets. To push this data reliably to the chain, some kind of origin verification is required. The OVM module essentially fills this role in the SGE Network chain. The OVM Module verifies the following data:
Event data pushed by the House to the chain.
Validity of Odds data during bet placement by the bettor.
To verify the origin of the data, a simple mechanism of signing and verification with a private key and the corresponding public key is performed.
Fast single-signature verification
Fast batch verification
Very fast signing Fast key generation
High-security level
Foolproof session keys
Collision resilience
No secret array indices
No secret branch conditions
Small signatures
Small keys
After generating the encrypted signed ticket
, this signature data is included in the transactions. This includes transactions for adding/editing betting markets on the chain, as well as verifying odds when the user places on these markets. All tickets come with an expiry timestamp which invalidates the ticket after a certain duration. This facility prevents the use or abuse of old and expired tickets.
The OVM Module
essentially stores a list of trusted public keys. These public keys are just the counterpart to the private keys that were used to sign and encrypt the tickets off-chain. When a transaction is made to the chain that necessitates verification of the origin of the data, the corresponding module invokes the OVM module for verification and decryption purpose. The OVM Module works as an interface, which can decode any signed data passed to it when supplied with the encryption algorithm and the decrypted type. This design completely nullifies the need to change the structure of the OVM if the ticket structure changes. This essentially enables the OVM to be a global verification module.
When the OVM is invoked, it first attempts to verify the signature of the data against the list of registered public keys. If the signature is verified successfully by the leader public key (the first element in the public keys slice in the key vault store), the OVM decrypts the data into the provided structure and returns it to the invoking module. In case the signature verification fails, or the ticket seems to have expired, or the decrypted structure does not match with the expected structure, the verification is considered to be a failure and a corresponding error is returned to the invoking module, which consequently results in failure of the transaction.
The OVM Leader is the public key that is being used for the verification of the tickets, The first element of the Key Vault public keys is the leader. If the private key of the leader's public key gets corrupt/hacked/leaked, The holders of the rest of the public keys can create a pub keys-change proposal to replace the leaked public key with a new one and choose the new leader key. Each proposal needs at least 3 "yes" or 2 "no" to make blockchain code to decide about the proposal's approval or rejection, the modification happens in the end blocker if the condition of votes is satisfied.
The exposed transactions CLI commands and ticket payloads by the OVM module.
The below transaction can be used to create a proposal for pubkey change on the blockchain.
The below table specifies the details of the arguments used in the above transaction:
The payload for the proposal transaction is as follows:
The below transaction can be used to create a proposal for pubkey change on the blockchain.
The below table specifies the details of the arguments used in the above transaction:
The payload for the vote transaction is as follows:
Params | Description | Type | Validation | Example |
---|
The data that needs to be pushed into the blockchain is first signed by the private key of a trusted source. This process occurs off-chain. Essentially, we create an encrypted ticket with the trusted private key. The curve used for signing and verification of the ticket is the. This algorithm has been chosen for the following benefits:
Details of the algorithm can be found .
Argument | Description | Type | Validation | Example |
---|
Argument | Description | Type | Validation | Example |
---|
status | Active or finished proposals | uint32 |
| 1: Active 2: Finished |
ticket | Used for proposal verification. | String (JWT token) |
| 1eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1aWQiOiI5OTkxYzYwZi0yMDI1LTQ4Y2UtYWU3OS0xZGMxMTBmMTY5OTkiLCJ4aWQiOiJCZXRPZGQiLCJuYW1lIjoiMSIsImJldF9ldmVudF91aWQiOiI1NTMxYzYwZi0y MDI1 |
ticket | Used for proposal verification. | String (JWT token) |
| 1eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1aWQiOiI5OTkxYzYwZi0yMDI1LTQ4Y2UtYWU3OS0xZGMxMTBmMTY5OTkiLCJ4aWQiOiJCZXRPZGQiLCJuYW1lIjoiMSIsImJldF9ldmVudF91aWQiOiI1NTMxYzYwZi0yMDI1 |
pubkeyIndex | The registered pubkey index that you are voting on behalf | uint32 |
| 1 |
Subaccount module parameter types and definition.
The House module has the following parameters:
Wager Enabled: Determines if the wagering by subaccount is active or not.
Deposit Enabled: Determines if the deposit (be the house) by subaccount is active or not.
The proto for the params is as follows:
Defines the way in which the state of the Subaccount is being stored in the chain.
The Create and TopUp messages are used to store the data of a particular subaccount's locked balance in the blockchain. The AccountSummary
entity consists of the following fields:
deposited_amount
: The total amount that has been transferred to a subaccount so far.
spent_amount
: The spent amount that has been used for wager and deposit.
withdrawn_amount
: The amount that has been withdrawn from the subaccount's unlocked/locked balance.
lost_amount
: The amount that has been lost in wager and deposit.
The proto for the Deposit messages is as follows:
The Create and TopUp messages are used to store the data of a particular subaccount's locked balance in the blockchain. The LockedBalance
entity consists of the following fields:
amount
: The amount of locked balance.
unlock_ts
: The time when the amount would be unlocked.
The proto for the locked balance is as follows:
The main logic of the House module definitions and methods.
There are several steps for subaccount create to be made:
Check for existing subaccount.
Generate a new ID.
Create a new account extracted from the generated ID.
Set the new account into the account keeper.
Store the owner, locked balances, and account summary in the state.
There are several steps for a subaccount top-up to be made:
Get account summary and locked balances from the state.
Update the account Summary and locked balances.
Send tokens from the transaction signer to the subaccount balance in the bank module.
There are several steps for a subaccount withdrawal to be made:
Get the account summary from the state.
Calculate the withdrawable balance according to the unlock timestamps and spend and lost amounts.
Update the account summary withdrawn amount.
Send tokens from the subaccount to the owner's balance.
There are several steps for a wager by a subaccount to be made:
Check the existence of the subaccount for the bettor.
Verify the ticket and unmarshal the payload and validate.
Use bet module's methods to prepare a bet object.
Withdraw the needed amount first from the unlocked, then the locked if there is not enough unlocked balance.
Use bet module to place the bet for the owner's account.
The SGE-Network node application introduces a distinctive account type called
subaccount
and its balance is managed by this module. The subaccount balance is intended for use in betting and engaging in the "be the house" feature to participate in the markets as a house.
The subaccount balance is established with an unlocking period, following which the balance can be withdrawn to the owner's main balance.
Owners have the option to create the Subaccount themselves, or it can be generated by the rewards module.
This section elaborates on the transaction message handler methods being exposed by the House module.
When a create transaction is processed, the following things happen:
Validate the incoming create message.
Call the Create
method of the keeper.
The RPC for creating a subaccount is as follows:
The request message for Create
is MsgCreate
. The proto for the request message is as follows:
The response message for Deposit
is MsgDepositResponse
. The proto for the request message is as follows:
When a top-up transaction is processed, the following things happen:
Validate the incoming create message.
Call the TopUp
method of the keeper.
The RPC for a top-up of the subaccount is as follows:
The request message for TopUp
is MsgTopUp
. The proto for the request message is as follows:
The response message for TopUp
is MsgTopUpResponse
. The proto for the request message is as follows:
When a top-up transaction is processed, the following things happen:
Validate the incoming create message.
Call the WihtdrawUnlocked
method of the keeper.
The RPC for a top-up of the subaccount is as follows:
The request message for WihtdrawUnlockedBalances
is MsgWihtdrawUnlockedBalances
. The proto for the request message is as follows:
The response message for WihtdrawUnlockedBalances
is MsgWihtdrawUnlockedBalancesResponse
. The proto for the request message is as follows:
When a wager transaction is processed, the following things happen:
Validate the incoming create message.
Call the Wager
method of the keeper.
The RPC for a wager of the subaccount is as follows:
The request message for Wager
is MsgWager
. The proto for the request message is as follows:
The response message for Wager
is MsgWagerResponse
. The proto for the request message is as follows:
Subaccount module CLI.
This section specifies the queries, transactions, and required payloads. By following this section, one can get a deep understanding of the functioning of the subaccount
module in the SGE Network chain.
The responsibility for overseeing and validating campaigns and reward allocations lies with the reward module.
The below transaction can be used to create a subaccount on the blockchain.
The below table specifies the details of the arguments used in the above transaction:
The below transaction can be used to top up a subaccount on the blockchain.
The below table specifies the details of the arguments used in the above transaction:
The below transaction can be used to withdraw a subaccount unlocked balance.
The below table specifies the details of the arguments used in the above transaction:
The below transaction can be used to wager using the subaccount and owner account balance.
The below table specifies the details of the arguments used in the above transaction:
Params | Description | Type | Validation | Example |
---|---|---|---|---|
Argument | Description | Type | Validation | Example |
---|
Argument | Description | Type | Validation | Example |
---|
Argument | Description | Type | Validation | Example |
---|
Argument | Description | Type | Validation | Example |
---|
owner_address
owner account address
string
Required
Valid Address
sge1059gavv45jdp0l7c4kkskr0jae02j9cxmjr3f3
owner account address | the address of the owner of the subaccount | string |
| sge1059gavv45jdp0l7c4kkskr0jae02j9cxmjr3f3 |
funds | the initial fund of the subaccount | uint64 |
| 100000 |
duration | lock duration of the balance | duration |
| 8760h |
owner account address | the address of the owner of the subaccount | string |
| sge1059gavv45jdp0l7c4kkskr0jae02j9cxmjr3f3 |
funds | the initial fund of the subaccount | uint64 |
| 100000 |
duration | lock duration of the balance | duration |
| 8760h |
owner account address | the address of the owner of the subaccount | string |
| sge1059gavv45jdp0l7c4kkskr0jae02j9cxmjr3f3 |
ticket | the ticket data | string |
|
This section elaborates on the transaction message handler methods being exposed by the House module.
When a create transaction is processed, the following things happen:
Validate the incoming create message.
Call the CreateCampaign
method of the keeper.
The RPC for creating a campaign is as follows:
The request message for CreateCampaign
is MsgCreateCampaign
. The proto for the request message is as follows:
The response message for CreateCampaign
is MsgCreateCampaignResponse
. The proto for the request message is as follows:
When a create transaction is processed, the following things happen:
Validate the incoming create message.
Call the UpdateCampaign
method of the keeper.
The RPC for updating a campaign is as follows:
The request message for UpdateCampaign
is MsgUpdateCampaign
. The proto for the request message is as follows:
The response message for UpdateCampaign
is MsgUpdateCampaignResponse
. The proto for the request message is as follows:
When a withdrawal funds transaction is processed, the following things happen:
Validate the incoming create message.
Call the WithdrawFunds
method of the keeper.
The RPC for a withdraw funds of a campaign is as follows:
The request message for WithdrawFunds
is MsgWithdrawFunds
. The proto for the request message is as follows:
The response message for TopUp
is MsgWithdrawFundsResponse
. The proto for the request message is as follows:
When a grant reward transaction is processed, the following things happen:
Validate the incoming create message.
Call the GrantReward
method of the keeper.
The RPC for a grant reward of the reward module is as follows:
The request message for GrantReward
is MsgGrantReward
. The proto for the request message is as follows:
The response message for GrantReward
is MsgGrantRewardResponse
. The proto for the request message is as follows:
The SGE-Network provides functionality for creating and configuring reward campaigns, allowing users to define specific rewards. Subsequently, the system facilitates the granting of these defined rewards as part of its exposed features.
Users have the flexibility to define and configure limitless campaigns in alignment with their marketing objectives. These campaigns can be equipped with specified start and end times, along with predetermined reward amounts to create diverse promotional needs.
Diverse categories, such as Signup and Referral, offer users the option to define campaigns with distinct types like Signup Bonus, Referral Signup, and Referral Reward. The blockchain system undertakes the validation and computation of rewards, ensuring that the allowed grant amount aligns with the specific configurations set for each corresponding campaign.
Subaccount module parameter types and definition.
The Reward module does not have defined parameters at the moment.
The main logic of the House module definitions and methods.
There are several steps for the campaign to be created:
Check for existing campaign with the same identifier.
Check authorization if the creator and promoter are not the same.
Validate the ticket payload according to the defined reward type and category.
Transfer the pool amount to the pool module account.
Store the campaign data in the state.
There are several steps for updating a campaign:
Get current campaign configurations from the state.
Validate the payload of the campaign update.
Check the Authorization if the creator and the campaign promoter are not the same.
Calculate the top-up amount of the campaign pool.
Update the end timestamp of the campaign.
Update the active or inactive status of the campaign.
There are several steps for a campaign funds withdrawal to be made:
Get the campaign from the blockchain state.
Validate authorization if the promoter and the creator are not the same.
Calculate the available amount that can be withdrawn from the campaign pool.
Transfer the withdrawable amount from the pool module account to the promoter.
Update the campaign balance and set in the state of the blockchain.
There are several steps for a reward to be granted:
Check for existing rewards with the identifier.
Retrieve the campaign information from the blockchain state.
Check the campaign validity period according to the current block time.
Calculate the reward amount according to the campaign reward type and category.
Check the claims per category for the reward.
Check the campaign pool balance to have enough funds.
Distribute the reward to the corresponding receiver account's subaccount.
Update the campaign's pool spent amount.
Store the reward, reward by campaign and reward by category into the blockchain state.
Defines the way in which the state of the Subaccount is being stored in the chain.
The Create Campaign message is used to store the data of a particular campaign alongside its configurations in the blockchain. The Campaign
entity consists of the following fields:
creator
: The creator's address of the campaign.
uid
: The universal unique identifier of the campaign.
promoter
: The address of the promoter account address, the pool balance will be deducted from this account balance.
start_ts
: The start time of the campaign.
end_ts
: The end time of the campaign.
reward_category
: The category of the campaign (Signup, Referral, ...).
reward_type
: The reward type of the campaign (Signup Bonus, Referral Signup, Referral, ...).
reward_amount_type
: The type of reward amount calculations (Calculated, Fixed, ...).
reward_amount
: The deduction amount from the subaccount and owner's account balance.
pool
: The spend and total amount of the campaign pool.
is_active
: Active or inactive status of the campaign.
claims_per_category
: The maximum allowed reward grant for the specific category.
meta
: The metadata, can be used for storing any useful info similar to the memo.
The proto for the Deposit messages is as follows:
The Grant message is used to store the data of a particular granted reward in the blockchain. The Reward
entity consists of the following fields:
uid
: The universal unique identifier of the reward.
creator
: The address of the reward creator account.
receiver
: The address of the reward receiver (grantee) account.
campaign_uid
: The Universal unique identifier of the corresponding campaign.
reward_amount
: The deducted amount from the subaccount and the owner account.
source_uid
: The unique identifier of the reward source (can be the address of the reward creator or granter).
meta
: The metadata, can be used for storing any useful info similar to the memo.
The proto for the locked balance is as follows:
The reward by category and reward by the campaign are stored for query, calculations, and validation purposes.
Reward module CLI queries.
The below table explains the details of the argument required for the above query:
The below table explains the details of the argument required for the above query:
The below table explains the details of the argument required for the above query:
The below table explains the details of the argument required for the above query:
The below table explains the details of the argument required for the above query:
The below transaction can be used to create a campaign on the blockchain.
The below table specifies the details of the arguments used in the above transaction:
The below transaction can be used to update a campaign on the blockchain.
The below table specifies the details of the arguments used in the above transaction:
The below transaction can be used to withdraw available funds from a campaign pool on the blockchain.
The below table specifies the details of the arguments used in the above transaction:
The below transaction can be used to grant a reward of a certain campaign to a reward receiver address on the blockchain.
The below table specifies the details of the arguments used in the above transaction:
Params | Description | Type | Validation | Example |
---|
Params | Description | Type | Validation | Example |
---|
Params | Description | Type | Validation | Example |
---|
Params | Description | Type | Validation | Example |
---|
Params | Description | Type | Validation | Example |
---|
Argument | Description | Type | Validation | Example |
---|
Argument | Description | Type | Validation | Example |
---|
Argument | Description | Type | Validation | Example |
---|
Argument | Description | Type | Validation | Example |
---|
uid | uid of the campaign | string |
| 8483cc8a-d4c8-44ef-9f06-971ec7afe059 |
uid | uid of the campaign | string |
| 8483cc8a-d4c8-44ef-9f06-971ec7afe059 |
address | address of the receiver | string |
| sge1059gavv45jdp0l7c4kkskr0jae02j9cxmjr3f3 |
address | address of the reward receiver | string |
| sge1059gavv45jdp0l7c4kkskr0jae02j9cxmjr3f3 |
category | category of the reward | int32 |
| 1 |
campaign | uid of the campaign | string |
| 8483cc8a-d4c8-44ef-9f06-971ec7afe059 |
uid | uid of the camoaign | string |
| 8483cc8a-d4c8-44ef-9f06-971ec7afe059 |
totalfunds | total funds of the campaign pool | uint64 |
| 100000 |
ticket | ticked payload for the campaign create | string |
|
uid | unique identifier of the campaign | string |
| 8483cc8a-d4c8-44ef-9f06-971ec7afe059 |
topup funds | the funds to be topped up to the campaign pool | uint64 |
| 100000 |
ticket | ticked payload for the campaign update | string |
|
uid | unique identifier of the campaign | string |
| 8483cc8a-d4c8-44ef-9f06-971ec7afe059 |
ticket | ticked payload for the campaign funds withdrawal | string |
|
uid | unique identifier of the reward | string |
| 8483cc8a-d4c8-44ef-9f06-971ec7afe059 |
campaign_uid | uid of the corresponding campaign | string |
| 8483cc8a-d4c8-44ef-9f06-971ec7afe059 |
ticket | ticked payload for the grant reward | string |
|
Payload: The payload for placing a bet is as follows:
Please ensure to change the kyc_id
with your bettor address, and update the timestamps. A JWT ticket should be created out of this payload for providing it in the transaction below.
Transaction: The transaction for placing a bet is as follows:
sged tx bet place-bet [uid] [amount] [ticket] --chain-id [chain-id] --from [signer-account-key]
Example:
sged tx bet place-bet 6631c60f-2025-48ce-ae79-1dc110f16123 1000000000 [ticket] --chain-id sge --from bettor
Verification: The above success or failure of the above transaction can be verified using the queries and the state table below.
Query the transaction hash:
sged q tx [tx-hash]
Expectation: Code is 0
Query the list of bets
saaged q bet bets
Expectation: One bet should be placed.
Query the balance of the bettor
saaged q bank balances sge1uffpdv3lg4v3gdwlt6pp0ty3fr7fyyau59hzmd
Payload: The payload for updating the above market is as follows: A JWT ticket should be created out of this payload for providing it in the transaction below. The timestamps need to be updated accordingly.
Transaction: The transaction for updating a market is as follows:
sged tx market update [ticket] --chain-id [chain-id] --from [signer-account-key]
Example:
sged tx market update [ticket] --chain-id sge --from oracle
Verification: The above success or failure of the above transaction can be verified using the query below.
Query the transaction hash:
sged q tx [tx-hash]
The bettor has been rewarded with the payout from the house.
Six Sigma Sports is a next generation sports betting platform designed to democratize the sports betting industry. It’s deployed on the Sports, Gaming and Entertainment Network (The SGE Network); a Cosmos SDK-based layer-1 blockchain that uses its own native utility token (The SGE Token). It is a new approach to sports betting, re-imagined with the benefit of blockchain technology to bring a transparent, fast, and uniquely engaging experience.
At Six Sigma Sports, for the first time ever, you can truly step into the shoes of the operator behind a sports book.
House module CLI.
This section specifies the queries, transactions, and required payloads. By following this section, one can get a deep understanding of the functioning of the reward
module in the SGE Network chain.
1. Introduction
The information in this Privacy Policy describes how we, SAAGE Labs Limited, a company registered in England (Company number 13783501) whose registered address is Cannon Place, 78 Cannon Place, London, United Kingdom, EC4N 6AF, use the personal data you provide us when you use the SIX SIGMA SPORTS application (“SIX SIGMA SPORTS”), any of the services provided by us which are accessible through SIX SIGMA SPORTS (“Services”), the website (https://sixsigmasports.io/#) or any other sites of ours (“Sites”) and through any communications with us in connection with SIX SIGMA SPORTS (“Communications”).
SIX SIGMA SPORTS, the Services and Sites are delivered to you in partnership with our online gaming licensor, SunSeven N.V. (a company incorporated under the laws of Curacao, company number 100554, and having its registered office at Heelsumstraat 51, E-Commerce Park, Curacao). When you engage with SunSeven N.V. in connection with the provision of SIX SIGMA SPORTS, the Services, and the Sites, SunSeven N.V. is acting as a processor on our behalf. When we refer to information collected by us throughout this policy, this includes information collected by SunSeven N.V. on our behalf and under our instructions.
We respect your privacy and protecting your information is paramount. We want you to be informed and empowered with respect to your privacy when you use SIX SIGMA SPORTS and the Services, Sites, and during any Communications with us, so please read this Privacy Policy carefully. This Privacy Policy sets out our practices regarding your personal data, how we collect, process, and treat it, and the rights you have in relation to the protection of your personal data.
2. Important information and who we are
SAAGE Labs Limited is the controller and is responsible for your personal data (collectively referred to as “we”, “us” or “our” in this policy).
We have appointed a data privacy manager. If you have any questions about this privacy policy, please contact them using the details set out below.
Contact details
Our full details are:
· Full name of legal entity: SAAGE Labs Limited
· Attention: Data Privacy Manager
· Email address: support@sixsigmasports.io
· Postal address: Cannon Place, 78 Cannon Place, London, United Kingdom, EC4N 6AF
3. Complaints
If you have a complaint relating to the processing of your personal data, please use the contact details above to contact us.
We would appreciate the opportunity to address any concerns or complaints you may have with respect to SIX SIGMA SPORTS, the Services, Sites and Communications and our data processing practices. However, you have the right to make a complaint at any time to the Supervisory Authority (that is, the regulator for data protection issues). In the UK, this is the Information Commissioner’s Office (ICO) (https://ico.org.uk/make-a-complaint/).
4. Your duty to inform us of changes
It is important that the personal data we hold about you is accurate and current. Please keep us informed if your personal data changes during our relationship with you.
5. The data we collect about you
We may collect, use, store and transfer different kinds of personal data about you as follows:
· Communications Data: details regarding the communications made between us.
· Identity Data: first name, last name, username, e-mail address or similar identifier, title, date of birth.
· Contact Data: address and email address.
· Financial Data: digital wallet address.
· Transaction Data: details about transactions to and from you.
· Device Data: IP Address.
· Usage Data: includes details of your use of SIX SIGMA SPORTS, the Services and Sites including, but not limited to, traffic data, and other communication data, whether this is required for our own purposes or otherwise and the resources that you access (including but not limited to the digital wallet(s) used).
· Marketing and Communications Data: includes your preferences in receiving marketing from us and your communication preferences.
· Location Data: Geo-Location IP.
We also collect, use and share Aggregated Data such as statistical or demographic data for any purpose. Aggregated Data could be derived from your personal data but is not considered personal data in law as this data will not directly or indirectly reveal your identity. However, if we combine or connect Aggregated Data with your personal data so that it can directly or indirectly identify you, we treat the combined data as personal data which will be used in accordance with this privacy policy.
We do not collect any Special Categories of Personal Data about you (this includes details about your race or ethnicity, religious or philosophical beliefs, sex life, sexual orientation, political opinions, trade union membership, information about your health, and genetic and biometric data). Nor do we collect any information about criminal convictions and offences.
6. How is your personal data collected?
We will collect and process the following data about you:
· Information you give us. This is information (including Identity, Contact and Marketing and Communications Data) you consent to giving us about you by filling in forms on SIX SIGMA SPORTS or on our Sites, or through Communications with us (for example, by email or chat). It includes information you provide when you register to use SIX SIGMA SPORTS or subscribe to any of our Services and when you report a problem with SIX SIGMA SPORTS or our Services or our Sites. If you contact us, we will keep a record of that correspondence.
· Information we collect about you and your device. Each time you visit one of our Sites or use SIX SIGMA SPORTS we will automatically collect personal data including device and usage Data. We collect this data using cookies and other similar technologies.
· Location Data. We also use geo-location IP to determine your current location. It is necessary for us to determine your location to provide you with access to and use of SIX SIGMA SPORTS and the Services in compliance with our legal and regulatory obligations. If you wish to register to use SIX SIGMA SPORTS and the Services, you will be asked to consent to your data being used for this purpose. You can withdraw your consent to your data being used for this purpose at any time by requesting the deletion of your SIX SIGMA SPORTS account.
· Information we receive from other sources including third parties and publicly available sources. We will receive personal data about you from various third parties and public sources as set out below:
o Device Data from the following parties:
§ analytics providers including but not limited to Meta, Google Analytics and other third party affiliate networks;
§ advertising networks including but not limited to Meta and Google; and
§ search information providers including but not limited to Google Index, Bing and Yahoo.
o Identity and Contact Data from data brokers, data aggregators or third party service providers.
7. How we use your personal data
We will only use your personal data when the law allows us to do so. Most commonly we will use your personal data in the following circumstances:
· Where you have consented before the processing.
· Where we need to perform a contract, we are about to enter or have entered with you.
· Where it is necessary for our legitimate interests (or those of a third party) and your interests and fundamental rights do not override those interests. When we rely on our legitimate interests, you have the right to object at any time. For example, we may process your personal data to:
o Keep our records up to date.
o Provide you with our Services, including for the purpose of quality control and analysis.
o Develop and improve our Services.
o Communicate and manage our relationship with you.
· Where we need to comply with a legal or regulatory obligation.
We will only send you direct marketing communications by email, Progressive Web App (PWA) notification or native in-app notification if we have your consent. You have the right to withdraw that consent at any time by contacting us.
We will get your express opt-in consent before we share your personal data with any third party for marketing purposes. We will never sell your personal data.
Purposes for which we will use your personal data
8. Disclosures of your personal data
We may need to disclose your personal data to others to facilitate the provision to you of SIX SIGMA SPORTS. Disclosure of your personal information to a third party will only be made where they agree to keep your information confidential and will only be used for the specific purpose for which we provide it to them. Your data may be disclosed to the other persons or entities as described below.
· Third parties who supply services to us, such as our online gaming licensor (SunSeven N.V., as referred to above) and our KYC service provider.
· Our professional advisors, such as our legal advisors where they require information in order to provide advice to us in relation to SIX SIGMA SPORTS, our Services, Sites or Communications.
· Any regulatory authority we may be subject to for the purpose of demonstrating compliance with applicable laws and regulations.
· Third parties to whom we may choose to sell, transfer or merge parts of our business or our assets. Alternatively, we may seek to acquire other businesses or merge with them. If a change happens to our business, then the new owners may use your personal data in the same way as set out in this privacy policy.
· Such third parties as we reasonably consider necessary in order to prevent crime, e.g., the police.
9. International transfers
Your personal data may be stored and processed outside the UK in countries that may have different data protection rules than our own. Whenever we transfer your personal data out of the UK, we ensure a similar degree of protection is afforded to it by ensuring appropriate safeguards have been put in place.
Please contact us if you want further information on the specific mechanism used by us when transferring your personal data out of the UK.
10. Data security
All information you provide to us is stored on our secure servers. Information we pass to third parties will be stored on their secure servers.
Once we have received your information, we will use strict procedures and security features to try to prevent your personal data from being accidentally lost, used, or accessed in an unauthorised way.
We have put in place procedures to deal with any suspected personal data breach and will notify you and any applicable regulator when we are legally required to do so.
11. Use of Cookies
SIX SIGMA SPORTS, the Services and our Sites use “cookies” and similar technologies to collect and store certain information. These typically involve pieces of information or code that a website transfers to or accesses from your computer hard drive or mobile device to store and sometimes track information about you. Depending on their purpose, the cookies may last only the length of a single browsing session, but in some cases, may last longer to ensure their purpose is fulfilled. Cookies help us recognise you as a unique visitor when you return to SIX SIGMA SPORTS and our Sites and help us to better understand how visitors use SIX SIGMA SPORTS and our Sites. This helps us to provide you with a good experience when you use SIX SIGMA SPORTS and our Sites and also allows us to improve SIX SIGMA SPORTS, our Sites and the Services. We will ask for your consent to place cookies or other similar technologies on your device, except where they are essential for us to provide you with a service that you have requested.
Broadly, SIX SIGMA SPORTS and our Sites use cookies and similar technologies for the following purposes:
· Strictly necessary cookies. These are cookies that are required for the operation of SIX SIGMA SPORTS, the Services and our Sites. They include, for example, cookies that enable you to log into secure areas of SIX SIGMA SPORTS and our Sites.
· Analytical cookies. These allow us to recognise and count the number of visitors and to see how visitors move around SIX SIGMA SPORTS and our Sites when they are using them. This helps us to improve the way SIX SIGMA SPORTS and our Sites work, for example, by ensuring that users are finding what they are looking for easily.
· Tracking cookies. These cookies record your visit to SIX SIGMA SPORTS and our Sites, the pages you have visited and the links you have followed. We will use this information to make SIX SIGMA SPORTS and our Sites, and the advertising displayed on them more relevant to your interests.
You can find more information about the individual cookies we use and the purposes for which we use them in the table below:
Please note that the following third parties may also use cookies when you access SIX SIGMA SPORTS, our Services or our Sites, over which we have no control. These named third parties may include, for example, advertising networks and providers of external services like web traffic analysis services. These third party cookies are likely to be analytical cookies or performance cookies or targeting cookies:
· Google Analytics
· Facebook Pixel
· Instagram Pixel
· Elfsight
· Youtube
You can choose whether to allow analytical and tracking cookies by clicking on the button(s):
· Analytical or Tracking cookies ON/OFF
However, if you use your browser settings to block all cookies (including essential cookies) you may not be able to access all or parts of SIX SIGMA SPORTS, our Sites or our Services.
12. Data retention
We will only keep your personal data for as long as necessary to carry out the relevant purposes set out in this Privacy Policy and in order to comply with our legal and regulatory obligations, following which we will securely destroy your personal information. We will provide you with more detail regarding the storage periods for the different types of personal data as and when you request.
In some circumstances you can ask us to delete your data: see Your legal rights below for further information.
In some circumstances we will anonymise your personal data (so that it can no longer be associated with you) for research or statistical purposes, in which case we may use this information indefinitely without further notice to you.
13. Your legal rights
We are committed to delivering the rights that data protection law provides. Please be aware that these rights are often not absolute, and exemptions may apply.
You have the right to:
· Be informed: and to be provided with clear, transparent and easily understandable information about how we use your information and your rights. This is why we are providing you with the information in this Privacy Policy.
· Request access to your personal data (commonly known as a “data subject access request”). This enables you to receive a copy of the personal data we hold about you and to check that we are lawfully processing it.
· Request correction of the personal data that we hold about you. This enables you to have any incomplete or inaccurate data we hold about you corrected, though we may need to verify the accuracy of the new data you provide to us.
· Request erasure of your personal data. This enables you to ask us to delete or remove personal data where there is no good reason for us continuing to process it. You also have the right to ask us to delete or remove your personal data where you have successfully exercised your right to object to processing (see below), where we may have processed your information unlawfully or where we are required to erase your personal data to comply with local law. Note, however, that we may not always be able to comply with your request of erasure for specific legal reasons which will be notified to you, if applicable, at the time of your request.
· Object to processing of your personal data where we are relying on a legitimate interest (or those of a third party) and there is something about your particular situation which makes you want to object to processing on this ground as you feel it impacts on your fundamental rights and freedoms. You also have the right to object where we are processing your personal data for direct marketing purposes. In some cases, we may demonstrate that we have compelling legitimate grounds to process your information which override your rights and freedoms.
· Request restriction of processing of your personal data. This enables you to ask us to suspend the processing of your personal data in the following scenarios:
o if you want us to establish the data’s accuracy;
o where our use of the data is unlawful, but you do not want us to erase it;
o where you need us to hold the data even if we no longer require it as you need it to establish, exercise or defend legal claims; or
o you have objected to our use of your data, but we need to verify whether we have overriding legitimate grounds to use it.
· Request the transfer of your personal data to you or to a third party. We will provide to you, or a third party you have chosen, your personal data in a structured, commonly used, machine-readable format. Note that this right only applies to automated information which you initially provided consent for us to use or where we used the information to perform a contract with you.
· Withdraw consent at any time where we are relying on consent to process your personal data. However, this will not affect the lawfulness of any processing carried out before you withdraw your consent. If you withdraw your consent, we may not be able to provide certain products or Services to you. We will advise you if this is the case at the time you withdraw your consent.
You can exercise any of these rights at any time by contacting us using the contact details set out at the top of this Privacy Policy.
14. How we Protect Your Information
We do our best to protect your personal data, but we cannot guarantee the security of your data transmitted; any transmission is at your own risk. Once we have received your information, we will use strict procedures and security features to try to prevent unauthorised access, loss, or damage.
15. Links to Third Party Websites
SIX SIGMA SPORTS may, from time to time, contain links to and from the websites of our partner networks, advertisers, and affiliates. If you follow a link to any of these websites, please note that these websites have their own privacy policies and that we do not accept any responsibility or liability for these policies.
16. Changes
We keep our privacy policy under regular review. This version was last updated on 1 December 2023.
We may make changes to this Privacy Policy in future to reflect changes in the functionality of SIX SIGMA SPORTS or otherwise changes in the way that we process your personal information. Any changes we may make to our SIX SIGMA SPORTS Privacy Policy will be posted [https://six-sigma-sports.gitbook.io/docs/privacy-policy] and, where the changes are material or we decide it is appropriate, notified to you in any manner we deem appropriate. Please check back frequently to see any updates or changes. Please note that from time to time, we may require you to read and acknowledge such updates or changes.
Purpose/activity
Type of data
Lawful basis for processing
To register you as a new SIX SIGMA SPORTS user
Identity
Contact
Location
Your consent
Necessary to comply with legal obligations
To manage our relationship with you including notifying you of changes to SIX SIGMA SPORTS or any of the Services and managing any requests or complaints received from you
Identity
Contact
Profile
Marketing and Communications
Performance of a contract with you
Necessary for our legitimate interests (to keep records updated and to analyse how customers use our products/ Services)
Necessary to comply with legal obligations (to inform you of any changes to our terms and conditions)
To administer and protect our business and SIX SIGMA SPORTS including troubleshooting, data analysis and system testing
Identity
Contact
Device
Usage
Location
Necessary for our legitimate interests (for running our business, provision of administration and IT services, network security)
To deliver content and advertisements to you
To make recommendations to you about goods or services which may interest you
To monitor trends so we can improve SIX SIGMA SPORTS
Identity
Contact
Device
Content
Profile
Usage
Marketing and Communications
Location
Consent
Necessary for our legitimate interests (to develop our products/Services and grow our business)
Cookie Title
Cookie Type
Cookie Name
Purpose
Expiry
Name: App Session Cookie
Category: Strictly Necessary
Type: Persistent Cookies
Application feature in use
Application state
Time Zone
Device type
Expires 7 days from visit
Name: User Session Cookie
Category: Strictly Necessary
Type: Session Cookies
Wallet Address
Wallet Balance
Wallet Type
Track Login/Logout of SIX SIGMA SPORTS and our Sites
End of session / Expires on Logout of our Site
This section specifies the steps to understand the complete life cycle of a bet. Please follow the below steps to implement wager and bet settlement if you want to run it on your local machine (not on the SGE mainnet). This includes the following steps:
Query the initial state of the system
Add a market
Wager on the market
Resolve the market
Settle the bet
Query the OVM public keys
Command: sged q ovm pubkeys
Expectation- At least three public keys should be present
Query the balance of the Bettor (Please ensure to change the bettor address to your specific address)
sged q bank balances <address of the bettor>
Query the list of markets
sged q market markets
Query the list of bets
sged q bet bets
Payload: The payload for adding a market is as follows: A JWT ticket should be created out of this payload for providing it in the transaction below. The timestamps need to be updated accordingly.
Transaction: The transaction for adding a market is as follows:
sged tx market add [ticket] --chain-id sge --from oracle
Verification: The above success or failure of the above transaction can be verified using the query below.
Query the transaction hash:
sged q tx [tx-hash]
Payload: The payload for participation in a market is as follows:
Transaction: To participate in a market, a Deposit command is needed
sged tx house deposit "5531c60f-2025-48ce-ae79-1dc110f16001" 1000000usge [ticket] --chain-id sge --from deposior
Verification: The above success or failure of the above transaction can be verified using the query below.
Query the transaction hash:
sged q tx [tx-hash]
Here are the articles in this section
At Six Sigma Sports, we are committed to promoting responsible gambling practices and ensuring the well-being of our users. We recognize that gambling can be both enjoyable and entertaining, but it's important to maintain control and gamble responsibly.
Here are some tips to help you gamble responsibly:
Set Limits: Establish limits on how much time and money you spend on gambling. Stick to these limits and avoid chasing losses.
Know the Risks: Understand that gambling carries inherent risks, and there is a chance of losing tokens. Only gamble with tokens that you can afford to lose.
Take Breaks: Take regular breaks from gambling to avoid it becoming overwhelming or consuming too much of your time.
Seek Support: If you feel that your gambling habits are becoming problematic or if you're experiencing difficulty controlling your gambling behavior, seek help from a professional or support organization.
For more information and support on responsible gambling, please visit:
Europe: Gambling Therapy
UK: GamCare
Brazil: Jogo Responsável
Philippines: Responsible Gaming
Canada: Responsible Gambling Council
Organizations Help & Support Resources:
These organizations provide support, advice, and resources for individuals struggling with gambling-related issues.
Remember, gambling should be fun and entertaining. Please gamble responsibly.
If you have any questions or concerns about responsible gambling, please don't hesitate to contact our support team on Telegram .
Payload: The payload for placing a bet is as follows:
Please ensure to change the kyc_id
with your bettor address, and update the timestamps. A JWT ticket should be created out of this payload for providing it in the transaction below.
Transaction: The transaction for placing a bet is as follows:
sged tx bet place-bet [uid] [amount] [ticket] --chain-id [chain-id] --from [signer-account-key]
Example:
sged tx bet place-bet 6631c60f-2025-48ce-ae79-1dc110f16123 1000000000 [ticket] --chain-id sge --from bettor
Verification: The above success or failure of the above transaction can be verified using the queries and the state table below.
Query the transaction hash:
sged q tx [tx-hash]
Expectation: Code is 0
Query the list of bets
saaged q bet bets
Expectation: One bet should be placed.
Query the balance of the bettor
saaged q bank balances sge1uffpdv3lg4v3gdwlt6pp0ty3fr7fyyau59hzmd
Payload: The payload for resolving the above market is as follows: A JWT ticket should be created out of this payload for providing it in the transaction below. The timestamps need to be updated accordingly.
Transaction: The transaction for resolving a market is as follows:
sged tx market resolve [ticket] --chain-id [chain-id] --from [signer-account-key]
Example:
sged tx market resolve [ticket] --chain-id sge --from oracle
Verification: The above success or failure of the above transaction can be verified using the query below.
Query the transaction hash:
sged q tx [tx-hash]
The bettor has been rewarded with the payout from the house.
This section specifies the steps to understand the complete life cycle of a bet. Please follow the below steps to wager and bet settlement. This includes the following steps:
Query the initial state of the system
Add a market
Wager on the market
Resolve the market
Settle the bet
The pre-requisites are:
Start the blockchain.
Add tokens to the accounts for doing the transactions.
The result of the below queries can be matched with the below state table of this section.
Query the OVM public keys
Command: sged q ovm pubkeys
Expectation- At least three public keys should be present
Query the balance of the Bettor (Please ensure to change the bettor address to your specific address)
sged q bank balances <address of the bettor>
Query the list of markets
sged q market markets
Query the list of bets
sged q bet bets
Payload: The payload for adding a market is as follows: A JWT ticket should be created out of this payload for providing it in the transaction below. The timestamps need to be updated accordingly.
Transaction: The transaction for adding a market is as follows:
sged tx market add [ticket] --chain-id sge --from oracle
Verification: The above success or failure of the above transaction can be verified using the query below.
Query the transaction hash:
sged q tx [tx-hash]
Payload: The payload for participation in a market is as follows:
Transaction: To participate in a market, a Deposit command is needed
sged tx house deposit "5531c60f-2025-48ce-ae79-1dc110f16001" 1000000usge [ticket] --chain-id sge --from deposior
Verification: The above success or failure of the above transaction can be verified using the query below.
Query the transaction hash:
sged q tx [tx-hash]
Payload: The payload for placing a bet is as follows:
Please ensure to change the kyc_id
with your bettor address, and update the timestamps. A JWT ticket should be created out of this payload for providing it in the transaction below.
Transaction: The transaction for placing a bet is as follows:
sged tx bet wager [uid] [amount] [ticket] --chain-id [chain-id] --from [signer-account-key]
Example:
sged tx bet wager 6631c60f-2025-48ce-ae79-1dc110f16123 1000000000 [ticket] --chain-id sge --from bettor
Verification: The above success or failure of the above transaction can be verified using the queries and the state table below.
Query the transaction hash:
sged q tx [tx-hash]
Expectation: Code is 0
Query the list of bets
saaged q bet bets
Expectation: At least one wager is needed.
Query the balance of the bettor
saaged q bank balances sge1uffpdv3lg4v3gdwlt6pp0ty3fr7fyyau59hzmd
Payload: The payload for resolving the above market is as follows: A JWT ticket should be created out of this payload for providing it in the transaction below. The timestamps need to be updated accordingly.
Transaction: The transaction for resolving a market is as follows:
sged tx market resolve [ticket] --chain-id [chain-id] --from [signer-account-key]
Example:
sged tx market resolve [ticket] --chain-id sge --from oracle
Verification: The above success or failure of the above transaction can be verified using the query below.
Query the transaction hash:
sged q tx [tx-hash]
The bettor has been rewarded with the payout from the house.
SIX SIGMA SPORTS General Terms and Conditions
Please read these SIX SIGMA SPORTS General Terms and Conditions carefully before using the SIX SIGMA SPORTS website or the mobile application. If you have any questions relating to SIX SIGMA SPORTS or these General Terms and Conditions, please check [https://six-sigma-sports.gitbook.io/docs/faq], or contact [support@sixsigmasports.io]. By using the SIX SIGMA SPORTS services and/or registering for an account with us, you indicate your acceptance of the General Terms and Conditions, and the rest of the Agreement, as described and/or set out below.
You should also read our Privacy Policy which explains how we use your personal information. You can find our Privacy Policy [https://six-sigma-sports.gitbook.io/docs/privacy-policy].
These General Terms and Conditions were last updated on 1-December-2023 and supersede any previous version of the General Terms and Conditions.
1. What are these General Terms and Conditions?
1.1 When you register for an account with SIX SIGMA SPORTS and/or use or access any of the products or services (including websites and applications) offered by SIX SIGMA SPORTS (the “Services”) you enter into a legally binding agreement with us (“Agreement”), which is comprised of and includes:
· these general terms and conditions (“Ts&Cs”);
· the betting rules, as updated from time to time and available here [https://six-sigma-sports.gitbook.io/betting-rules/group-1/rules-by-sport]; and
· the rules for any promotion that we offer from time to time (“Promotion Terms”).
1.2 If there is any conflict between these Ts&Cs and any other terms or rules which comprise the Agreement, these Ts&Cs will take precedence.
1.3 In the Agreement we will refer to you, the end user of the Services, as “you” and “your”.
2. Why is this Agreement important?
2.1 These Ts&Cs, together with the additional terms and rules which comprise the Agreement (as described in Section 1 above), form a legally binding agreement between you and us.
2.2 You should take time to ensure you understand and are happy with the Agreement before you register for an account or use the Services. If you don’t understand any part of the Agreement or do not agree to any of the terms, you should not register for an account, or use our services in any way.
3. Who are we?
3.1 We are Sunseven N.V., a company organised under the laws of Curaçao, registered under number 100554, with address at Heelsumstraat 51, E-Commerce Park, Curaçao. We are licensed to carry and exploit the brand SIX SIGMA SPORTS by a third party.
3.2 We are licensed and regulated by the government of Curacao (licence number #8048/JAZ2008-001).
4. How could the Agreement or the Services change?
4.1 We may vary the terms of the Agreement from time to time for a number of reasons, for example to reflect changes to the Services or any changes in law or regulation or for security purposes.
4.2 Minor changes to the Agreement can be made at any time. A minor change includes a change that doesn’t materially alter your rights, or our obligations, to your detriment. You should review the Agreement and any amendments to them regularly.
4.3 We will notify you of any material or major changes to the Agreement before that change takes effect. We will provide notice of material changes by sending an email to the email address you have provided to us and/or via a message or pop-up notice when you log into your account.
4.4 Your continued use of the Services following any change to the Agreement taking effect constitutes your acceptance of the updated Agreement. If you do not agree to any change to the Agreement, you should stop using the Services. You may close your Account at any time.
4.5 We may suspend, modify, remove and/or add products and services to the Services at our reasonable discretion from time to time. If the relevant change to the Services would constitute a material change which is to your detriment, we will try to give you prior notice wherever possible, however some amendments to the Services may be required to be made with immediate effect and without notice (for example, for security reasons).
5. Am I eligible to open an account and use the Services?
5.1 You need to register and be accepted for an account with us (“Account”) to use the Services. To be eligible to open an account, you must:
· be 18 (eighteen) years of age or older and legally capable of entering into legally binding contracts. Underage gambling is a criminal offence;
· Not reside in The United States, The United Kingdom, Aruba, Australia, Belarus, Belgium, Bonaire, Cuba, Curacao, France, Germany, the Indian State of Andhra Pradesh, the Indian State of Assam, the Indian State of Odisha, the Indian State of Tamil Nadu, the Indian State of Telangana, Iran, Israel, Italy, North Korea, Qatar, Russia, Saba, Singapore, Spain, St Eutatias, St Maarten, Statia, Sudan, Syria, The British Virgin Islands, The Netherlands, Venezuela or any other jurisdiction in which gambling is or becomes strictly prohibited;
· not be self-excluded from gambling or otherwise prohibited for any reason from gambling with us or from using the Services;
· be acting solely for your own personal non-professional use, on your own behalf, and expressly not on behalf of any other person or company. Any bets or wagers placed via your Account must be for your own benefit and not for the benefit of, or made in conjunction with, any third party;
· not already have an open account with us. Only one account is permitted per customer. If we discover that you have opened one or more additional accounts, we can close such additional account(s) and treat any Bonuses (as defined below in section 11.1) and winnings accrued from them as void;
· not have previously had an account with us which we closed; and
· have a safeguarded private key for your wallet address (being “Your Wallet”) that only you can access and control to sign transactions and prove your ownership of your Account and its assets.
5.2 Access to certain of the Services may not be legal for residents of, or persons located in, certain countries. The fact that our Services may be accessible from a country does not constitute an offer or invitation by us for the use of such Services in any country where such activities are prohibited by law. We do not accept liability if your use of our Services is in contravention of the laws of the country where you are resident or located (as applicable).
6. How do I open an account?
6.1 To open an Account, you must apply to open an account with us by completing the registration process, which is accessible here [https://account.sixsigmasports.io/account/register]. You will be asked to complete a liveliness check and to provide certain personal information during the registration, which includes a contact email, proof of identification, and proof of address.
6.2 You must ensure that the information you provide is complete and accurate and that you update it if the information changes in the future. It is particularly important that you update us about any information that affects your use of the Services as quickly as possible.
6.3 By registering, you confirm to us that you meet the eligibility criteria in Section 5 of these Ts&Cs and that all information you provide when opening an account and subsequently is and will be kept complete and accurate.
6.4 If we accept your registration for an Account, we will notify you by email.
6.5 We may decline to open an Account for any reason.
7. What checks do you undertake?
7.1 We are required to undertake certain checks to comply with our legal and regulatory obligations, for example to verify your age, identity, address, and location, and we may also undertake other appropriate credit, fraud prevention and verification checks (“Verification Checks”). We may ask you to provide various information and supporting documentation to enable us to carry out these Verification Checks, for example a copy of your passport, driving licence, birth certificate and/or proof of address.
7.2 By registering for an Account, you authorise us to conduct any Verification Checks that we may reasonably require at any time. You agree to provide us with any information we may reasonably need in relation to such Verification Checks.
7.3 We may suspend or place limits on your Account whilst we undertake the Verification Checks and/or until you provide the requested information and documents. You will not be able to place a bet until we have successfully completed our initial Verification Checks.
7.4 If we discover that you are under 18 (eighteen) years of age, all bets will be voided, and we may make a report to the relevant regulatory or law enforcement authorities. Underage gambling is illegal.
7.5 We may supply the information that you have given us to authorised credit reference agencies, who may check the details we provide against any databases (public or private) to which they have access and may keep a record of that check. We may share information with credit reference and fraud prevention agencies for use in identification checks and for fraud detection and prevention purposes. We may also share your information with our regulators. Our Privacy Policy sets out in more detail how we use your personal information.
8. What do you need to know about your user ID, password, private key and the security of your Account?
8.1 When you register with us, you will choose a unique user ID and password for your Account which will be linked to Your Wallet. You must not under any circumstances share your user ID, password or private key or allow any other person to use your Account (and/or Your Wallet). It is your responsibility to maintain the confidentiality and security of your user ID, password and/or private key and to ensure that you do not reveal your user ID, password and/or private key to anyone else.
8.2 You are responsible for all activity that takes place on your Account using your user ID, password, private key and/or other security information. We will not be liable for any claims or losses in the event that you disclose your user ID, password and/or private key to anyone else or where your negligence or deliberate act has contributed to such third-party access to your Account (or Your Wallet).
8.3 All bets placed where your username, password, private key and/or other security information have been entered correctly will be regarded as valid, whether or not authorised by you (except where our negligence or deliberate act has resulted in such party obtaining your username, password or other security information), provided that the bet otherwise complies with the Agreement.
8.4 You should change your password regularly. You must notify us of any unauthorised use of your Account (or Your Wallet) as soon as you suspect or otherwise become aware of it so that we can suspend your Account and prevent further misuse.
8.5 You must not attempt to sell or otherwise transfer the benefit of your Account to any third party and nor will you acquire or attempt to acquire an account which has been opened in the name of a third party.
8.6 If young persons are sharing or have access to your devices, we recommend that you install and use parental control software.
8.7 Your Wallet credentials (including your private key and any associated recovery phase) are personal and confidential to you and should not be shared with anyone else, including for their benefit or convenience. If you share Your Wallet details with any other person or entity, you are giving them full access and control over your wallet and its funds, and you may lose your wallet or its funds entirely or partially or incur liabilities or obligations that you did not authorise or intend.
8.8 You acknowledge and agree that we do not store, hold, or manage your private key, and that we have no access to or control over your private key. You also acknowledge and agree that we cannot recover, restore, or reset your private key if you forget, lose, or disclose it, or if it is damaged, corrupted, or hacked. If you lose access to your private key, you may lose access to Your Wallet and its assets permanently, and we will not be liable for any loss or damage resulting from your failure to safeguard your private key.
9. What do you need to know about assets listed in your Account?
9.1 To bet/wager or play games on SIX SIGMA SPORTS, you will need to hold SGE tokens (which are tokens that are native to the sports, gaming and entertainment network built using the Cosmos SDK) or any other token approved by us as a betting token in Your Wallet so that those tokens are viewable in your Account.
9.2 We do not charge you for making a deposit or withdrawal of SGE tokens or any other token approved by us as a betting token to or from Your Wallet. You may be required to pay a blockchain transaction fee, over which we have no control, for making a deposit or withdrawal and you should check with any service provider you may use for the purpose if they will apply any charges. We do not accept any responsibility for fees or charges applied by third parties.
9.3 We do not offer credit.
9.4 If funds are credited to your Account in error, please contact us promptly. We may recover such funds by account adjustment.
9.5 You are responsible for reporting or declaring any funds withdrawn, including winnings, if such reporting is required by local law, tax or other authorities.
10. What do I need to know about placing a bet and using the Services?
10.1 We only accept bets made online (including via our mobile applications). Bets are not accepted in other ways, including by telephone, email, post or fax, and will not be valid if received in such a way.
10.2 It is important that you ensure that all details of any bet are correct. Once we have accepted a bet, you cannot change or cancel it. We may refuse the whole or part of a bet for any reason.
10.3 A bet is not accepted by us until we have confirmed it to you.
10.4 You agree that, save in the case of manifest error or our negligence, we and our transaction data and records shall be the final authority in determining the terms and settlement of any bets you place, subject to your rights under Section 20 of these Ts&Cs.
10.5 You may only place bets using the SGE tokens or any other token approved by us as a betting token in Your Wallet.
10.6 You may implement certain limits on your Account using our safer gambling tools. Please see [https://six-sigma-sports.gitbook.io/docs/responsible-gambling-resources] for more information. We may also implement certain limits on your Account in accordance with our legal and regulatory obligations and commitment to safer gambling.
10.7 We may place maximum limits on the amount of each bet you may place using the Services. We may also impose limits on the maximum amount of winnings, which apply regardless of the amount you have bet or staked, and/or maximum amount of bets that you may place. Please see our Betting Rules for more information.
10.8 You are fully aware that there is a risk of losing money, SGE tokens and/or any other tokens when gambling, including when participating as the House, and you are responsible for any such loss.
10.9 Information shown on the Services for the purpose of gambling is for illustration purposes only and does not constitute any advice, endorsement or recommendation by us and we do not accept responsibility for bets that are placed on the basis of such display information. This information may be provided by third parties and may not be up to date (for example, live video coverage may be subject to a delay of a few seconds) or may be affected by an Error (please see Section 14 below).
11. What terms apply to promotions, bonuses and offers?
11.1 We may offer certain promotions, bonuses and other offers from time to time (“Bonus”). For example, free bets, token rewards and price and bet boosts. All such offers are subject to the Agreement and any other specific terms relating to the relevant offer that we publish. Serious failure to comply with such rules will render the applicable Bonus and any winnings attributable to such Bonus void.
11.2 All Bonuses can be restricted to particular customers and do not have to be generally offered to all customers.
11.3 We may withdraw, amend or cancel any offer at any time and without notice. If we do so, any offers that you have opted in for or otherwise accrued will still be valid in accordance with the relevant terms that applied at the time of their grant, or we will take such other measures as may reasonably be required to ensure that you are not otherwise disadvantaged. Other than in exceptional circumstances, we will provide notice of any withdrawal, amendment or cancellation of an offer.
12. What is our approach to safer gambling? What safer gambling tools are available? How can I self-exclude?
12.1 We are committed to safer gambling and have a number of self-help tools to help you manage your gambling. These tools provide you with the ability to:
· control and limit your spending;
· receive notifications about the duration of your session of play;
· temporarily “cool off” (“Time Out”) from using the Services for a set period of time; and
· self-exclude by deactivating your Account.
12.2 Please refer to [https://six-sigma-sports.gitbook.io/docs/responsible-gambling-resources] for more information about our safer gambling tools, including how to access advice and support on how to gamble responsibly.
12.3 We may not accept bets originating from a person we reasonably believe to be self-excluded.
13. What additional rules apply to ensure betting via SIX SIGMA SPORTS is fair?
13.1 It is a condition of our acceptance of bets from you, and by offering to place a bet with us you promise that:
· you are not prohibited from entering into the bet by any term of your contract of employment, this Agreement or any rule of a sport governing body or other professional body of which you are a member, which applies to you;
· where the bet is a bet placed on the outcome of a race, competition or other event or process or on the likelihood of anything occurring or not occurring, you do not know the outcome of such event; and
· you are not misusing non-public information to place a bet.
13.2 In the event of any promise made by you pursuant to Section 13.1 proving to be false, we may void bets and/or suspend your Account and we shall not be obliged to pay any winnings which might otherwise have been payable in respect of the bet.
13.3 If there is reasonable evidence or reasonable suspicion of price or event rigging, or manipulation in relation to any event or game, or if the integrity of an event or game has been called into question, or if we have been made aware of irregular or unusual betting patterns, or there is any attempt to defraud us, we may:
· suspend our offering on any event or series of events in any of its markets; and
· void all relevant bets or withhold settlement of them until the outcome of any investigation is confirmed. If no fraudulent or unlawful conduct is found to have occurred, settlement of the relevant bets shall be completed.
13.4 If fraudulent or unlawful conduct is found to have occurred in respect of any event or series of events (by the appropriate sports governing bodies or by any other means), we may suspend any bets placed on such events, either by any individual identified as having misused non-public information or by any other individual who in our reasonable opinion is connected to, acting in conjunction with, or in any way involved with such individual or the event manipulation.
14. What happens if there is an error, malfunction or other issue which affects the Services?
14.1 We try hard to provide a high-quality and reliable online gambling service but from time to time, errors – whether technical, human or otherwise - may occur which affect the Services (“Errors”). Certain kinds of Errors may not be apparent or detectable by you and/or us until our checks have been completed.
14.2 In this Section 14 we set out a description of the types of Errors that can occur and what the consequences are for any bets you have placed. Please also refer to Section 20 which explains what liability we will and will not accept for losses that may result when these (and other) things go wrong.
14.3 Errors may include the following:
· systems and/or communications errors, delays, severe latency, technical failures, interruptions, malfunctions, bugs and/or viruses. We will refer to these Errors as “Interruptions”;
· errors in the odds and/or terms of a bet published for the purposes of betting, for example:
(a) where the odds or terms of a bet are mis-stated;
(b) where there is a “palpable error” or “obvious error” (being where we erroneously offer odds that are materially different from those available in the general market or clearly incorrect given the chance of the event occurring);
(c) where a bet offer includes an incorrect participant (for example an individual or team that is not participating in the relevant event); and/or
(d) in respect of “live” or “in-play bets” if the odds offered by us are based on a score or result displayed on the Services which differs from the actual score at such time as provided by the relevant sports governing association, body or organisation;
· errors in our acceptance of a bet, for example:
(a) where a bet placed by you is accepted by us in error;
(b) where a bet (other than a “live” or “in-play bet”) is accepted by us after the start of the relevant event; and/or
· in respect of “live” or “in-play bets” (to the extent we offer such bets):
(a) where a bet is accepted by us at the wrong odds or an incorrect price due to the live coverage being delayed or otherwise faulty;
(b) where a bet is accepted by us on an in-play event which has already occurred; or
(c) where a bet is accepted by us after an event which is separate to the one that you are betting on has already occurred or is occurring and such separate event can in any way be considered as contributing to the result of the event bet on (for example, with regards to football a free kick is awarded and you place a bet that the next goal to be scored will be by way of free kick); and/or
· errors in our settlement of a bet and/or our calculation and distribution of winnings, for example if we settle a fixed-odds bet using odds other than those at which you placed your bet, if we pay out winnings for a losing bet or wager, or if we distribute winnings that are not due to you.
14.4 If there is an Error: (a) any bet that you have made that has been affected by that Error will be void; and (b) any winnings or bonuses (or any other similar benefit) (“Winnings”) awarded to you or paid to you which you would not have otherwise been awarded or paid (as applicable) but for that Error occurring (“Erroneous Winnings”) will be void. This means that your bet will not count and any Erroneous Winnings will not be payable to you by us. This will be the case whether or not the Erroneous Winnings are credited to your Account. We may suspend betting markets whilst an Error persists.
14.5 Whilst we investigate whether any Winnings are Erroneous Winnings, we may temporarily suspend payment of such Winnings to you. If we find that such Winnings are not Erroneous Winnings, we will process the payment/credit of such Winnings. If we find that such Winnings are Erroneous Winnings, we will not pay/credit these to you.
14.6 If you are for any reason able to access and use any Erroneous Winnings in Your Wallet, you agree to repay such amount to us promptly. We may deduct an amount equal to this amount against any amount owed to you by us.
14.7 Where any Error is or becomes apparent or obvious to you or you suspect that an Error may be occurring, you agree that you will cease your use of the relevant Services and report it to [support@sixsigmasports.io] immediately.
14.8 In the event of an Interruption, we will do our best to handle those in a way that is fair and does not systematically disadvantage our customers.
15. What am I not allowed to do when using the Services?
15.1 You may only use the Services, including your Account, for lawful gambling in accordance with the Agreement. You must not engage in any activity which we define below as a “Prohibited Activity” and you acknowledge and understand that the consequences of you doing so may include the voiding of any relevant bets, the withholding of any winnings, and the suspension and/or closure of your Account. You may also be liable to compensate us for losses suffered by us as a result of you engaging in a Prohibited Activity.
15.2 The following activities are each defined as a “Prohibited Activity”:
· any form of fraudulent or illegal activity or cheating (including any activity set out in Section 16 below);
· abuse of special offers or promotions. This includes where we know or reasonably suspect that you are taking unfair advantage of, or exploit or manipulate (or attempt to exploit or manipulate) any of the promotions, bonuses or special offers that we may offer on via the Services;
· if you are located in any territory in which the use of the Services is not legal or in jurisdictions from which we do not accept customers, including if you are using a VPN to disguise your location;
· if you use the Services other than for your personal and recreational use;
· if you provide incorrect or misleading information while registering for an Account;
· if you allow or enable someone else to use your Account;
· if you have deliberately or fraudulently opened or are using more than one Account;
· using the Services in any way that may lead to the encouragement, procurement or carrying out of any criminal or unlawful activity, or cause distress, harm or damage to any other person;
· if we discover that you are accessing the Services in contravention of the laws of the country where you are located;
· if you knowingly introduce viruses, trojans, worms, logic bombs or other material which is malicious or technologically harmful. You must not attempt to gain unauthorised access to our websites and mobile applications or any server computer or database connected to our websites or mobile applications;
· if you infringe our rights (including intellectual property rights) or the rights of any other person;
· if you make any statements to other customers and/or our personnel or submit any material that is abusive, defamatory or discriminatory; or
· if you seriously breach the Agreement in some other way.
16. How do SIX SIGMA SPORTS deal with fraud and cheating?
16.1 Fraudulent activity or cheating constitutes a serious breach of the Agreement. We consider fraudulent activity or cheating to include:
· identity fraud;
· payment fraud;
· money laundering;
· third-party funding;
· forgery;
· using payment details or a wallet that does not belong to you (including stolen or fraudulent payment details);
· collusion with other individuals;
· utilisation of software to gain an unfair advantage;
· circumventing any of our registration and/or bet placement processes in order to register an account and/or place a bet (including by circumventing our front-end software (including our onboarding process) in order to submit a bet directly on the blockchain);
· exploitation of Errors, malfunctions or Interruptions;
· betting on fixed sporting events; and/or
· misuse of non-public or inside information.
16.2 You may not in any way interfere, interrupt, attempt to interrupt, or attempt to manipulate the operation of our Services or the normal play of any of our products. You agree to play personally via the interfaces made available by us only.
17. Can SIX SIGMA SPORTS close your Account?
17.1 We may close, limit or suspend your Account at any time. We will take reasonable steps to notify you in advance of any closure, other than where you have seriously breached the Agreement (in which case such closure may take effect without notice).
17.2 If we have reasonable grounds to suspect that you have engaged in any Prohibited Activity, we may suspend your Account without notification, and your Account will remain suspended while the matter is investigated. You agree to cooperate fully with any such investigation. Your funds cannot be accessed or withdrawn during periods of suspension, and any balance will remain in the Account. We will use reasonable efforts to undertake our investigation within a reasonable period.
17.3 If our investigation results in our decision (acting reasonably) that the issue has been resolved to our satisfaction, we may lift the Account suspension. If our investigation results in our decision (acting reasonably) that you have engaged in any Prohibited Activity, we may restrict or permanently close your Account. In these circumstances, your details may be passed on to any applicable regulatory authority or any other relevant external third parties.
17.4 We may also from time to time be required by a competent authority to restrict, suspend or close Accounts for legal or regulatory reasons. Such restrictions, if applicable, may affect your use of your Account.
17.5 You agree to compensate us for any costs, charges or losses sustained or incurred by us arising from any Prohibited Activities on your part.
18. How can you close your Account?
18.1 You can close your Account at any time by making the request via email at [support@sixisgmasport.io].
18.2 You remain responsible for all activity using your Account until it is closed.
19. What happens to outstanding bets if your Account is closed?
19.1 Closure of your Account may automatically render any bets, Bonuses or promotions void. We may not be able to reinstate these if the Account is subsequently reopened.
20. What losses will SIX SIGMA SPORTS be liable to you for?
20.1 As a consumer, you have certain rights under the applicable local laws in respect of our provision of the Services. You have certain legal remedies if we breach any of these rights. Nothing in the Agreement will affect or undermine these legal rights or remedies.
20.2 Nothing in this Agreement is intended to, or will, exclude or limit our liability for:
· fraud;
· death or personal injury resulting from our negligence; or
· any other liability which we may not limit or exclude under the applicable law.
20.3 Subject to Sections 20.1 and 20.2 above, we will not be responsible to you or any third party in any way, for any loss or damage whatsoever arising from or in any way connected with:
· indirect losses which are a side effect of the main damage and losses that were not foreseeable by you and us at the time of you first accepted the Agreement;
· business losses and/or losses to non-consumers (for example loss of business, loss of business information, business interruption and loss of profits or revenues);
· losses resulting from third party services, equipment and devices that you use to access the Services;
· any use by you of our Services in breach of this Agreement (including any Prohibited Activity on your part);
· any incomplete, lost or delayed transactions (including as a result of technical failure), other than to the extent caused by our failure to use reasonable care and skill;
· damage to your equipment (e.g. desktop, laptop, mobile, smartphone, tablet, games console or other internet-enabled device) or for any loss or corruption of data that results from your use of our Services;
· the accuracy, completeness or currency of any information services provided by us or third parties (including but not limited to prices, runners, times, results, live scores or general statistics);
· any Error, malfunction or Interruption other than to the extent caused by our failure to use reasonable care and skill;
· our closure or suspension of Your Account in accordance with this Agreement; or
· failure or delay by us to provide the Services or to meet any of our obligations under the Agreement to the extent that such failure or delay results from events beyond our reasonable control. Events beyond our reasonable control include but are not limited to cyber-attack, fire, flood, storm, riot, earthquake, pandemic, epidemic, public utility failures, delays or disruptions of the internet or telecommunications networks, civil disturbance, war, nuclear accident, terrorist activity and acts of God.
20.4 We will not be liable to you under this Agreement for, and nor do we owe you a duty of care in respect of, our compliance or non-compliance with any regulatory obligations that we may be under from time to time including those relating to so-called 'safer gambling', ‘responsible gambling’ or 'social responsibility'.
20.5 There is a risk of losing money when gambling and you are responsible for any such loss.
20.6 Subject to Sections 20.1 and 20.2, we do not promise that the Services will have uninterrupted availability or that they will be free of bugs, viruses or Errors. Access to the Services may be suspended temporarily and without notice in the case of system failure, maintenance, repair or for reasons beyond our reasonable control.
20.7 You accept that, in relation to time-critical gambling events, there is a risk that you may be at a disadvantage compared to other players because of technical issues such as slower network speeds, or slower end user device performance.
20.8 Subject to Sections 20.1 and 20.2 above, and save in respect of any winnings properly due to you in accordance with this Agreement, our maximum liability to you under this Agreement in relation to any one incident or series of related incidents is limited to the greater of:
· where such liability relates to a specific bet, the amount of the applicable stake made by you in respect of such bet; or
· £10,000 pounds sterling.
21. Who owns the SIX SIGMA SPORTS website, app and the Services?
21.1 All intellectual property rights in our Services (including our website, applications and other integrations) and all material and/or content made available on the Services (including but not limited to rights in the products and services offered, all code, software, data, information, animations, graphics, music, sound, photographs, video content or text, and the selection and arrangement thereof) (“Materials”) or otherwise by us shall remain at all times our property or the property of our third party licensors.
21.2 The names, images and logos identifying us, our partners or third parties and our/their products and services contained in our websites and mobile applications are proprietary marks and may not be reproduced or otherwise used without our express written permission.
21.3 Nothing contained in this Agreement shall be construed as conferring by implication any licence or right to use any trademark, patent, design right, copyright or other intellectual property that belongs to us or any third party.
21.4 You may not sell, assign, license, distribute, copy, modify, publicly perform or display, transmit, publish, edit, adapt, create derivative works from, or otherwise make unauthorised use of the Services or Materials without our express prior written consent. Except as permitted by law, you must not de-compile, re-engineer or disassemble the Material, nor attempt to interfere with its correct operation. You agree not to remove, obscure, or alter any copyright, patent, trademark, or other proprietary rights notices affixed to Material.
21.5 Subject to the Agreement, you may download one copy of insubstantial excerpts of the Material to your PC, mobile or any other device for the sole purpose of viewing it without modification.
21.6 The information which we or third parties provide (including results, statistics, fixture lists, odds and betting figures) as part of the Services is for your personal use only and the distribution or commercial use or exploitation of such information by you is strictly prohibited. No information which we or third parties provide on our websites, apps and Services is intended to amount to advice or recommendations and is provided for information purposes only.
21.7 Our Services may contain links and references to third party websites and resources, these links are provided for your information only. We have no control over the content of third-party sites or resources, and we accept no liability for them or for any loss or damage that may arise from your use of them. The inclusion of a link to a third-party website does not constitute our endorsement of that third party’s website, product or services (if applicable). We will not be a party to, or in any way be responsible for, monitoring any transaction between you and third-party providers of products or services.
22. How can I contact you?
22.1 You can contact us by emailing: [support@sixsigmasports.io]
23. What happens if I have a complaint or dispute?
23.1 If a dispute arises in relation to a bet placed, our transactions database will be the ultimate authority in such dispute (save in the case of manifest error or our negligence).
23.2 We hope it never happens but if you wish to make a complaint, please notify us by contacting [support@sixsigmasports.io].
23.3 If you are unhappy with the decision of Customer Support you can choose to escalate your complaint by making a written request. We will respond to any such request within fourteen (14) working days and enter into good faith discussions with you regarding the dispute. If the dispute is not wholly resolved, we will enter into mediation in good faith to settle the dispute. Unless otherwise agreed between you and us, within fourteen (14) working days of such agreement to enter into mediation, the mediator will be nominated by us. To initiate the mediation a party must give notice in writing to the other party to the dispute, referring the dispute to mediation (the “ADR Notice”). Unless otherwise agreed, the mediation will start not later than eight (8) weeks after the date of the ADR Notice.
23.4 Neither you nor we may commence any court proceedings/arbitration in relation to the dispute arising out of the Agreement until the relevant party has attempted to settle the dispute by mediation and either the mediation has terminated, or the other party has failed to participate in the mediation, provided that the right to issue proceedings is not prejudiced by a delay.
24. Is there anything else I need to know?
24.1 If we need to notify you under this Agreement, we will do so by email to the email address registered to your Account or via notification on our websites, apps and/or or other parts of the Services.
24.2 We may transfer our rights and/or obligations under this Agreement to another organisation at any time. We will treat this as a major change to the Agreement, as described above in Section 4.3. If you are unhappy with the change, you may close your Account with us at any time.
24.3 This Agreement is personal to you. You may not transfer your rights or obligations under this Agreement to anyone else.
24.4 If you breach this Agreement and we take no action against you, we will still be entitled to use our rights and remedies in any other situation where you breach this Agreement.
24.5 If any part of this Agreement is disallowed or found to be ineffective by any court or regulator, the other provisions shall continue to apply.
24.6 This Agreement is not intended to give rights to anyone except you and us. This does not affect our rights under Section 24.2.
24.7 This Agreement is only available in the English language.
24.8 This Agreement is governed by and will be interpreted in accordance with the laws of Curaçao.
24.9 Disputes arising in connection with this Agreement shall be subject to the exclusive jurisdiction of the courts of Curaçao.