Hyperpush Solana economy: program, treasury, and payout architecture with token-or-SOL configuration

[snowdamiz]

Parent epic

• Hyperpush: Solana treasury, configurable token/SOL payouts, and whale-proof token mechanics #21

Outcome

Define and ship the Solana-side program / treasury / pool / payout architecture with configurable token-or-SOL contributor payouts.

Why this needs clarification

The product promise is now specific enough that this issue should stop reading like a broad architecture placeholder. The on-chain path needs to support:

• automatic per-project token launch during onboarding
• a custom pool that charges fees on buys and sells
• treasury routing where fee proceeds split 10% to the hyperpush SaaS treasury and 90% to the project treasury
• configurable payout asset selection per project
• maintainer-owned authority with revocable hyperpush automation/delegation
• a reproducible localnet proof before implementation PRs are opened

Proposed architecture direction

• Custom Solana program in Rust with Anchor
• Project config / registry PDAs
• Per-project token launch flow with metadata
• Custom pool designed for later aggregator discoverability
• Buy/sell fee mechanics enforced in the pool path, not as a blanket transfer tax
• Project treasury, hyperpush treasury, and bounty escrow accounts/vaults
• Payout release path for verified/approved bug-fix rewards
• Maintainer remains canonical authority; hyperpush may automate through scoped delegation

Supply model

Use a fixed-cap supply model for the initial protocol design:

• fixed max supply at launch
• no open-ended inflation after launch
• reserve / escrow tranches can be created up front for treasury and bounty operations
• ongoing treasury replenishment should come from trading-fee flow, not perpetual minting

This is the best default balance for tradability, trust, and bounty funding.

Acceptance criteria

• Program and treasury path are real.
• The pool path is real and supports the buy/sell fee model.
• Buy/sell fees are routed automatically through the defined 10% hyperpush / 90% project treasury split.
• Payout asset is configurable per project.
• Product can actually execute the payout path.
• Token metadata / identity is set up cleanly, and the pool/event surface is designed for later aggregator discoverability.
• A PR for this issue is not treated as ready until the flow is tested and working on Solana localnet.

Localnet proof gate

Minimum proof before PR submission:

• Anchor tests for token launch, pool setup, buy/sell fee routing, treasury split, escrow creation, and payout release
• A reproducible localnet demo covering:
  1. project initialization
  2. token launch
  3. pool setup
  4. buy fee collection
  5. sell fee collection
  6. treasury split into hyperpush and project wallets
  7. payout release to a developer wallet after approval
• Explicit docs/runbook for localnet verification

Tracker context

• Labels: enhancement, roadmap
• Project-backed: yes