Reward Pool Model

Instroduction

The Reward Pool Model is the core economic framework within the giggle ipos system. It operates by binding all user orders to a specific reward pool, enabling a structured distribution of revenue and rewards.

Each IP holder, after creating their IP token, is required to set up an associated IP Token Reward Pool. During creation, the IP holder must inject an initial amount of their IP tokens into the pool and define a unit price for these tokens within the pool. IP holders retain the ability to add further liquidity to their reward pools at any time.

Regarding reward distribution, token rewards from the pool are subject to a 180-day linear release schedule. USDC rewards, conversely, are disbursed immediately upon confirmation of the order.

How It Works

The overall flow of the Reward Pool Model is as follows:

1. IP Holder Creates Pool: The IP holder establishes a Reward Pool for their IP token, crucially defining the revenue distribution ratios.

2. Developer Creates Order: A developer integrates with the system to create orders. The system automatically links the order to the appropriate Reward Pool based on the IP holder who created it.

3. User Pays: A user completes the payment for an order.

4. Order Confirmation: The giggle ipos system processes and confirms the order payment.

5. Reward Allocation: Upon order confirmation, the system allocates the revenue based on the distribution ratios specified by the IP holder for the bound Reward Pool.

Note: Once an order is confirmed and rewards are released, the order cannot be refunded.

Here is a Mermaid diagram illustrating this workflow:

Allocation

In every order payment, giggle ipos deducts a fixed 10% as the platform fee. Your configuration, specified via the revenue_ratio property, defines the distribution model for the remaining 90% of the revenue.

When defining the allocation details within revenue_ratio, each entry must include the following four properties:

• address: The on-chain wallet address designated to receive the allocated revenue share. This field is only effective when the role is set to customized.

• ratio: The proportion of the remaining 90% of the revenue allocated to this entry. This is expressed as an integer (e.g., 20 represents 20%). The sum of all ratio values in your revenue_ratio configuration should equal 90.

• allocate_type: Specifies how the revenue share for this entry should be allocated.

  • usdc: (Default) The revenue share will be distributed in USDC form upon order confirmation.

  • token: The revenue share will be converted into an equivalent value of the IP token from the reward pool and will be subject to the 180-day linear release schedule to the recipient's wallet.

• role: Defines the recipient or purpose of this revenue share. We currently support the following roles:

  • buyback: The revenue allocated to this account is designated for the buyback of the IP token from the reward pool, potentially reducing supply or increasing pool liquidity. If no inviter is associated with an order, the revenue share designated for the inviter role will automatically be reallocated to the buyback account.

  • inviter: The revenue share is allocated to the inviter of the user who placed the order. For all orders paid by an invited user, their inviter will receive this specified ratio of the revenue. If an order has no associated inviter, this share goes to the buyback account.

  • developer: When an order is paid within a widget context, this proportion of the revenue will be allocated to the developer of that widget.

  • customized: Allows you to designate a custom wallet address (address field must be specified for this role) to receive this proportion of the revenue. This provides flexibility for allocating revenue to other parties or your own cold storage.

By carefully configuring the revenue_ratio with the appropriate address, ratio, allocate_type, and role for each entry, IP holders can define a precise and automated distribution model for their IP token's revenue within the giggle ipos ecosystem.