Dual-Cycle Vault Protocol

01 Protocol Summary

Zimu Protocol turns Meme-token trading behavior, tax cash flow, curve-based reward release, reserve constraints, buyback burn accounting, and secondary-market routing into one on-chain vault system. The Mother Token is the entry asset, the Child Token is the curve-release asset, and the Vault is the accounting and reserve center.

02 Problem: Meme Liquidity Exhaustion

Traditional Meme assets depend heavily on early attention and external liquidity. Tax routing, marketing reserves, buyback narratives, and secondary markets are often separated, making it difficult for users to understand the relationship between real reserves, sellable capacity, and token supply.

03 Design Goal: Dual-Cycle Vault

The protocol is designed around two loops. The first loop routes Mother Tax into Child Curve Rewards. The second loop routes Child Sell fees into Mother Buyback & Burn. Both loops share one vault accounting layer while keeping market trading and reserve redemption boundaries explicit.

04 Mother Token Layer

• Mother-token trading tax is fixed at 3%.
• 10% of collected tax enters the early marketing reserve.
• 90% of collected tax enters Child curve mint / Child reward accounting.
• Only holders with at least 500,000 MOTHER enter the reward share set.
• The creator has no identity privilege and only participates through eligible holding share.

05 Child Curve Layer

The Child Token is released by the vault curve. The Stage 1 cap is 100,000 CHILD, with a maximum expandable cap of 300,000 CHILD. Curve price rises by tier. Earlier participants are positioned closer to the front of the curve, but curve price is not a fixed-yield promise.

• 10,000 CHILD average price: 0.0320U.
• 50,000 CHILD average price: 0.1419U.
• 100,000 CHILD average price: 0.6278U.
• Last 10,000 CHILD marginal price: 2.1376U.

06 Vault Reserve Layer

Vault Reserve defines sellable capacity. Pending mint BNB, sellable reserve BNB, buyback reserve BNB, marketing reserve, reward Child, burned Mother, and related values must be treated as on-chain accounting. Live contract state and Flap Taxinfo are the source of truth.

07 Sell / Burn / Buyback

When a user sells Child, the sold Child is burned, 90% BNB is returned to the user, and 10% BNB enters the Mother buyback-and-burn path. The dashboard separates BNB spent on buyback from the amount of Mother tokens actually burned.

08 PancakeSwap Infinity / Hook Layer

PancakeSwap Infinity acts as the secondary-market layer for Child-token trading and liquidity. The current architecture is Hook-ready / Hook-extension ready: it leaves room for future programmable trading around swap, fee, liquidity, and position logic, but it does not claim that all custom Hook mechanics are already deployed.

09 Parameters

• Mother Tax: 3%
• Marketing: 10%
• Child Rewards: 90%
• Mother Eligibility: 500,000 MOTHER
• Infinity Initial LP: 0.1 BNB
• Child Sell: 90% payout / 10% buyback & burn
• Stage 1 Cap: 100,000 CHILD
• Max Cap: 300,000 CHILD

10 Contract Architecture

The protocol uses a Factory, an upgradeable Vault, a Child Token implementation, a PancakeSwap Infinity adapter layer, and Flap Taxinfo schema integration. Internal ABI/storage names that still contain v4 are compatibility names. Public-facing copy should refer to the integration as PancakeSwap Infinity.

11 User Flow

1. A user launches a Mother Token through Flap.
2. The Factory creates and initializes the corresponding Vault / Child setup.
3. Mother trading tax enters the Vault and pushes Child Curve Rewards.
4. Eligible Mother holders claim Child Rewards.
5. Users can manually mint Child with BNB or sell Child back through the Vault.
6. When the Vault reaches the Infinity initial LP condition, the protocol enters the secondary-market layer.

12 Risk Boundary

• Child curve price is not a fixed-yield promise.
• Sellable BNB is limited by real Vault reserves.
• Infinity initial LP does not mean unlimited liquidity.
• Hook-ready does not mean every future Hook feature is already deployed.
• All parameters must be verified against the on-chain contracts and Flap Taxinfo.

13 Testnet / Mainnet Readiness

The website is the public presentation and user interaction surface. Mainnet readiness still depends on the deployed contracts, Factory configuration, Flap launch flow, PancakeSwap Infinity configuration, testnet smoke validation, and security reports.

14 Disclaimer

This document is not financial advice. Meme assets are highly volatile. Users should verify contract addresses, chain state, Flap Taxinfo data, and wallet transactions before interacting with the protocol.