.
Fee Routing
Defines the proposed FeeRouter flow, configurable fee destinations, default allocation, and distinction between fee distribution, protocol revenue, and treasury allocation.
GetPaid proposes a routing path between a launchpad's trading fee and its final destinations.
Launchpad → Trading Fee → FeeRouter → Configurable Allocation → Final Destinations
The proposed FeeRouter would receive an intercepted fee, apply a configured split, and route each portion independently. This separates fee distribution from the launchpad's trading interface.
Proposed default split
| Destination | Allocation |
|---|---|
| Creator | 60% |
| Burn | 10% |
| Buyback | 10% |
| Protocol | 10% |
DANGER
The current model accounts for 90% of routed fees. The remaining allocation will be finalized before implementation.
Final destinations
- Creator routing: sends the creator portion to the configured fee recipient.
- Burn allocation: purchases $GET, then sends it to the dead address.
- Buyback allocation: purchases $GET, then holds it in treasury.
- Protocol allocation: moves funds to the protocol treasury.
The split is configurable in the proposed architecture.
Distribution, revenue, and treasury
These terms describe separate parts of the proposed model:
| Term | Meaning |
|---|---|
| Fee distribution | The division of each routed trading fee among destinations. |
| Protocol revenue | The proposed 10% protocol cut from fees routed through GetPaid. |
| Treasury allocation | Funds directed to the protocol treasury through that protocol allocation. |
Protocol funds are intended to support operations, insurance, development, security, and ecosystem grants. This describes intended use, not current revenue or active treasury operations.
INFO
GetPaid is pre-testnet. No fee routing is deployed, audited, or live.