🚨 LEASH Investigation – How Supply Changed Despite “Renounced” Claims

TL;DR

• On August 11, 2025 the LEASH total supply increased ~10% (≈10,765 tokens) despite years of messaging that supply was fixed and rebasing was disabled.
• The cause was a still‑wired rebase pathway (via pre‑authorized contracts) that survived ownership renouncement and continued to function.
• From the outside, the system looked decentralized (owner addresses renounced), but functional control over supply adjustments remained through an orchestrated contract chain.
• Two paths forward will be proposed to the LEASH DAO: (A) negotiate with the original developer (historically unsuccessful), or (B) launch LEASH v2 on a new, audited, non‑rebase contract—subject to DAO approval.

Why we’re publishing this

We owe the community a full accounting of what happened, how it was possible, the risks going forward, and concrete, DAO‑led options. Working in a chaotic system with multiple historical owners and inherited code paths is exhausting to keep aligned; this report is one step toward clarity, integrity, and collectively setting the future direction. Also before beginning i would like to clarify this is 2020 stuff even before 99% of the folks joined.

What is a “rebase” (in plain English)?

A rebase is an elastic‑supply mechanism where the total supply of a token automatically expands or contracts based on rules or triggers (e.g., daily, or when price deviates from a target). When a positive rebase happens, every holder’s balance increases proportionally; when a negative rebase happens, balances decrease proportionally. Your percentage ownership stays roughly the same, but the absolute number of tokens you hold changes. Rebases can:

• Alter market cap and per‑token price math, sometimes confusing explorers and dashboards.
• Be neutral to individual percentage ownership in theory, but still impact perception, liquidity, and integrations.
• Be misused if control of the rebase trigger isn’t transparently and irreversibly disabled.

Key misconception: “Owner renounced = no more supply changes.” Not necessarily. If the contract allows non‑owner roles (e.g., a monetary policy address or orchestrator) to call rebase, renouncing owner alonedoes not turn those pathways off.

What we observed on August 11, 2025

• Time/Block: 18:55 UTC, Block 23,119,734
• Supply change: ≈ 107,646 → 118,411 LEASH (~+10%)
• No obvious “owner” call. The change occurred via internal calls through pre‑authorized contracts.

This was the first material supply move in a long time, directly contradicting “fixed supply” assumptions.

How a “renounced” system still changed supply

High‑level architecture (simplified):

[User wallets]
     ↑  (balances scale when rebase occurs)
[LEASH Token]
     ↑  (accepts rebase from policy)
[Monetary Policy]
     ↑  (invoked by)
[Orchestrator / Proxy Callers (whitelisted beforehand)]

• Token contract: Contains rebase() logic inherited from elastic‑supply patterns.
• Monetary policy: The only address/contract allowed to call rebase().
• Orchestrator / proxies: Pre‑authorized callers that can trigger the policy.
• Ownership renounced across these contracts did not unset or disable the pre‑authorizations; they remained live.

Why this matters: The system appeared trustless (no owner), yet a functional ability to change supply persisted through roles that were configured before renouncement and couldn’t be changed afterwards.

What likely happened (and why it’s deceptive)

• The prior developer publicly claimed keys were “burned” and that rebasing was “permanently disabled”.
• In reality, the contract graph kept a hidden‑in‑plain‑sight control path: pre‑authorized orchestrators/proxies still able to trigger rebases under certain conditions (e.g., time windows, daily frequency gates, etc.).
• From the outside: owner = 0x00 across contracts ⇒ looks decentralized.
• Functionally: rebase still callable by non‑owner authorized callers ⇒ supply can change.

We’re choosing careful language here: these are on‑chain observations. They strongly suggest deliberate design to preserve de facto control while presenting a renounced/immutable surface.

Impact on holders and integrators

• Your percentage share of the network is intended to remain the same after a rebase, but
• Absolute token counts change, affecting:
  • Explorers/analytics (supply, FDV, APYs, emissions assumptions)
  • Liquidity math (pool balances, price per token optics)
  • Trust: A “fixed‑supply” narrative is no longer credible under the current v1 contract graph.

Governance‑led options from here

We cannot retroactively fix decisions made in the past or alter renounced contracts. The choices ahead are community decisions. We propose two concrete paths for DAO consideration:

Option A — Attempt negotiation with the previous developer

• Goal: Obtain a public commitment to never trigger again and/or to provably disable the remaining pathway.
• Reality check: This has failed before (including attempts by Ryoshi). Expectations should be low.

Option B — Launch LEASH v2 (new, audited, non‑rebase contract)

• DAO vote required. If the community approves, v2 would be a fresh deployment with:
  • No rebase code (plain ERC‑20), no upgradable proxy, no backdoor roles
  • Immutable supply set at genesis; clear, minimal roles gated by a multisig + timelock
  • Open‑source code, third‑party audits, formal verification where feasible
  • Community wishlist features (to be discussed): e.g., permit signatures (EIP‑2612), native claim/migration helpers, fee‑less meta‑tx relays, or other utility the DAO prefers
  • This is a major undertaking on it's own not to be taken lightly as also have to work with exchanges for this to work well.
• Tentative migration sketch (if approved):
  1. Snapshot LEASH v1 balances at a publicly announced block height
  2. Deploy LEASH v2 (audited) and a claim portal (1:1 or DAO‑selected ratio)
  3. Liquidity migration plan (in coordination with major pools)
  4. Clear deprecation guidance for v1 (no endorsements, disclaimers)
  5. Ongoing monitoring and post‑mortem transparency

Important: The team will not unilaterally decide this. A formal LEASH DAO proposal with timelines, audits, and an implementation plan will be published for community vote.

Risk disclosures & lessons

• Renounce ≠ immutable: If powerful functions are delegated to non‑owner roles, renouncing owner doesn’t remove those powers.
• Design for verifiability: Prefer simple, frozen logic with no external policy hooks for assets marketed as “fixed supply”.
• Audits and diagrams matter: Demand a role map (who can call what) and a call graph (how calls propagate). If it’s not trivial to explain in one page, it’s too complex for a “fixed supply” claim.

Frequently asked questions (FAQ)

Q: Did someone “steal” my tokens?
No. A rebase changes the total supply and scales everyone’s balances proportionally. The concern is governance/control, not direct balance theft.

Q: Can this happen again on v1?
If the same pre‑authorized pathway remains live, yes. That’s why Option B focuses on moving to v2.

Q: What happens to LEASH v1 if v2 launches?
The DAO will define migration terms. Typically, v1 remains on‑chain but is deprecated by the project (documentation and UI make this clear). Liquidity and utility would shift to v2.

Q: Is there legal exposure?
We are avoiding personal accusations and sticking to on‑chain evidence. Any further steps involving individuals would require counsel.

Personal note

Dealing with a chaotic system with multiple owners and inherited, deceptive structures has been exhausting for me to keep aligned and safe for the community. I’m committed to transparency and putting these decisions in the hands of the DAO.

Next steps

• Publish a DAO proposal outlining Option A/B with specifics (audit scope, timelines, migration details) for a formal vote.
• Release a public evidence pack (TXs, contracts, call traces) so anyone can verify claims on‑chain.