.

How GetPaid Works

Describes proposed launchpad fee routing, default creator, burn, buyback, and protocol allocations, plus an illustrative Pons V2 integration.

WARNING

GetPaid is a pre-testnet concept. The operating flow below is proposed and not deployed.

GetPaid is a proposed fee layer for launchpads. It routes trading fees to configured destinations.

GetPaid provides routing infrastructure. It does not operate a launchpad, bridge assets, or issue tokens. Launchpads remain responsible for their markets and trading experience.

Proposed operating flow

Launchpad
    ↓
Trading Fee
    ↓
GetPaid Fee Router
    ↓
Configurable Distribution
├── Creator
├── Burn
├── Buyback
└── Protocol

• A supported launchpad generates a trading fee.
• The fee enters the proposed GetPaid routing layer.
• The router applies the configured allocation.
• The creator allocation is sent to the designated recipient.
• The burn allocation purchases $GET and sends it to the dead address.
• The buyback allocation purchases $GET and holds it in treasury.
• The protocol allocation supports operational and ecosystem functions.

Default allocation in Whitepaper v0.1

The proposed default allocation assigns 60% to creators, 10% to burn, 10% to buyback, and 10% to the protocol.

DANGER

The current model accounts for 90% of routed fees. The remaining allocation will be finalized before implementation.

The allocation is a proposed model, not live protocol behavior. Individual launchpad support and routing configurations remain unimplemented.

Proposed Pons V2 example

Consider a token named MOON launched on Pons V2. This illustrative example assumes a 1% trading fee per trade.

Under the proposed integration, GetPaid would intercept and route that fee. The creator would receive the creator allocation. Burn and buyback allocations would operate under the proposed model. The protocol allocation would move to treasury.

This is an illustrative proposal only. It does not indicate a live Pons V2 integration.