# Essential Info
## **Platform Overview**
FunPay creates a marketplace where buying, selling, and participating all feed into the same economic engine. Merchants list products or services, consumers complete purchases, and every transaction becomes part of a measurable contribution cycle powered by FP (FunPower) and the platform token FUN.
At the center of the system is a simple idea: economic activity should convert into lasting value for the people who create it. FunPay does this through a structured flow that records participation, injects liquidity, distributes FP, and transforms that FP into FUN through a predictable, rule-based mechanism.
The platform operates through a structure that handles four core responsibilities:
{% stepper %}
{% step %}
**Commerce as the Starting Point**
Users shop through merchants who have joined the platform. When an order is completed, FunPay deducts a **20% service fee** from the merchant's revenue. Instead of treating this fee as revenue for the platform, it becomes the first input of the economic cycle. The entire fee is automatically added to the FUN liquidity pool, strengthening market depth and price support as activity grows.
{% endstep %}
{% step %}
**FP as the Measurement of Contribution**
Each transaction generates FP for both sides of the exchange.
* Merchants receive a portion of FP based on their level, usually **20%–40% of the service fee**.
* Consumers receive FP equal to **100% of the service fee** generated from their purchase.
FP is always valued at **1 USD**, which keeps contribution measurement stable and prevents artificial fluctuation. FP doesn’t act as a tradable asset; instead, it is a way to quantify how much economic value each participant has added to the system.
{% endstep %}
{% step %}
**Transforming FP Into FUN**
FP converts into FUN through a daily generation cycle. Once a day, between **UTC 00:00 and 02:00**, the system calculates how much FUN a user can claim based on their FP balance, their generation coefficient, and the current FUN price. Higher membership levels unlock higher conversion efficiency.
Users must claim their daily FUN within seven days; unclaimed amounts expire.\
This rule ensures the system rewards active participation instead of passive accumulation.
{% endstep %}
{% step %}
#### **A Built-In Burning Mechanism**
FP does not grow endlessly. Every time FUN is generated, **FP is burned**, gradually reducing circulating FP and maintaining balance in the system.
* **0.2 FP is burned** for every 1 USD worth of FUN generated.
* **0.1 FP is burned** for every 1 USD worth of referral commission.
Once a user’s FP reaches zero, their FUN generation stops until they earn FP again through new activity. This ensures only contributors stay eligible for ongoing rewards.
{% endstep %}
{% endstepper %}
#### **Why the Model Holds Together**
Each part of the system feeds the next:\
transactions create FP → FP allows FUN generation → FUN burns FP → FP scarcity increases → new activity replenishes FP.
The result is a closed loop where users and merchants benefit directly from real transactions, liquidity strengthens automatically with every order, and the incentive environment stays tied to measurable economic behavior instead of speculation.
***
### **Supported Wallets**
FunPay supports all major wallets that interact with BEP-20 tokens.
**Supported at launch:**
* MetaMask
* Trust Wallet
* Binance Wallet
**Additional wallet integrations:**\
\&#xNAN;*(Details will be added once provided.)*
Wallet functions required by FunPay:
* Receiving FUN rewards
* Signing merchant payment confirmations
* Redeeming rewards inside the platform
* Participating in platform-level incentives
***
### **Gas, Fees, and Transactions**
FUN transactions follow standard BSC fee rules.
* **Gas Paid In:** BNB
* **Average Fee:** Low, due to BSC throughput
* **Settlement Time:** A few seconds under normal conditions
* **Fee Behavior:**\
High-traffic periods increase gas slightly, but do not affect FUN reward issuance.
For internal platform actions (reward issuance, merchant reinjection, value scoring), the FunPay smart contracts handle the execution while maintaining their own settlement logic.
***
### **Reward Circulation Rules**
The FUN reward system exists to reinforce consumer participation and merchant reinvestment.\
Its circulation follows a closed, repeatable model:
1. **A user completes a consumption action.**\
This action generates a measurable value signal.
2. **The system allocates FUN rewards** based on consumption weight, behaviour tier, and campaign multipliers.\
(Final reward coefficients will be added once provided.)
3. **Merchants receive FUN through reinjection mechanisms** tied to sales volume, loyalty metrics, and promotional structures.
4. **FUN returns to users** when they redeem, claim benefits, or participate in platform activities.
5. **The loop closes** when redeemed FUN contributes back to on-chain activity, supporting the next reward round.
This mechanism ensures FUN keeps circulating rather than accumulating in isolated pools.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://funpay.gitbook.io/funpay-docs/essential-info.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
