Buyback Engineering: A Working Playbook for Fee-Funded Token Programs

The fee-funded buyback became the reference tokenomics pattern of 2024–2026, and buyback engineering—the contract-level discipline of building and operating these programs—is no longer optional knowledge for founders, smart-contract engineers, or auditors. Hyperliquid’s Assistance Fund holds HYPE with a current market value on the order of $1.3 billion (cumulative USD spent is reported in the $890M–$1B range, depending on the snapshot date) as of early May 2026, per DL News — and as of the December 2025 validator vote, the AF balance is treated as permanently burned by binding social consensus. Jupiter committed half of its protocol fees to buying back JUP, with the purchased supply locked in reserve for three years; the program was paused / under governance review in January 2026 after JUP fell ~89% from peak and roughly $70M was spent over 2025 (DWF Labs research). Jito ran a $1M TWAP buyback over ten days in four phases as the pilot in Aug–Sep 2025, then activated an automated successor via the Cryptoeconomics SubDAO (JIP-24 / JIP-26) in October 2025; the CSD has since deployed $3.2M+ in continuous buybacks committing 100% of Jito Network revenue (The Block). Each of these is a different engineering object even though the marketing language sounds identical.

Investor coverage of these programs is now saturated—dashboards, weekly burn-rate posts, sustainability takes. Buyback engineering coverage is not. What actually goes into the contract? Where does the routing fail? What does an auditor look for? When does TWAP beat continuous? Why are priority-fee Dutch auctions a separate deflationary primitive, not a feature?

This playbook treats fee-funded buyback as an engineering surface with five design axes—fee source, routing path, fund ownership, execution strategy, and sink—and walks through each axis with the three live programs as reference implementations. For HYPE-specific allocation, the Assistance Fund’s daily math, and the five-archetype map, see the HYPE tokenomics article. For the underlying choice between dividends and buyback as utilization mechanisms, see utility models. This article focuses on what comes after that choice—how to do the buyback engineering work itself.

The Engineering Surface of a Fee-Funded Buyback

Every fee-funded buyback program can be decomposed along five independent design axes. Two programs that share a tagline (“we buy back tokens with revenue”) can land on completely different points along each axis, and the resulting contracts and operational surfaces look nothing alike. Naming the axes makes the rest of the article navigable.

Axis 1—fee source. What revenue stream funds the buyback? Trading fees (HYPE perp, JUP swap aggregation), MEV revenue (JTO), lending interest (Aave proposals), priority-fee auctions (a new primitive examined below). The source determines the volatility of buyback flow—high-frequency trading fees scale smoothly with volume; auction-based or quarterly fees produce stepped flow.

Axis 2—routing path. Where does the fee go before it becomes a buyback? Direct from the fee collector to an on-chain fund (HYPE’s near-direct routing), through a treasury that releases tranches (JUP’s locked-reserve model), or through a discretionary executor (JTO’s phased TWAP). Routing complexity is where most contract bugs and most audit findings live.

Axis 3—fund ownership. Who controls the post-buyback tokens? A protocol-owned address that no key holder can withdraw from (the credible-burn-equivalent design), a multisig with bounded withdrawal rules, or a treasury wallet under DAO vote. Fund ownership determines how the market discounts the supply removal—the more discretionary the control, the less the market treats tokens as off the float.

Axis 4—execution strategy. How are the open-market buys actually placed? Continuous per-trade execution, TWAP (time-weighted average price) over a window, batched lump purchases, or auction-priced execution. This is the axis where most public dashboards focus, and where MEV exposure differs the most.

Axis 5—sink. What happens to the tokens after purchase? Burned to a null address (irreversible supply reduction), accumulated on the fund balance (off-float but not destroyed), or recycled into ecosystem incentives. The sink choice interacts with regulatory framing—burns are simpler in tax narrative; accumulation gives the protocol optionality.

A working buyback contract picks one point on each of these five axes. The combinations are not all equally valid—TWAP execution paired with burn-immediate sink is fine, but discretionary fund ownership paired with continuous execution is internally inconsistent (continuous routing typically presumes structural, not discretionary, governance). The rest of this article zooms in on each axis with the live-program references as anchors.

Three Live Programs: HYPE, JUP, JTO Compared

Three programs are operating at scale with enough public data to compare under the five-axis framework. They cluster differently on each axis, which is exactly the point—the same outcome (“token holders benefit from protocol revenue”) can be engineered through structurally different surfaces.

Sources: HYPE—Hyperliquid docs, GoPlus Security research, Nov 2025, and the December 2025 validator vote (passed 85 / 7 / 8) reclassifying the AF balance; JUP—DWF Labs research and Jupiter governance announcements February 2025 (announce Feb 13, exec Feb 17), with the program paused / under review in January 2026 after ~$70M was spent over 2025; JTO—The Block, 2025 plus the Jito CSD quarterly update, Oct 2025 (CSD active, $3.2M+ deployed since launch). All values as of early May 2026 and subject to governance changes.

HYPE optimizes for structural credibility. The near-total fee share, the protocol-owned system address, the continuous execution, the on-chain transparency, and the December 2025 validator vote that reclassified the AF balance as permanently burned all push toward a single property—the market cannot price in a “will they pause” or “will they redeploy the fund” option. The trade-off is operational rigidity: there is no policy lever to slow buybacks during a treasury crunch, because the routing is mechanical rather than governed. This works because Hyperliquid’s cost structure is small relative to fee flow; it would not work for a project that needs to fund payroll out of fees. The full HYPE design—including the Assistance Fund’s daily math, the December 2025 burn-vote context, and its risks—is in the HYPE tokenomics article.

JUP optimizes for predictability under DAO governance. The 50% allocation and the 3-year lock are explicit policy choices subject to revote. The treasury serves as a buffer between fee flow and buyback execution, smoothing operational schedule from fee timing. This is appropriate for a DAO-governed project where governance bandwidth allows policy adjustments. The trade-off — explicit in JUP’s case — is that the market does price the option to change allocation in a future vote, which is exactly what happened in January 2026 when the program was paused / put under review after JUP fell ~89% from peak and approximately $70M had been spent through 2025. The DWF Labs “>$100M/yr” projection cited above was pre-pause; the actual 2025 spend underperformed it and the policy itself is now under revision.

JTO transitioned from pilot to live automation. The first $1M TWAP buyback in August–September 2025 was a deliberate small-scale test to validate the mechanics. The Cryptoeconomics SubDAO (CSD) was then activated via JIP-24 / JIP-26 in October 2025, deploying $3.2M+ in continuous buybacks since launch using TWAP + enhanced auction infrastructure, with 100% of Jito Network revenue now committed. The market treatment shifted accordingly — from “exploratory pilot” pricing to “live structural program” pricing.

The lesson is not “HYPE is the right design and the others are wrong.” Each program is internally coherent on its own five-axis combination, and an imitator should pick the combination that fits its governance and operational constraints, not the one that has the largest headline number.

Math: Supply Removal and Sustainability

The math of a fee-funded buyback is simple to write down. It is useful to write down anyway, because most “this protocol burns N% per year” claims fall apart when the inputs are made explicit.

Four observations follow.

The rate is sensitive to price in the inverse direction. A token price rally reduces the fraction of supply removed per dollar of fee flow, because the same dollar buys fewer tokens. Programs that quote a “removal rate” without specifying the assumed price are concealing this dependency.

Volume shocks compound through the numerator. A 50% volume drop is a 50% drop in buyback dollars at the same fee rate and allocation. If price also falls in the shock (typical, because both move with macro conditions), the rate can be relatively stable in percentage terms—but absolute token removal still drops.

The allocation fraction α is the main lever for the protocol. Price and volume are exogenous; supply is fixed by emission schedule. α is what governance can move. Going from α=0.5 to α=0.9 nearly doubles r at the same inputs, which is why HYPE’s near-total allocation produces such different numbers from typical 30–50% exchange-token programs.

The denominator S is moving. Most buyback math is reported against current circulating supply. If the project also has scheduled emissions (vesting unlocks, staking rewards), the gross buyback rate overstates net float reduction. The relevant metric for holders is net float change—r_net = r − e, where e is the annual emission rate against the same S. Programs with active emission schedules need to publish r_net, not just r.

For HYPE-specific sensitivity analysis—moving daily volume, fee rate, fund allocation, price, and a volume-shock multiplier in real time—use the interactive HYPE buyback sustainability calculator. To apply the formula to another program, substitute that program’s α, f, V, P, S inputs into the same equation; the structure is universal.

Fee Routing: What Goes in the Contract

The routing path between fee collection and buyback execution is where the most contract complexity—and the most audit findings—live. The high-level architecture is a pipeline, but each stage has design choices that ripple into security posture.

A typical fee-funded routing path:

Trade execution ─────► Fee collected (in trade asset, e.g. USDC)
                              │
                              ▼
              Fee accumulator (per-block or per-window)
                              │
                              ▼
              Routing decision (allocation %)
                              │
            ┌─────────────────┴─────────────────┐
            ▼                                   ▼
  Operations bucket                  Buyback bucket
  (treasury, ecosystem)              (fund / executor)
                                              │
                                              ▼
                              Buy execution (DEX / RFQ / OTC)
                                              │
                                              ▼
                            Sink (fund / burn / reserve)

Six design points sit inside this pipeline and each is worth deciding explicitly.

Fee asset normalization. When fees are collected in a non-target asset—USDC fees, buyback target HYPE—the contract needs a swap step. The swap introduces oracle dependency (for price discovery), slippage exposure, and MEV surface. The defensible pattern—collect fees in the fee-native asset, accumulate to a threshold, swap via a route that has both a slippage cap and a price-band check against an oracle.

Allocation enforcement. The fraction α should be encoded as an immutable contract parameter or as a parameter only adjustable through a delay-locked governance proposal. Allocation that a multisig can change without delay is operationally indistinguishable from a discretionary treasury, regardless of marketing.

Accumulator threshold vs continuous. Continuous per-trade swapping is operationally simple but gas-expensive and MEV-exposed—every swap is a sandwich target. Accumulating to a threshold (e.g. $50k or per-block batching) reduces both. The threshold becomes an audit parameter—too small and the gas overhead dominates; too large and the program reads as discretionary.

Buy execution venue. The contract must specify where the buyback executes—a designated DEX pool, an RFQ counterparty, an aggregator, or an internal book. The choice has price-impact, MEV, and counterparty implications. The defensible pattern is named venues (not “best execution by operator discretion”) with a fallback rule for venue unavailability.

MEV protection. Open-market buybacks executed transparently are sandwichable. The mitigation toolkit as of 2026 spans five categories: (1) private mempool routing — Flashbots Protect and MEV Blocker (CoW DAO / Agnostic Relay, acquired by Consensys January 2026; returns up to ~90% of backrun value to users); (2) batch auctions — CoW Protocol pattern, now mainstream; (3) intent-based / solver auctions — CoW Swap, UniswapX, 1inch Fusion, which hit ~$9B monthly volume by mid-2025; (4) commit-reveal scheduling; (5) randomized or jittered timing. Most live programs combine private routing with a solver/batch venue rather than rely on a single mitigation. The savings are material at scale—commonly cited estimates put unmitigated sandwich tax in the order of 10–30 bps per swap on typical pools, though published studies report 5 bps on the deepest pools to 50+ bps on thin or volatile pairs depending on timeframe.

Accounting reconciliation. The contract needs an on-chain or off-chain ledger that closes—fees in equals operations bucket plus buyback bucket; buyback bucket equals tokens bought plus residual; tokens bought equals fund balance plus burned. Without reconciliation, drift accumulates silently and the program loses public credibility on month-to-month verification.

The HYPE Assistance Fund is the cleanest live reference for several of these decisions—near-immutable allocation, named venue on HYPE’s spot book, on-chain accumulation. The mechanics are documented in detail in the HYPE tokenomics article. For programs operating across multiple chains or with non-native fee assets, the routing pipeline gets longer and each additional stage is a separate audit object.

The Assistance Fund Pattern and Its Variants

The “Assistance Fund” term became identified with Hyperliquid’s design, but the underlying pattern—a protocol-owned address that receives buyback proceeds—has several variants that differ in important operational ways. Naming the variants helps separate “we have a fund” claims into the ones that change market behavior and the ones that do not.

Variant 1—structural protocol-owned fund. The fund address is hardcoded in the routing contract, and withdrawals are either impossible or constrained to specific protocol-defined events (liquidation backstop, insurance payouts). No human key holder can transfer tokens out for unrelated purposes. The HYPE Assistance Fund is the strongest live example—it uses the system address 0xfefefefefefefefefefefefefefefefefefefefe, which has no private key and cannot be controlled without a hard fork; in December 2025 a validator vote (passed 85 / 7 / 8) reclassified the AF balance as permanently burned by binding social consensus, which functionally pushes HYPE from a “Variant 1 structural fund” toward a “Variant 4 burn-equivalent” while preserving the on-chain accumulation footprint. The market now treats fund balance as off-float for all practical purposes.

Variant 2—multisig-controlled fund with bounded scope. The fund is held by a multisig with a published policy on allowed uses—often “buyback only, can be redeployed to ecosystem incentives via governance vote with 30-day timelock.” This is closer to a constrained treasury than to a structural burn-equivalent. The market discounts fund balance somewhat, depending on the multisig’s track record.

Variant 3—reserve contract with time lock. Purchased tokens are sent to a contract that releases on a fixed schedule. JUP’s 3-year lock is a clean example—the lock substitutes for fund ownership ambiguity. The tokens are visibly inaccessible for the lock period, after which a governance decision applies. The market treats locked tokens as off-float for the lock window and prices in the unlock event.

Variant 4—burn-equivalent sink (no fund). Purchased tokens are immediately sent to a null address. There is no fund, no balance to dispute, no withdrawal policy. This is operationally simplest but eliminates protocol optionality—the tokens are gone and cannot be redeployed for insurance, liquidations, or strategic purposes.

The withdrawal-authorization rules are the part most often underspecified. A fund design that says “the Assistance Fund will be used for the protocol’s benefit” without enumerating allowed uses, decision thresholds, and timelock parameters is functionally a discretionary treasury with a different name. The Hyperliquid design narrows this by tying withdrawals to insurance events with on-chain triggers, but the formal withdrawal rule set still has room to be made more explicit. For any imitator, this is the place where the spec needs the most language, not the least.

A common error worth naming—building Variant 1 (structural fund) but giving an emergency-multisig override key “just in case.” The override key collapses the design back to Variant 2 in market terms, because the override exists and can therefore be priced in. If a structural fund is the intent, the override either does not exist, or it triggers a publicly-visible delay that itself makes the override expensive to use.

Execution Strategy: TWAP, Continuous, Batch, Dutch Auction

The execution strategy axis—how the buy orders are actually placed against the market—is where the three reference programs differ most visibly. The choice trades off across four properties: implementation complexity, MEV resistance, price predictability, and operational bandwidth.

Continuous execution is the HYPE pattern. Fees arrive, swaps execute, the fund balance grows. The operational simplicity is appealing—no scheduling, no discretion, no governance bandwidth required. The cost is permanent MEV exposure—every swap is visible in the mempool and sandwichable. Hyperliquid mitigates this partially by running the swaps inside its own venue rather than on an external DEX, which collapses the sandwich window. A protocol running continuous execution on a public DEX has a harder mitigation problem.

TWAP execution is the JTO pattern. A target volume is divided into N tranches, executed at fixed time intervals over a window. TWAP minimizes single-trade price impact and is straightforward to implement. The MEV exposure is medium—predictable timing means searchers can position around expected tranches, but each tranche is smaller and the per-trade sandwich profit is bounded. TWAP fits discrete buyback tranches where market-impact protection matters but real-time execution does not.

Batch execution is what JUP-style programs use when they deploy treasury tranches on a publicly-announced schedule. Each batch is an event with associated execution complexity, but predictability allows the team to use batch-auction infrastructure (CoW Protocol, Uniswap X) that bundles the buyback with other flow and protects against sandwich. The trade-off is governance bandwidth—each batch decision typically requires DAO approval.

Dutch auction execution is a separate primitive that has become relevant through priority-fee auctions (next section). Rather than placing orders into a continuous market, the protocol auctions the right to fulfill the buyback to bidders in a Dutch (descending-price) auction. The clearing price determines the rate, and MEV is internalized into the auction premium rather than extracted by external searchers. This is the most complex strategy and requires off-chain auction infrastructure, but the MEV resistance is structural rather than mitigative.

The decision tree for a new program is roughly—if fee inflow is continuous and a dedicated venue exists, use continuous; if fees are episodic, use TWAP; if execution requires governance approval per round, use batch with batch-auction infrastructure; if MEV exposure is the dominant cost and infrastructure investment is justified, evaluate Dutch auction.

Applied to JTO’s first run—target notional $1M, window 240 hours, 4 phases—the schedule resolves to four orders, $250k each, 60 hours apart:

def schedule_twap_buyback(target_notional_usd, window_hours, phases, venue):
    interval = window_hours * 3600 / phases
    per_phase = target_notional_usd / phases
    schedule = []
    for i in range(phases):
        schedule.append({
            "phase": i + 1,
            "execute_at_offset_sec": int(i * interval),
            "notional_usd": per_phase,
            "venue": venue,
            "slippage_cap_bps": 30,
            "private_mempool": True,
        })
    return schedule

# JTO first buyback as anchor
schedule = schedule_twap_buyback(
    target_notional_usd=1_000_000,
    window_hours=240,
    phases=4,
    venue="jupiter_aggregator",
)

For HYPE-specific volume sensitivity—including how volume shocks change the per-block buyback flow—the HYPE buyback sustainability calculator lets you move the inputs in real time.

Priority-Fee Auctions: A New Buyback Source

Priority-fee auctions emerged in 2025–2026 as a distinct deflationary primitive that does not fit the standard fee-funded buyback model. The pattern—users pay a premium for transaction ordering or latency advantage, the premium is auctioned (typically Dutch), and the proceeds are burned or otherwise removed from circulation. The source is not the protocol’s product fees but users’ willingness to pay for time priority.

Hyperliquid priority fees (mainnet alpha as of April 2026). Hyperliquid activated a two-tier priority-fee system—gossip priority, where bidders pay in HYPE via a Dutch auction (cycles synced to a 3-minute schedule, minimum 0.1 HYPE bid) to receive earlier visibility of incoming transaction data, and order priority, where users pay a fraction of filled notional (currently capped at ~8 bps, converted to HYPE from their undelegated staking balance) to bid ordering within the mempool. Both fee types are burned, making the system deflationary for HYPE supply; the docs do not separately specify the burn destination, but reporting treats both as flowing through the AF system address. Public reporting from Cryptointegrat, the Hyperliquid docs, and the Dwellir operator guide covers the mechanism in detail.

Arbitrum Timeboost (live since April 2025, dynamic reserve since 27 April 2026). Timeboost is an off-chain auction that sells “express lane” rights for 60-second windows. Winning bidders get their transactions sequenced ahead of standard flow during their window. The reserve price was static at launch and was switched to a dynamic reserve calculation on 27 April 2026—the reserve now adjusts based on recent demand, which means the auction extracts more value when latency is in demand. Auction proceeds flow to the Arbitrum DAO treasury rather than to burn. The mechanism is functionally analogous to Hyperliquid’s gossip priority—both auction latency advantage and internalize MEV value to the protocol—but the auction format differs: Timeboost is a sealed-bid second-price (Vickrey) auction, while Hyperliquid’s gossip priority is a Dutch (descending-price) auction. The two formats produce different bidder strategy and price-discovery profiles, even though the high-level revenue mechanism is the same. See the Arbitrum Timeboost introduction for the protocol-level mechanics.

Why this matters for buyback design—three points.

The source is orthogonal to trading volume. Trading fees scale with notional traded; priority-fee auction revenue scales with the demand for latency advantage in the order book. These are correlated but not identical—a market with high notional but low contestation (simple swaps) generates lots of trading fees and little priority-fee revenue. A market with lower notional but heavy MEV-extractable opportunities generates the opposite. A buyback design that relies on both is more diversified than one that relies on trading fees alone.

The auction internalizes MEV. Without priority-fee infrastructure, the value of being first in the order book is captured by external searchers via sandwich attacks, latency arbitrage, and frontrunning. The priority-fee auction redirects that value to the protocol, which can then deploy it to buyback or burn. Hyperliquid’s choice to burn priority-fee proceeds is a deliberate signal—the protocol prefers permanent supply removal over treasury accumulation for this revenue stream.

The design choice is burn vs accumulate vs distribute. Hyperliquid burns. Arbitrum directs to DAO treasury. A future design could distribute to validators (REV-style) or to stakers (slashing-adjacent). Each option produces different token-holder economics and is worth its own engineering analysis. As of early May 2026, the design space is still being explored across the major L1 / L2 / appchain stacks.

For a fee-funded buyback program, priority-fee auctions can serve as a secondary source that smooths the volatility of trading-fee revenue. The implementation surface is significant—an off-chain auction infrastructure, a routing path for auction proceeds, and either an on-chain burn or accumulation step. But the diversification benefit is real, and the primitive itself is new enough that early movers have meaningful design optionality.

Audit Checklist for Buyback Contracts

Existing buyback audit content—Mitosis University’s disclosures checklist is the closest reference—tends to focus on what protocols should disclose. The audit checklist below is for the contract surface itself, the code and configuration an auditor reads when reviewing a buyback program. It assumes the disclosure layer is separate work.

The checklist is not exhaustive—each program has specific surfaces (cross-chain bridging, multi-asset normalization, governance integration) that add items. But the ten above cover the failure modes that recur across HYPE-style, JUP-style, and JTO-style programs.

The next step for a real program is sequencing—pick the five axes, write the routing contract against the chosen variants, instrument the fee accounting on-chain, run the buyback once at small scale to verify reconciliation, and only then scale the allocation toward the target α. Building backward from a public launch number is how most programs end up with the wrong sink and a multisig override they cannot justify.