LEASH v2 – Unified DAO Proposal & Community Blog

TL;DR

• LEASH v1’s supply was increased through a still-active rebase pathway despite apparent ownership renouncement, causing ~20%+ dilution from the ~107,646 baseline.
• Proposal: Migrate to LEASH v2, a fixed-supply, audited token, using the last trusted pre-rebase snapshot with fairness filters.
• No free airdrop: v2 will be a burn-to-claim swap—you must burn v1 to claim v2.
• xLEASH / veLEASH and Metaverse Lock stakers: Must unstake/unlock and burn-to-claim.
• Shibarium bridge users: Will be handled separately.
• LP providers: Policy to be announced.

Proposal Link

You need ERC20 Leash one ETHEREUM to vote on this proposal:

Doggy DAO: Empowering Shiba Inu Utility Crypto Governance

Join Doggy DAO to shape the future of Shiba Inu’s ecosystem. Harness community-driven governance for real utility in the crypto landscape today.

Context & Accountability

Short version: the rebase pathway and contract wiring that enabled supply changes were created before the current team. I was not consulted on those choices. A former developer later claimed a wallet hack; we cannot verify that. What we can verify on‑chain looks like the work of someone with deep, specific knowledge of the LEASH monetary policy path.

What we can prove (on‑chain facts)

• The token honored rebase calls through a pre‑authorized policy/orchestrator path that remained valid after “renounce”.
• Supply changes occurred via that path, not via the owner role.
• The caller(s) executed the correct sequence against the correct contracts/parameters — behavior consistent with insider‑level familiarity with how this system was wired pre‑renounce.

What we cannot prove

• We cannot independently verify the hack claim. No conclusive forensic evidence has been produced to us that links a compromise to the rebase transactions.
• We do not have reliable, attributable identities for historical participants; most were pseudonymous.

Why this keeps happening in Shib

• Leaders (including those with real skin in the game) can and have left at any time, often without full handover. When they do, they leave the mess to clean up and it is our "responsibility" to carry it forward
• Decision rights and operational knowledge get fragmented across anons. Years later, the people who remain (in this case, me and the current team) are left to triage past mistakes and their downstream effects.
• We tried to create order in this chaos for everyone with proper structures but seems like those kind of initiatives not digested well and are called centralized by same people who are custodians of Shib assets and they use those assets to fill their own pockets.

How we’ll handle accountability

• We will stick to verifiable facts and publish an evidence pack (tx hashes, block numbers, function traces, supply diffs) alongside this process.
• We will avoid personal accusations in public forums. If warranted, we will engage counsel and relevant venues with evidence.
• Our focus is forward‑looking: remove the lever, restore predictable supply, and make sure this cannot recur in v2.

Guardrails for v2 (WIP)

• No rebase logic. Plain ERC‑20 with fixed supply.
• Least privilege governance: multisig + timelock; narrowly scoped permissions; scheduled renounce/sunset where possible.
• Audit(s)
• Public runbooks for any sensitive ops; on‑chain proofs for all distribution steps (Merkle roots, proofs, checksums).
• Monitoring & transparency: publish supply metrics, contract configs, and change logs so the community can audit in real time.

Plain‑language takeaway: the past left us with a hidden lever and no reliable owner to call to account. We can’t change that history, but we can remove the lever, prove the fix, and migrate together under rules the DAO approves.

Why This Matters

• Integrity: We can’t stop future rebases on v1.
• Trust: Unpredictable supply damages listings, analytics, and confidence.
• Holders: While percentage share per rebase may stay the same, total supply changes matter.

Options Considered

Option A — Pre-Rebase Snapshot (Recommended)

• Pros: Reverses unauthorized dilution; strongest ethical stance; protects long-term holders; sets clear precedent against manipulation.
• Cons: Post-rebase buyers may feel penalized; some CEX reconciliation complexity; requires careful messaging.

Option B — Current State Migration

• Pros: Simplest operationally; minimum friction for CEXs/DEXs; no immediate losers.
• Cons: Legitimizes manipulation; long-term holders remain diluted; damages trust.

Option C — Pro-Rata Reduction to Original Supply

• Pros: Equal percentage treatment; mathematically returns supply to intended cap.
• Cons: Punishes good and bad actors alike; ignores injustice; complex to communicate.

Option D — Hybrid with Penalties

• Pros: Maximizes fairness and deterrence; acknowledges different behaviors.
• Cons: High classification complexity; potential appeals volume; legal/PR risks.

This proposal recommends Option A with a Hybrid Fairness Layer and a burn-to-claim swap.

Snapshot & Allocation Policy

• Baseline Snapshot Block: Last block before first unauthorized rebase.
• Eligible: All addresses with positive LEASH balance at baseline.
• Filters:
  • Exclude only-post-rebase buyers.
  • Exclude sellers after announce block.
  • Include continuous LPs from before rebase through announcement, weighted.
  • Grace Window: Block REBASE_BLOCK → REBASE_BLOCK + X hours.
    • Purchases < X LEASH: Included.
    • Purchases > X LEASH: Excluded.
    • Sales: Neutral.
• Special Groups:
  • xLEASH / veLEASH + Metaverse Lock: Must unstake/unlock then burn-to-claim.
  • Shibarium bridge users: Separate process.
  • LP providers: Policy forthcoming.

Exchange & Custody Playbook

CEX Custody Allocation is Risky:

• Require user balance snapshot at baseline.
• Require cryptographic proof from custody wallet.
• Require public commitment to proportional distribution.
• Without compliance, no custodial allocation—users self-claim.

Verifiability & Appeals

We’ll publish:

• balances_pre_rebase.csv
• activity_after_rebase.csv
• eligibility_tags.csv
• airdrop_allocations.csv
• merkle.json + proofs
• Reproducible Docker toolchain

Appeals:

• Duration: TBD days.
• Categories: CEX user, LP, bridge user, staker/locker, other.
• Required docs per category.
• Public log of decisions.

Burn-to-Claim Mechanics

• Eligibility: Snapshot + fairness filters.
• Claim: Burn v1 (up to eligible amount) to mint v2.
• Selling after announce doesn’t help—you must rebuy v1 to claim.

Migration Steps

1. DAO Vote Approves Policy & Parameters.
2. Run Snapshot Pipeline; publish preliminary eligibility.
3. Appeals Window.
4. Finalize Allocations; publish Merkle root + proofs.
5. Development + audit
6. Open Claim Portal (burn-to-claim).
7. Liquidity migration + incentives.
8. CEX coordination.
9. Bridge freezes + handling.

Personal Note

This has been exhausting. In a chaotic, decentralized system, those who remain bear the weight of past mistakes. I’m committed to resolving this transparently, fairly, and with the DAO deciding the path forward.