Tokens that lean long
A launchpad being built on Pons, where part of a token's creator-recipient fees funds a long for its holders. The intended flow, the fee split and the risks.
Development note · The public app offers a simulated demo and public data views. Lean's real-money launch, trading and redemption services are not enabled. This article explains the implementation being built.
Lean starts with a simple idea: use part of a token's trading revenue to build market exposure for people who hold it. A creator chooses a market and a fee split. Holders receive accounting units representing their allocated share of the token's strategy.
The launch integration uses Pons V2 on Robinhood Chain. Pons V2 launches through a bonding curve and supports graduation into a locked Uniswap V4 pool. Lean's contract creates a dedicated fee receiver and venue account for each token. The fee receiver collects the token's creator-recipient revenue; the router separates the creator, platform and strategy portions. The local integration rehearsal exercised a Pons launch, fee collection, ETH-to-USDG swap and a Lighter deposit. Public Lean contracts and live trading are still pending.
Where the fees go
The current Lean contract starts with a 10% platform share of creator-recipient revenue. The creator chooses how to divide the remainder, with at least half assigned to the strategy. Those terms are fixed for that token; the platform setting for future launches can change through the timelock.
The 30/70 Pons split is an assumption for this example, not a promise about every launch. Actual Pons economics are checked and pinned when a token launches. An optional creator tax is additional to the base trading fee; Pons assigns that tax to the creator recipient, where Lean applies its split. Trading revenue, collected fees and funds already deployed are different amounts.
What a holder receives
Recorded strategy deposits mint units at the accepted net asset value, or NAV. A daily calculation allocates new units using eligible holders' balances over time. Previously allocated units stay assigned to a wallet when it sells the token. A buyer begins contributing to future allocations through its own holding time.
A redemption request enters a queue. A later accepted NAV fixes its USDG amount; conversion and confirmed funding are also required before withdrawal. Stale prices, insufficient liquidity, paused withdrawals or venue problems can extend the wait. There is no guaranteed one-hour or 24-hour completion time. The current ledger has no separate redemption-fee parameter, but gas, swaps, funding and venue costs can still affect the outcome.
What can go wrong
Long exposure can lose value. Leverage, funding payments, liquidation, settlement, liquidity, smart-contract faults and failures in shared infrastructure all matter. A 1× setting is not a guarantee against loss or every liquidation scenario. Separate token accounts make accounting easier to inspect, while shared contracts, operators and venues remain shared risks.
The candidate contracts constrain NAV posting, require a separate verifier for allocation roots and withdrawal receipts, and delay root activation by six hours. Administrative changes pass through a timelock of at least 24 hours. These controls are implemented and tested locally; independent production verification and operational custody are still being configured.
Try the flow
The demo lets you create a simulated token, inspect a position and follow a redemption with no real wallet transaction. The public data pages show what has actually been indexed. Market availability there does not mean Lean has enabled a market for launches.