Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Subaccount module parameter types and definition.
The Reward module does not have defined parameters at the moment.
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.
The responsibility for overseeing and validating campaigns and reward allocations lies with the reward module.
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.
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.
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 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.
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 |
|