parabolic

1 В· Introduction

The vast majority of tokens launched on pump.fun follow a stereotyped lifecycle: an initial pump driven by a small cohort of buyers, a brief plateau, and a near-total collapse once the bonding-curve graduation milestone is reached. The shape of this trajectory is not a property of the asset; it is a property of the absence of any mechanism shaping it.

We propose parabolic: a hook program that injects exactly such a mechanism. The protocol owner — the creator address registered on pump.fun — is set to a program-derived account that the creator never controls. All creator rewards earned from trading volume accrue inside that account. At regular intervals, the program reads the live market price, compares it against a fixed target curve, and either buys or sells the token, with all proceeds re-entering the same account. A residual fraction is burned. The combined effect is that the realized price follows the target curve to within a small, bounded error, with the bound determined by trading volume and the choice of controller gains.

The remainder of this document specifies the model (§2), describes the on-chain mechanism (§3), exposes a live simulation of the system (§4–5), and concludes with implementation notes (§6).

2 В· Model

We adopt the following baseline for the unperturbed market, then layer the protocol on top.

Assumption 1 is deliberately weak: it assigns the market no prior belief in the target curve, so any deviation from P* must be closed by the controller alone. Under a stronger Ornstein–Uhlenbeck assumption (mean-reversion toward P*) the tracking task becomes strictly easier; the bounds below are therefore worst-case relative to that stronger assumption.

2.1 В· Target curve

Let t ≥ 0 denote time since launch (in seconds). The protocol fixes a target price function

where a > 0 is a scalar slope set at deployment and Pв‚Ђ is the launch price. Equation (1) is the only commitment the protocol makes: every subsequent action is derived from minimizing the distance between (1) and the realized price P(t).

2.2 В· Tracking error

Let P(t) denote the spot price reported by the pump.fun bonding curve (pre-migration) or the post-migration AMM. Define the signed tracking error

and its derivative ė(t) = de/dt and integral ∫₀ᵗ e(τ) dτ. When e > 0 the market trades below the target; when e < 0 it has overshot.

2.3 В· Control law

The controller is a standard three-term PID with anti-windup applied to the integral:

where Kₚ, Kᵢ, K_d ≥ 0 are tuning constants. A positive u is interpreted as a buy signal of magnitude |u|; a negative u as a sell signal.

2.4 В· Fuel constraint

Let V(П„) denote the instantaneous trading volume and f в€€ (0, 1) the creator-fee fraction. The cumulative fuel available to the controller is

and the controller's input is bounded by

where S(t) is the cumulative SOL already spent on buys, net of SOL received from sells. The protocol never holds external capital; it cannot exceed (4b).

2.5 В· Phase function

The controller passes through three deterministic phases:

In acceleration, sells are disabled and 60% of each buy is burned. In tracking, two-sided PID is active; vault inventory above 5% of circulating supply overflows into burn. In terminal, buys are disabled and the vault is drained progressively into burn, after which the protocol becomes a passive observer.

2.6 В· Stability

Equation (3) defines a feedback law but says nothing about whether the closed loop converges. Below we state a sufficient condition on the gains; the live forecast of В§5 illustrates the boundary visually.

Let β > 0 denote the linearized price impact per unit control input, that is, β = ∂P/∂u evaluated at the operating point on the bonding curve. Let τ > 0 denote the keeper tick interval (the time between successive evaluations of (3)).

The first line of (6) is the classical proportional bound: gain times round-trip lag must be less than 2. The second is the differential bound: anticipatory action cannot exceed the sample period. The third couples integral and proportional gains: integral wind-up must remain dominated by proportional response, else the loop spirals.

The simulator of В§5 exposes Kв‚љ, Kбµў, K_d directly so the reader may verify (6) by inspection: gains within the box produce monotone convergence in Figure 2; gains violating the first line produce limit-cycle oscillation; gains violating the third line produce divergence. We do not provide a global stability result; (A1) admits trajectories that exceed any finite fuel budget (4b) with positive probability, and the controller is then unable to track.

3 В· Mechanism

The on-chain implementation rests on three constructs supplied by Solana and pump.fun, no extension of either is required.

(i) Creator address as program-derived account. pump.fun routes a fixed share of every swap to the creator address registered at launch. We set this address to a PDA owned by the parabolic program. As a consequence, no human key can withdraw rewards; they accrue into program-controlled state.

(ii) Keeper invocation of tick(). The program exposes a permissionless instruction tick which reads the current price from the bonding curve, evaluates (3) under (4b), and executes the resulting buy, sell, or burn via CPI into the AMM. Any account may call tick; the program rebates a small SOL bounty to incentivize timely invocation.

(iii) Atomic vault swaps. All token movements are routed through the AMM; the program never sets the price directly. The protocol is therefore subject to the same slippage as any other participant and cannot achieve arbitrarily precise tracking; the residual error is governed by (4b) and the choice of Kв‚љ, Kбµў, K_d.

A complete trace of a single tick is: collect pending creator rewards from the bonding curve into the vault PDA; observe the spot price; compute e, ∫e, ė; compute u; clamp by phase and by (4b); if buying, CPI swap SOL for token and route to vault, with overflow burned; if selling, CPI swap token from vault for SOL and retain in vault; emit an Action event with the deltas.

4 В· Live state

Figure 1 shows the realized price trajectory of the reference deployment whose contract address is published in the header above. The figure is sourced from the live pump.fun bonding curve, the corresponding PumpSwap pool when present, or the Jupiter aggregator price feed as a final fallback; the price-source resolution is automatic. All on-chain swaps that touch the mint are overlaid as markers. Transactions signed by the protocol treasury wallet (also disclosed in the header) are rendered as filled protocol markers — buy, sell, or burn — and are the visible footprint of the controller of §3 operating in its non-custodial, manually-keepered phase.

Table 1 reports the live state of the controller, the vault, and the rewards stream. All quantities are produced by the same simulator that drives Figure 1.

Table 2 shows the most recent 0 on-chain actions executed by the protocol, in reverse chronological order.

5 В· Parameter exploration

The controller gains Kв‚љ, Kбµў, K_d, the target slope a, the fee fraction f, the market-noise scale Пѓ, and the baseline volume Vв‚Ђ jointly determine the steady-state tracking error and the rate at which fuel is consumed. The controls below mutate these parameters and re-simulate the next hour of operation against the current state; Figure 2 shows the forecast under the current settings.

6 В· Limitations and threat model

We list six failure modes that the model of В§2 does not absorb. Each is presented with the conditions under which it manifests and the partial mitigations available.

6.1 В· Migration gap

Between bonding-curve graduation and the establishment of post-migration liquidity on PumpSwap there exists a finite interval during which no AMM is reachable. The tick instruction is a no-op throughout this window; tracking error e(t) accumulates without control. The interval is on the order of seconds in current pump.fun behavior but can be longer under network congestion. We do not attempt to control during the gap; we resume tracking after migration with the same controller state, which may produce a step response on resumption.

6.2 В· Keeper frontrunning

The tick instruction is permissionless. A keeper observing a pending tick transaction in the mempool can place a sandwich trade around it, capturing the protocol-induced price move. Solana's leader-rotation reduces but does not eliminate this risk. Partial mitigation: (i) trades within a configurable slippage envelope are silently skipped; (ii) the keeper bounty is set to a fraction of the realized buy/sell, removing the incentive to delay or batch ticks.

6.3 В· Attention elasticity collapse

Constraint (4b) presupposes that organic volume V(t) does not collapse to zero. Should organic interest die, no rewards accrue, the controller's budget freezes, and P(t) drifts under (A1) alone. The protocol has no mechanism to re-seed attention; the dead state is absorbing. This is the dominant terminal failure mode for any protocol whose fuel is endogenous to its own popularity.

6.4 В· MEV on protocol swaps

Each protocol-initiated swap is itself subject to MEV. A sufficiently sophisticated searcher can pre-position liquidity such that the protocol's buy is filled at an inferior price. We do not claim resistance; we bound the per-trade slippage at a configurable threshold and skip otherwise, ensuring that the controller never spends fuel at adverse rates. Over a sufficiently long horizon this lowers the effective ОІ of Proposition 1 but does not invalidate (6).

6.5 В· Irreversible parameter choice

Once Config is written at deployment, the tuple (a, Kₚ, Kᵢ, K_d, t₁, t₂, f, P₀) cannot be modified. A choice violating Proposition 1 (e.g. Kₚ · β · τ ≥ 2) cannot be corrected after the fact; the protocol will oscillate or diverge for its entire lifetime. We mitigate by requiring deployers to publish a calibration trace from the simulator of §5 alongside the program ID, demonstrating gains lie strictly inside (6).

6.6 В· Bonding-curve idiosyncrasy

The linearization underlying Proposition 1 assumes a locally smooth price-impact map. pump.fun's bonding curve is piecewise constant-product with discontinuities at graduation and at fee-tier changes; ОІ is not strictly constant. We treat it as locally constant on each segment and re-linearize at segment boundaries. The cost is occasional transient overshoot on the order of the segment width; the live trace of В§4 includes such events when the simulated state crosses a fee boundary.

7 В· Implementation notes

The reference implementation is an Anchor program targeting Solana mainnet, with three on-chain accounts: a Config singleton storing (a, Kₚ, Kᵢ, K_d, t₁, t₂, f, P₀) at deployment, a VaultPda holding both SOL and the mint, and a State account holding the rolling integral ∫e, last error, last tick timestamp, and cumulative counters. The program is non-upgradable; Config is written exactly once at deployment.

Migration from the pump.fun bonding curve to PumpSwap is handled transparently: the keeper detects the migration event and updates the swap route stored in State. Bonding-curve and AMM swaps are dispatched through a uniform Router module that exposes the same buy(sol_amount) and sell(token_amount) primitives to the controller logic.

A complete audit-ready release will publish: the deployed program ID; the deterministic Config account; a reproducible build with solana-verify; an open-source TypeScript indexer that exposes the same JSON schema as the in-browser simulator at /state, allowing this paper's figures to switch seamlessly from simulation to live data without changing the rendering code.

Until that release, this document is a research note. No token has been launched, no presale exists, and any party claiming to represent parabolic in advance of the on-chain announcement is impersonating it.

8 В· References

1. K. J. Åström and T. Hägglund. PID Controllers: Theory, Design, and Tuning, 2nd edition. Instrument Society of America, 1995.
2. K. J. Åström and B. Wittenmark. Computer-Controlled Systems: Theory and Design, 3rd edition. Prentice Hall, 1997. — discrete-time PID and the Jury stability criterion used in the proof of Proposition 1.
3. Solana Labs. Token-2022 Program: Transfer Hooks Extension. Solana Program Library documentation. https://spl.solana.com/token-2022/extensions#transfer-hook
4. Solana Labs. Program-Derived Addresses (PDA). Solana developer documentation. https://solana.com/docs/core/pda
5. pump.fun. Creator Revenue Share. Protocol documentation, retrieved 2026.
6. H. Adams, M. Salem, A. Robinson, et al. Uniswap v4 Core. Whitepaper, 2024. — closest precedent for AMM hook architectures, though the design here does not depend on v4.
7. G. E. Uhlenbeck and L. S. Ornstein. "On the Theory of the Brownian Motion." Physical Review, vol. 36, pp. 823–841, 1930.
8. S. E. Shreve. Stochastic Calculus for Finance II: Continuous-Time Models. Springer, 2004. — geometric Brownian motion, Assumption 1.
9. L. W. Cong, Y. Li, and N. Wang. "Tokenomics: Dynamic Adoption and Valuation." Review of Financial Studies, vol. 34, no. 3, pp. 1105–1155, 2021.
10. S. McKeon. "Continuous Bonding Curves." Working note, 2018. coinbase.com/blog
11. P. Daian, S. Goldfeder, T. Kell, et al. "Flash Boys 2.0: Frontrunning in Decentralized Exchanges, Miner Extractable Value, and Consensus Instability." IEEE S&P, 2020. — threat model for §6.2 and §6.4.
12. E. F. Camacho and C. Bordons. Model Predictive Control, 2nd edition. Springer, 2007. — alternative to PID that may be considered in a future revision when the platform supports atomic multi-tick scheduling.