Proposed components
| Component | Responsibility |
|---|---|
| Launch fee adapter | Collect authorized creator fees by currency |
| Fee splitter | Allocate two-thirds to liquidity and one-third to team |
| Protocol LP vault | Hold and manage protocol-owned positions |
| Community position adapter | Create user positions and preserve user ownership |
| Harvest accounting | Separate earned fees, costs and principal |
| Holder distributor | Verify funded epoch allocations and claims |
| Staking vault | Track principal and funded reward entitlements |
| Indexer / frontend | Present positions, history, quotes and transaction state |
Define control before deploying capital
The protocol needs published controls for asset allowlists, pool selection, spending limits, emergency pauses and treasury access. Multisigs and timelocks are proposed controls, not protections already present in this demo.
Community position ownership must remain distinguishable from protocol LP custody. Users should be able to understand who can withdraw or rebalance their assets and whether an independent onchain exit exists.
Bounded liquidity automation
A keeper may collect fees and rebalance positions, but it should not have unrestricted spending authority. Swaps need deadlines, minimum output checks and price-deviation limits. Allowlisted assets and venues reduce accidental routing to the wrong contracts.
Stock trading hours, stale feeds, chain finality and sequencer availability affect execution. Procedures should specify what the keeper does when a quote, feed or transaction cannot be safely validated.
What the live frontend must verify
- The connected account and correct chain before preparing any transaction.
- Canonical token, vault, position manager and distributor addresses with verified ABI versions.
- Balance and allowance reads from chain state, plus current quotes and minimum accepted amounts.
- Pending, rejected, failed, replaced and confirmed transaction states.
- Fee and principal reconciliation after every confirmed action.
- Position-level fee growth and reward proofs, rather than estimates treated as claimable balances.
Required accounting properties
- Deposits cannot receive fees earned before entry.
- Withdrawals cannot burn already-earned entitlements.
- Claims cannot be replayed or exceed the funded reward balance.
- Zero-stake periods cannot donate earlier rewards to the next depositor by accident.
- Personal LP income and protocol reward distributions must reconcile without double counting.
- Principal must not be counted as harvest revenue.
Implementation status
Only the website and local simulation are implemented. The model exercises user flows and accounting relationships using example balances. It is not Solidity code, audited custody or a wallet integration.
Production work starts by verifying the launchpad, selecting the community-position architecture, finalizing reward policies and proving the complete flow in a contract test environment.