How Stayers Works
Follow the launch, trading, graduation and discovery loop.
Code exists; Stayers production behavior is not yet verified.
A Stayers token moves through several related systems. They share a token identity but do not share a single automatic permission to spend money.
From configuration to launch
The platform first needs a reusable, approved Meteora DBC configuration. This one-time configuration defines the supply, curve, fees and migration rules; it does not create a token.
A creator then supplies metadata, reviews an exact launch transaction and its costs, and approves it in a connected wallet. Deployment of the website never performs this launch automatically.
Trading and graduation
Buyers and sellers trade against the DBC pool using SDK quotes, slippage limits and wallet-approved transactions. Curve completion makes migration possible. Graduation is recorded only when the required DAMM account and pool state establish that migration actually occurred.
The current website does not automatically route swaps into DAMM after graduation.
Fees, survival and discovery
Collected eligible fees enter token-specific accounting. Market observations support Stay Score and survival evaluation. If production qualification is approved, genuinely new milestone qualifications or comeback heuristics can create time-limited Second Wind events.
Financial authorization stays separate
Discovery qualification does not authorize a payout or liquidity deposit. Supported instructions, custody reconciliation, funding, execution limits and explicit owner approval are additional requirements. See Stay Vaults for the proposed liquidity process.
stayers.fun