Rebases on LEASH v1 are still being triggered, but our job is to protect holders and deliver a smooth, verifiable migration to LEASH v2.

After coordination with exchanges and a technical review of how rebases complicate liquidity accounting (especially on Uniswap V3/ShibaSwap V2), we’re aligning execution to a ratio‑based migration that preserves holder‑equivalence, while still using targeted snapshots where they’re technically necessary.

Held = whole. Sold = reduced. Sold out = zero (unless you rebuy).
We do this with a single ratio R = S₀ / S₁, where S₀ is the intended/original supply and S₁ is the current total supply of LEASH v1.

Why not a global snapshot for every case?

A system‑wide, pre‑rebase snapshot is principled, but exchanges cannot safely “rewind” order books to reassign pre‑event balances to different current customers (trade finality, accounting, compliance).
However, some subsystems require snapshots to be fair—notably Uniswap V3/ShibaSwap V2 LP positions, where rebases don’t accrue to LP shares and can leave extra tokens trapped in pools.

Bottom line: we’re not abandoning snapshots; we’re using them surgically where they’re the correct tool (e.g., V3/V2 LPs), and using the ratio model elsewhere to keep venues compatible and users included.

Holder‑equivalence (ratio) in one minute

• S₀ = intended/original supply
• S₁ = current total supply of LEASH v1
• R = S₀ / S₁

During migration, each account’s LEASH v1 converts to LEASH v2 = current_balance × R.

Example (R = 2/3):

• Had 10 and never sold; later wallet shows 15 post‑rebases → 15 × 2/3 = 10 (made whole).
• Had 10, after rebase 15. Sold down to 5 -> 5 x 2/3 =3.333 (reduced because you sold 10 which is 10 x 2/3 =6.667) hence lost in selling
• Sold out → 0 × 2/3 = 0 (nothing unless you rebuy).

Centralized exchanges: reality check

Exchange engagement has been slow (or none at all for some venues). Negotiations are the long pole; they take longer than engineering. Even with a venue‑friendly plan, there is no guarantee any given exchange will support the migration.

One exchange told us their evaluation could result in any of the following:

1. Token swap not supported and the old token delisted
2. Token swap not supported
3. Token swap supported, but the new token will not be listed
4. Token swap supported and the new token will be listed

A special shout‑out to Crypto.com and Gate.io for being exceptionally diligent and helpful during reviews and integration planning.

Our side: We’ll provide the public ratio R, contract addresses, and test vectors; ask venues for a short signed attestationif they apply R; maintain a public venue dashboard; and offer a self‑custody portal for users whose venue doesn’t participate.

Migration plan (phased; targeted snapshots where needed)

Phase 1 — Normal migration (holders, stakers, UniV2/ShibaSwap V1 LPs)

• Deposit LEASH v1 → receive LEASH v2 = current_balance × R (v1 locked/burned).
• xLEASH / veLEASH / Metaverse Lock: Unstake/unlock → migrate here.
  • veLEASH withdrawal penalties are removed during the incident window.

Phase 2 — Uniswap V3 / ShibaSwap V2 LPs (uses snapshots)

Rebases don’t flow to V3 LP shares, so we avoid trapped value by either:

• Direct migrator: Approve a migrator; burn LP NFT; compute withdrawable v1; mint v2, or
• Old liquidity snapshot + Proof‑of‑withdrawal (recommended): LP withdraws, proves the actual v1 received, we mint v2 = withdrawn × R.

Phase 3 — Bridged holders (official Shibarium & others)

• Bridged balances migrate by the same ratio via an L1/L2‑aware flow coordinated with bridge operators.

What this means for you

• Held through, didn’t sell: effectively whole after conversion.
• Sold some: reduced proportional to what you kept.
• Sold out: 0 unless you rebuy.
• Post‑rebase buyers: included (scaled by the same ratio).
• Stakers/lockers: Unstake/unlock → migrate in Phase 1.
• V3 LPs: wait for the Phase 2 guide; targeted snapshots will be used to ensure fair accounting.
• CEX users: if your venue participates, no action needed; if not, withdraw and use the portal.

LEASH v2 – Development Update (Token Design, Migrator, and Audit Plan)

TL;DR

• We explored FHE features for LEASH v2. After discussing with Rand, the right path is to keep the base token simple now and wrap it later under the confidential‑token standard he’s developing with OpenZeppelin.
• Token contract: plain ERC20 with ERC20Permit and ERC20Burnable, implemented with OpenZeppelin. This keeps the code minimal and battle‑tested. We’ll still run a combined audit (token + migrator) with our audit company.
• Migrator contract: designed so it cannot mint. We will pre‑mint the full LEASH v2 supply to a multisig, and the migrator will only transfer from that multisig (via allowances) after users migrate. This removes any lingering doubt about supply manipulation.
• Endgame: After migration slows down, any unclaimed v2 left in the multisig can be burned (reducing total supply). The DAO will decide whether we set a migration cutoff date or keep it open‑ended.

1) Token: simple now, private wrapper later

• We evaluated whether v2 should ship with FHE (Fully Homomorphic Encryption) features out of the gate.
• Per guidance from Rand, a simple ERC‑20 can later be wrapped into a confidential token using the new standardhe’s working on with OpenZeppelin.
• Therefore, LEASH v2 will launch as:
  • ERC20 (no rebase, no upgradeable proxy)
  • ERC20Permit
  • ERC20Burnable (for explicit burns, including the post‑migration burn of any unclaimed supply)
  • Implemented with OpenZeppelin libraries
• Using these audited, widely used components reduces incremental risk. We’ll still commission a full audit of the integrated system (token + migrator) to be safe and to satisfy venues.

2) Migrator: no mint powers, transfers only

Goals: transparency, minimal trust, no “hidden levers.”

How it works (ratio model):

1. v2 total supply is pre‑minted at deployment and held by a multisig.
2. The migrator contract cannot mint and holds no v2.
3. When a user migrates (e.g., deposits/burns LEASH v1 per the flow), the migrator:
   • Verifies the user’s v1 amount, applies the public ratio R = S₀ / S₁,
   • Uses an allowance from the multisig to transfer the corresponding v2 to the user.
4. Result: the migrator never creates new v2; it only moves pre‑minted tokens out of the multisig as users migrate.

Why this matters

• No contract in the system (other than the one‑time pre‑mint) can expand supply.
• The path to distribute v2 is explicit and observable: user action → migrator calculation → transferFrom(multisig) to user.
• At the end, the multisig’s remaining v2 (if any) can be provably burned.

3) Audit plan

• Even though the token relies on OpenZeppelin standards, we will still audit the full system (token + migrator, plus any LP/bridge adapters used in Phases 2–3).
• Scope will include: ratio math, allowance patterns, burn/lock logic for v1, and the post‑migration burn procedurefor remaining v2 in the multisig.
• We’ll publish the auditor selection and scope summary next.

4) Post‑migration burn & cutoff (needs DAO input)

• Burn of leftovers: After a reasonable period, any v2 remaining in the multisig (unclaimed/unused) can be burned, lowering the supply.
• Cutoff vs. open‑ended:
  • With a cutoff (e.g., 90–180 days): Faster closure, easier exchange/analytics onboarding; risk that some holders miss the window.
  • Open‑ended: Maximally inclusive; slower convergence; exchanges may prefer a clear end date.
• We’ll present this as a DAO parameter to finalize.

5) How this fits the broader plan

• Targeted snapshots remain for Uniswap V3/ShibaSwap V2 LPs (to fairly capture withdrawable v1 via Old liquidity snapshot + Proof‑of‑withdrawal).
• Everywhere else, we continue with holder‑equivalence via a single ratio R (Held = whole; Sold = reduced; Sold out = zero unless you rebuy).
• The migrator’s “no mint” design reinforces the message that v2 supply cannot be manipulated in the future.

Verifiability

We will publish the core parameters and keep a concise public record of what was applied when.

Closing

This approach combines the best of both worlds: ratio‑based holder‑equivalence for broad compatibility and inclusion, and targeted snapshots where they’re technically required (like V3/V2 LPs). It honors long‑term holders, naturally reduces sellers, remains auditable, and gives venues a viable way to support you—while development progresses with a simple, auditable token, a non‑minting migrator, and an external audit of the whole system.