# Hard Rules Things we've bound ourselves to, in code, in process, or in public commitment, that protect the integrity of the token and the regulatory posture it depends on. These are not marketing promises. Each one has a concrete enforcement mechanism listed alongside. *** ## 1. Zirodelta never custodies ZDLT as collateral **The rule:** ZDLT is never deposited into a Zirodelta-controlled vault, smart contract, escrow, or off-chain wallet as collateral. Borrowing against ZDLT in Zidee Wallet routes through **Jupiter Offerbook**: a third-party, permissionless lending protocol that Zirodelta does not control. The collateral sits in Offerbook program PDAs on Solana; Zirodelta's treasury participates as a lender (counterparty), not as a custodian. **Why this preserves the spirit of the original rule:** * **No "own-token vault" systemic risk.** The Alameda / FTT pattern (2022) was a centralized actor holding its own token as collateral against borrowed customer funds, then having the token *and* the borrowed assets vaporize together when liquidity dried up. Offerbook PDAs are non-custodial and program-enforced: a Zirodelta-treasury insolvency does not touch borrower collateral, and a ZDLT price move does not propagate back into Zirodelta operating capital. The custody surface that made FTT systemic does not exist here. * **No ZDLT as margin in any Zirodelta product.** The DEX still rejects ZDLT as margin (separate code path). Automation strategies (Autopilot) still reject ZDLT as collateral. The denylist enforced in those code paths is unchanged. * **Regulatory posture stays clean.** Zirodelta acts as a permissionless lender on a third-party protocol, the same way any party can. The collateral relationship is between the borrower and the Offerbook program, not between the borrower and Zirodelta. **Enforcement:** * DEX collateral denylist still hard-rejects ZDLT (no change). * Autopilot policy gates still cannot accept ZDLT as collateral or margin (no change). * The current borrow flow routes through Offerbook's `create-collateral-offer` instruction; ZDLT never moves to a Zirodelta-controlled address. The Offerbook program is the custodian under Solana's program-execution model. * Any change that would introduce a Zirodelta-custodial ZDLT collateral path (e.g., a Zirodelta-deployed lending vault accepting ZDLT) requires a security-classification review before entering the roadmap. *** ## 2. Fair launch, no team allocation, no retained mint authority **The rule:** The team received zero ZDLT at launch. The mint authority and freeze authority were revoked on-chain immediately after supply was set. **Why:** This is the cleanest possible regulatory posture for a Solana SPL. No insider lockup to dump, no hidden mint risk, no ability to freeze your wallet. It also reinforces the "build in public" ethos: the team earns via pool fees and product revenue like everyone else, not via preferred allocation. **Enforcement:** On-chain. Verify `mintAuthority = null` and `freezeAuthority = null` on Solscan for mint `4PX31xRA1BaAyb2Js45ZKYp92VGWGp47yWeVs5CGVKbf`. These are irreversible. *** ## 3. No revenue share, no dividend, no proportional distribution **The rule:** Product revenue never flows back to holders as a proportional payment, in ZDLT or any other currency. The only revenue-funded benefit is buyback-and-burn (see [Tokenomics](/zdlt-token/tokenomics.md)). **Why:** Proportional distribution of revenue to token holders based on holdings is the textbook definition of a security in most jurisdictions (Howey test: investment of money, common enterprise, expectation of profits, from the efforts of others). Buyback-and-burn does not meet that test: holders benefit from scarcity, not from a direct payment. **Enforcement:** No "rewards contract," no staking emissions, no distribution code path exists anywhere in the Zirodelta stack. Any proposal that would introduce one requires a formal security-classification review before even entering the roadmap. *** ## 4. Burn cycles are publicly reconstructable end-to-end **The rule:** Every buyback-and-burn cycle must be fully traceable on-chain, from revenue accrual to final burn tx. If the chain isn't reconstructable, the cycle did not happen, and we owe a public post-mortem before the next cycle runs. **Why:** Trust in revenue-funded burn mechanics collapses the moment the "revenue → burn" link becomes opaque. We've seen this fail (see $JAIL in the public research doc: "a portion of fees" without a published % killed the credibility before the product did). **Enforcement:** Each cycle posts a thread in `#data` with: * Revenue figures (by source) * Opex deduction (with calculation method) * Bridge txs (if cross-chain revenue involved) * Buy tx on Meteora * Burn tx to the burn wallet Plus ongoing cumulative tracking on the burn dashboard (see tokenomics doc). *** ## 5. The 15% burn floor cannot be reduced; the acceleration ladder is immutable **The rule (floor):** The V1 15%-of-net-revenue buyback commitment is a floor. It **cannot be reduced under any circumstances**. No committee vote, no governance process, no public notice. The only direction it moves is up, via the milestone acceleration ladder. **The rule (ladder):** The FDV-milestone burn acceleration ladder published in [Tokenomics](/zdlt-token/tokenomics.md) is **immutable once the doc is live**. Milestones cross automatically when the 7-day TWAP crosses the threshold (subject to the minimum-volume floor). Neither the thresholds nor the burn shares at each step can be changed retroactively. **The rule (additions):** New, *higher* tiers can be added above the top tier (e.g., a $1B FDV → 55% step) with 30 days public notice. That's additive, not editing the existing ladder. Existing tiers stay fixed forever. **Why:** A buyback percentage that the team can change by fiat is a "soft commitment". Research across small-cap SPL tokens shows the market discounts soft commitments heavily. A starting floor that cannot be lowered + a pre-published ladder that cannot be edited is how we signal the difference between a hard mechanism and a marketing line. **Enforcement:** Milestone state is on-chain-verifiable (7-day TWAP of Meteora pool × 1B supply). Crossing a milestone requires no action from the team. The burn script reads the current tier from the on-chain state. Any attempt to run a cycle below the active tier's burn share = protocol violation, public post-mortem required. *** ## 6. Opex denominator is published monthly **The rule:** "Net revenue" means gross revenue minus operating expenses. The opex figure, how much we spent keeping the lights on, is published every month alongside the burn report. **Why:** Without this, "net" is a backdoor. A team that can define "net" however they want can buy back anything or nothing. Publishing opex makes the burn/opex split auditable by anyone who cares to read the numbers. **Enforcement:** Monthly burn thread includes the opex line. Missing month = protocol violation, public post-mortem required. *** ## 7. Treasury is locked until $11M market cap, and has use-rule commitments after **The rule (gate):** The 30M ZDLT treasury reserve is **locked until ZDLT's fully-diluted market cap reaches $11,000,000 USD**. Until that gate is crossed, **no ZDLT leaves the treasury wallet**, for any purpose: not liquidity, not bounties, not partnerships, not emergencies. **The rule (post-unlock):** Once the gate is crossed (one-way), the treasury is used only for: * Liquidity provisioning on new venues (CEX listings, bridged pools) * Partner and integration incentives * Community bounty payouts * Emergency reserves under publicly-announced extraordinary circumstances **The rule (negative, always):** The treasury never: * Funds team salaries (those come from pool fees and product revenue) * Dumps on the market in routine operations * Distributes to holders as "rewards" **Why the $11M gate:** At 1B fixed supply, $11M FDV = $0.011/token = \~$330K treasury value. That's the first scale at which the treasury becomes proportionate to the product. Pre-$11M, any reserve usage would be too large a % of real market depth, so we remove the team's ability to touch it. The lock is a commitment device: holders get a public, on-chain-verifiable guarantee that the team can't draw on reserves until the protocol has proven itself. **Enforcement:** Treasury wallet ([`EaJ4aEKCSJKiLvJMBUMXZcmJp4GFqR5w1B94Xgv17PoW`](https://solscan.io/account/EaJ4aEKCSJKiLvJMBUMXZcmJp4GFqR5w1B94Xgv17PoW)) is public. The lock is enforced socially + on-chain: any outflow before the $11M gate = protocol violation, public post-mortem, loss of credibility. Post-gate outflows remain reviewable on Solscan and require prior public announcement of intent. *** ## 8. Contract upgrade and governance constraints **The rule:** The SPL mint itself is immutable (can't be changed, it's a Solana SPL, not an upgradable program). Future on-chain governance or staking programs that are added will: * Ship behind a time-locked contract (minimum 30 days between deployment and activation). * Be audited by at least one reputable third party before activation. * Have opt-in-only interaction. No existing holder balance is touched without explicit user approval. **Why:** The base token is already non-mintable and non-freezable. Any additional contracts (staking locks, governance weight tracking) must inherit that safety posture: opt-in, audited, time-locked. *** ## Summary: what this means for you as a holder * **You cannot be rugged via the mint.** Supply is fixed forever. * **You cannot be frozen out.** No freeze authority exists. * **You won't wake up to a surprise revenue cut.** The 15% base rate cannot go down, ever. The milestone ladder cannot be edited. * **You can verify every claim on-chain.** Mint authority, freeze authority, treasury balance, burn address, burn txs, all on Solscan. * **We can't quietly pivot to "yield" mechanics.** Adding them requires formal review and public process. The entire tokenomics design depends on these rules staying intact. Breaking any of them breaks the deal. --- # 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/hard-rules.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.