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...
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.
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
Required
Valid Address
sge1059gavv45jdp0l7c4kkskr0jae02j9cxmjr3f3
uid
UID of market
string
Required
Valid UUID
0435e5b6-635f-11ed-90a6-bb470175dfce
creator
creator account address
string
Required
Valid Address
sge1059gavv45jdp0l7c4kkskr0jae02j9cxmjr3f3
UID
UUID of the bet
string
Required
Valid UUID
0435e5b6-635f-11ed-90a6-bb470175dfce
creator:uid
creator account address and UID pair list
string
Required
Valid Address
sge1059gavv45jdp0l7c4kkskr0jae02j9cxmjr3f3:0435e5b6-635f-11ed-90a6-bb470175dfce
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:
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:
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.
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.
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:
Argument | Description | Type | Validation | Example |
---|
Params | Description | Type | Validation | Example |
---|
uid | Unique Identifier of a the bet | string |
| 0435e5b6-635f-11ed-90a6-bb470175dfce |
amount | It is the total wager amount (contains bet fee also) | Integer |
| 100000000 |
ticket | Used for market verification. | String (JWT token) |
| 1eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1aWQiOiI5OTkxYzYwZi0yMDI1LTQ4Y2UtYWU3OS0xZGMxMTBmMTY5OTkiLCJ4aWQiOiJCZXRPZGQiLCJuYW1lIjoiMSIsImJldF9ldmVudF91aWQiOiI1NTMxYzYwZi0yMDI1 |
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:
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:
Market module parameter types and definition.
The Market module do not have any parameters.
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 |
| "uid": "2231c60f-2025-48ce-ae79-1dc110f16444" |
value | Value of the odd selected by the bettor | sdk.Dec |
| "value": "5.0" |
market_uid | Unique identifier of the market on which the bet should be placed |
| "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 |
| 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” |
Should be a proper UUID ()
Should be a proper UUID ()
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.
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:
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.
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.
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.
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:
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
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:
Params | Description | Type | Validation | Example |
---|---|---|---|---|
status
Active or finished proposals
uint32
Required
1 or 2
1: Active 2: Finished
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.
A subaccount is a unique account variant wherein the subaccount module regulates both its balance and permissions.
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 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.
Subaccount module parameter types and definition.
The Reward module does not have defined parameters at the moment.
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
Required
Valid Address
sge1059gavv45jdp0l7c4kkskr0jae02j9cxmjr3f3
funds
the initial fund of the subaccount
uint64
Required
Valid Number
100000
duration
lock duration of the balance
duration
Required
Valid Duration
8760h
owner account address
the address of the owner of the subaccount
string
Required
Valid Address
sge1059gavv45jdp0l7c4kkskr0jae02j9cxmjr3f3
funds
the initial fund of the subaccount
uint64
Required
Valid Number
100000
duration
lock duration of the balance
duration
Required
Valid Duration
8760h
owner account address
the address of the owner of the subaccount
string
Required
Valid Address
sge1059gavv45jdp0l7c4kkskr0jae02j9cxmjr3f3
ticket
the ticket data
string
Required
Valid ticket
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.
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
Required
Valid uuid
8483cc8a-d4c8-44ef-9f06-971ec7afe059
uid
uid of the campaign
string
Required
Valid uuid
8483cc8a-d4c8-44ef-9f06-971ec7afe059
address
address of the receiver
string
Required
Valid address
sge1059gavv45jdp0l7c4kkskr0jae02j9cxmjr3f3
address
address of the reward receiver
string
Required
Valid address
sge1059gavv45jdp0l7c4kkskr0jae02j9cxmjr3f3
category
category of the reward
int32
Required
Valid address
1
campaign
uid of the campaign
string
Required
Valid uid
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 |
|
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:
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.
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.
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 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.
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.
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 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.
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:
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.
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.
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
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 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).
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:
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 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.
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 |
---|
account
depositor account address
string
Required
Valid Address
sge1059gavv45jdp0l7c4kkskr0jae02j9cxmjr3f3
account
depositor account address
string
Required
Valid Address
sge1059gavv45jdp0l7c4kkskr0jae02j9cxmjr3f3
depositor-addr
creator account address
string
Required
Valid Address
sge1059gavv45jdp0l7c4kkskr0jae02j9cxmjr3f3
market_uid
UUID of the merket
string
Required
Valid UUID
Existing market
8483cc8a-d4c8-44ef-9f06-971ec7afe059
participation_index
participation index of the orderbook participation
uint64
Required
Numeric
Existing participation
1
id
sequential id of the withdrawal
uint64
Required
Numeric
Existing ID
1
uid | Unique Identifier of a market | string |
| 0435e5b6-635f-11ed-90a6-bb470175dfce |
uid | A list of unique identifiers of markets separated by | string |
| 0435e5b6-635f-11ed-90a6-bb470175dfce |
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 |
The Order Book is a module for the order book and fund management over module accounts and actors.
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:
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.
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.
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.
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.
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.
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.
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.
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 Edwards-curve Digital Signature Algorithm. This algorithm has been chosen for the following benefits:
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
Details of the algorithm can be found here.
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 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.
The responsibility for overseeing and validating campaigns and reward allocations lies with the reward module.
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.
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 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:
Argument | Description | Type | Validation | Example |
---|---|---|---|---|
Argument | Description | Type | Validation | Example |
---|---|---|---|---|
ticket
Used for proposal verification.
String (JWT token)
Cannot be empty
Cannot contain space (More validations will be added in the future)
1eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1aWQiOiI5OTkxYzYwZi0yMDI1LTQ4Y2UtYWU3OS0xZGMxMTBmMTY5OTkiLCJ4aWQiOiJCZXRPZGQiLCJuYW1lIjoiMSIsImJldF9ldmVudF91aWQiOiI1NTMxYzYwZi0y
MDI1
ticket
Used for proposal verification.
String (JWT token)
Cannot be empty
Cannot contain space (More validations will be added in the future)
1eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1aWQiOiI5OTkxYzYwZi0yMDI1LTQ4Y2UtYWU3OS0xZGMxMTBmMTY5OTkiLCJ4aWQiOiJCZXRPZGQiLCJuYW1lIjoiMSIsImJldF9ldmVudF91aWQiOiI1NTMxYzYwZi0yMDI1
pubkeyIndex
The registered pubkey index that you are voting on behalf
uint32
Cannot be empty
The pubkey index should be available in current public keys list
The ticket should be signed with the private key corresponding to this pubkey at index
1