# Tokenomics > **Version: V1** (live at launch). Candidate upgrades V2 and V3 are scoped below in the [Versioned roadmap](#versioned-roadmap). Each version ships only when its objective activation condition is met. The design is deliberately simple: **all revenue-funded benefit to ZDLT flows through one mechanism: buyback and burn. No distribution, no yield, no staking rewards, no dividend.** Supply only shrinks. This page explains where the fuel comes from, how much of it feeds the burn, and how we tell you it happened. *** ## Revenue pipeline Zirodelta earns revenue from three independent sources. All of them eventually feed the buyback-and-burn pipe, though they arrive in different currencies and on different cadences. ### 1. Meteora pool 0.5% tx fee Every swap in the ZDLT/SOL Meteora DLMM pool pays 0.5% to the team wallet, split across both buys and sells. This is the most direct pipe: trading in ZDLT itself funds ZDLT burns. * **Currency:** SOL or ZDLT (depending on swap direction) * **Cadence:** Accrues per-swap; harvested to treasury monthly ### 2. Hyperliquid builder fees The Zirodelta DEX, Zidee Wallet, and Automation strategies all route user trades through Hyperliquid with a builder-fee approval. That fee (variable %, set per surface) flows to Zirodelta's HL wallet. * **Currency:** USDC on Hyperliquid * **Cadence:** Continuous; batched + bridged to Solana monthly or quarterly depending on size ### 3. Pro tier subscriptions When enabled on a product (currently Automation strategies, later DEX pro features), monthly subscription fees from tier-gated users. * **Currency:** USDC or ZDLT (if paid in ZDLT, the paid-in tokens route directly to burn) * **Cadence:** Monthly *** ## The buyback-and-burn mechanism ### The commitment (V1 launch) **15% of net revenue across all three streams, every cycle, buys ZDLT from the Meteora pool and sends it to a public burn address.** * The starting percentage is **fixed at 15% and cannot be reduced**. It can only increase, automatically, via the milestone acceleration ladder below. * Any decrease to the base rate, or any change to the ladder's milestones, requires **30 days public notice** and an on-chain governance post before taking effect. * "Net revenue" means gross revenue minus opex. The opex calculation is published every cycle alongside the burn so the denominator is never opaque. * Remaining 85% funds operations: infra, salaries, security audits, growth, reserves. ### Burn-rate milestone acceleration ladder 15% is the floor, not the ceiling. As ZDLT grows, the burn share ratchets up automatically along a public, pre-committed ladder. Each step is **one-way**: crossed once, it locks in permanently; the protocol cannot walk back to a lower burn share. | FDV milestone | Burn share | Opex share | | ------------- | ---------- | ---------- | | Launch → $15M | **15%** | 85% | | $15M FDV | **20%** | 80% | | $50M FDV | **30%** | 70% | | $150M FDV | **40%** | 60% | | $500M FDV | **50%** | 50% | FDV = fully diluted valuation = time-averaged Meteora pool price × 1,000,000,000 (total supply). Trigger uses a **7-day TWAP** and a **minimum-volume floor** to block single-block pool manipulation from tripping the threshold artificially. Why a ladder instead of a static rate: at sub-PMF scale, 15% is the right number. Ops need 85% of revenue to get the protocol to the next milestone. At $150M FDV, the math inverts: the product has proven itself, ops are well-funded, and holders deserve a larger share of revenue flowing back to scarcity. The ladder bakes that dynamic into code so no committee vote is ever needed to tighten the burn as growth compounds. Same philosophy as the $11M treasury unlock gate: **commitment devices, not discretion.** The team loses the option to under-burn at scale, and in exchange gets to under-promise at launch. ### Cadence: honest about scale At today's revenue (\~$500/mo team fees target + early HL builder fees + negligible subscriptions), **15% of net revenue is a very small absolute dollar figure**. Weekly buybacks at this size would get eaten by bridge fees ($5-20/hop) and move the pool in ways bots can front-run. Cadence tiers: | Monthly net revenue | Burn cadence | | ------------------- | --------------------------------------------------------------------------------- | | < $1,000 | **Quarterly** (batched, one big tx per quarter) | | $1,000 - $10,000 | **Monthly** | | $10,000 - $100,000 | **Bi-weekly** | | > $100,000 | **Weekly, probabilistic timing** (anti-front-run, à la pump.fun Tokenized Agents) | This is not hedged. Each threshold triggers the next cadence automatically. No committee vote, no discretion. ### Execution flow Every buyback cycle follows the same script: 1. **Accrue**: revenue accumulates in wallets (team wallet on Solana for pool fees, HL wallet for builder fees, Stripe/HL for subs). 2. **Bridge**: non-Solana revenue bridged to Solana via established routes (Wormhole / deBridge / Portal). Bridge tx hashes published. 3. **Compute**: the current milestone tier's burn share × net revenue, converted to SOL for pool execution. 4. **Buy**: SOL → ZDLT on Meteora DLMM. Buy tx posted publicly. 5. **Burn**: bought ZDLT sent to the burn address (`11111111111111111111111111111111` or a purpose-generated burn wallet). Burn tx posted publicly. 6. **Publish**: the full set (revenue, opex, bridge, buy, burn) posted as a single thread in `#data` on Discord and logged to the public burn dashboard. Any cycle where the chain from revenue-accrual to burn-tx is not fully reconstructable on-chain **did not happen**. If we can't prove it, it doesn't count. ### Burn address A single, purpose-created Solana wallet with its private key destroyed (Pedersen-style, public proof of destruction) will be used as the burn destination. * Address: *to be published on execution of the first buyback cycle* * Anyone can query cumulative ZDLT burned by reading this wallet's balance on Solscan. *** ## Transparency dashboard (committed, to be built) A public page at `docs.zirodelta.com/zdlt-token/burn-dashboard` will display: * **Cumulative ZDLT burned** (+ percentage of total supply) * **Cumulative USD value of buybacks** * **Monthly burn log**: each cycle with tx hash, USD spent, ZDLT bought, ZDLT burned, revenue source breakdown * **Current cadence tier** (which threshold the project sits in) * **Current burn tier** (which milestone bracket is active, FDV reading, TWAP window used) * **Runway / opex transparency**: monthly opex figure so the burn/opex split is auditable **No fixed launch date.** The first burn cycle fires only once Zirodelta products have found product-market fit and are generating enough revenue for a non-trivial buyback. Committing to a calendar target before the underlying revenue exists would be cosplay. The public research on sub-scale SPL tokens (see `$JAIL` case: mechanism promised, product never hit PMF, token went -99.9%) is clear about what that does to credibility. The dashboard ships the day of the first cycle, not before. *** ## Versioned roadmap The design evolves in explicit versions. Each version ships only when the activation condition is met. No premature complexity, no cosplay. Current and candidate versions: | Version | Status | Activation condition | What it adds | | ------- | ------------------ | --------------------------------------------------------------------- | -------------------------------------------------------------------------- | | **V1** | **Live at launch** | (none) | 15% base burn + FDV milestone ladder + per-cycle burn thread + public opex | | **V2** | Candidate | Monthly revenue ≥ $100K | Continuous streaming buybacks | | **V3** | Candidate | Monthly revenue ≥ $10K **AND** Meteora DLMM format stable ≥ 12 months | POL (protocol-owned liquidity) sub-allocation | Versions are additive. V2 does not replace V1, it layers on top. Activation conditions are objective and publicly-verifiable; when both conditions are met, the respective version ships with a formal spec PR + 30-day review window. Nothing auto-deploys without community notice. *** ### V2 candidate: Streaming execution at scale **Activation:** monthly revenue clears \~$100K (around the time the ladder hits its $150M FDV step). Batch monthly buybacks stop being the right cadence at this scale: they're predictable and front-runnable. V2 explores **continuous streaming buybacks** (à la Superfluid / Sablier), paying out on a per-block basis as revenue arrives. On-chain verifiable in real time; zero batch timing to exploit. **Risk:** Solana-side streaming requires bridge-revenue-to-stream infra that's moderately novel. Not worth building before the revenue justifies it. *** ### V3 candidate: POL (Protocol-Owned Liquidity) sub-allocation **Activation:** two conditions. Monthly revenue ≥ $10K, **AND** Meteora's DLMM pool format has remained stable for ≥ 12 months (so migration risk on locked LP positions is quantifiable). Inside the cycle's burn allocation (not touching the opex split), a portion goes to seeding a permanently-locked LP position in the ZDLT/SOL Meteora pool instead of straight-to-burn. The LP is held in the burn wallet, cannot be withdrawn, and its continuously-earned 0.5% Meteora swap fees automatically compound into further burns. Proposed sub-allocation ladder (inside the burn allocation, not the 15%/85% split): | Monthly revenue | Straight-to-burn | To locked POL | | --------------- | ---------------- | ------------- | | < $10K | 100% | 0% | | $10K - $100K | 70% | 30% | | > $100K | 50% | 50% | **What it solves:** compounding burns from trade volume alone, plus deeper pool depth (lower slippage for everyone trading ZDLT). **Risks:** * **Meteora migration risk.** If the DLMM format is deprecated, the locked LP is stranded. Mitigation: the 12-month format-stability activation condition is specifically to shrink this risk envelope. * **Complexity in the story.** Adds a layer to the "buyback-and-burn" pitch. We'd split the doc so the V1 story stays clean for newcomers. * **Olympus precedent (partial).** OlympusDAO locked 99%+ of its liquidity successfully, but narrative-collapsed from the *bonding* side (discounted token sales). We don't bond. POL would be funded from operating revenue, never from discounted issuance. The POL mechanic itself isn't the cautionary; the bonding was. *** ## What we won't do * **No "staking for yield".** Staking mechanics that distribute revenue, even denominated in ZDLT, are regulatory security traps. See `hard-rules.md`. * **No weekly buyback promises at sub-$10K revenue.** Cosplay cadence destroys credibility (see the $JAIL post-mortem in public research). We'd rather under-promise and scale up than the reverse. * **No discretionary skipping of burns.** If the rule says burn, we burn. If we didn't, we owe a public post-mortem before the next cycle. * **No opaque "net". The opex denominator is published.** Without that, "net revenue" is a backdoor. *** ## Why the value accrual is real When a holder asks *"why should ZDLT go up?"* the answer isn't "because more buyers." The answer is: * **Fixed supply** (1B, cannot be inflated) * **Minus a committed, monotonically-increasing burn stream** (15% at launch, ladders up to 50% as FDV grows; both the base rate and the ladder are one-way commitments) * **Times demand from Discord tier access + future product-level utility** (see `utility.md`) That's a structural accrual narrative, not a speculation narrative. Speculators are welcome (the mechanics don't care why you hold), but the floor is defensible in numbers. *** ## Risks (honest) * **Revenue risk.** If Zirodelta products don't earn, the burn stream is small. Tokenomics cannot save a dead product. See the `$JAIL` case study: mechanism existed, product didn't find PMF, token went -99.9%. * **Bridge risk.** Cross-chain revenue bridging has occasionally failed catastrophically (Ronin, Nomad, Wormhole exploits). We mitigate by batching and using multiple well-audited routes, but this is a real attack surface. * **Meteora depth.** Buybacks on thin liquidity move the pool. The probabilistic-timing execution model (triggered at >$10K/mo cadence) is specifically to reduce predictable front-run patterns. * **Regulatory.** We operate on the theory that a pure-utility, no-distribution, fair-launched, no-team-allocation token is defensible. That theory is not tested in every jurisdiction. Holders should understand local regulatory posture. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.zirodelta.com/zdlt-token/tokenomics.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.