# Claim & Sacrifice Hub The Vitality Claim & Sacrifice Hub is the planned user-facing entry point for Vitality claims, optional sacrifice participation, points, position NFTs, future eligibility records, and app-based ecosystem participation. This page is a rules and architecture record only. It does not open a claim campaign, does not open a sacrifice campaign, does not create a snapshot, does not mint NFTs, and does not create any public claim. ### Purpose The Claim & Sacrifice Hub is designed to: * onboard eligible users into the Vitality ecosystem; * support the pDAI-holder airdrop strategy; * protect the VTY/pDAI liquidity pool from large immediate sell pressure; * create a structured no-expectations sacrifice pathway; * strengthen Vitality treasuries and protocol-owned reserves; * create points, position NFTs, badges, and future eligibility records; * support future Vitality App identity, charging, CHI, CHI-Share, and NFT systems. ### Public page structure The intended public experience is: 1. Legal acknowledgement and no-expectations acceptance. 2. Claim eligible VTY. 3. Voluntary optional sacrifice. 4. View user dashboard, including claims, points, NFTs, balances, expiry dates, future eligibility, and activity history. Claim comes first. Sacrifice is voluntary. The dashboard remains visible as the long-term user interface. ### Key public phrase Sacrificing in support of the inalienable rights to better longevity, greater choice, and improved lifestyle systems. ### Current token allocation source The current published tokenomics allocation includes: * Airdrop Allocation: `234,360,000 VTY` * Strategic Sacrifice Vesting Allocation: `234,360,000 VTY` Source page: `https://vitality-project.gitbook.io/vitality-token-project/tokenomics/vitality-tokenomics-v2.1-genesis-allocation-reward-formula-and-custody-direction` ### Airdrop allocation The Airdrop Allocation is: `234,360,000 VTY` This allocation should not be released all at once. The planned first major campaign is the pDAI Holder Genesis Claim. #### Phase 1 — pDAI Holder Genesis Claim Planned Phase 1 pool: `70,308,000 VTY` Immediate liquid release: `3,515,400 VTY` Charging / future allocation: `66,792,600 VTY` This means the Phase 1 model is: * 5% immediate liquid VTY; * 95% charging, future eligibility, vesting, or later activation. ### Snapshot qualifier The pDAI Holder Genesis Claim is expected to use a snapshot qualifier. Snapshot source: PulseChain pDAI balances at a selected block. pDAI token: `0x6B175474E89094C44Da98b954EedeAC495271d0F` Snapshot timing should be selected after LP-1 observation and before public claim announcement. ### Eligibility process The intended qualification process is: 1. Select the snapshot block. 2. Export pDAI holder balances. 3. Remove excluded addresses. 4. Apply a minimum pDAI threshold. 5. Apply whale caps. 6. Calculate wallet scores. 7. Calculate fixed-pool normalized allocations. 8. Generate allocation and Merkle proof files. 9. Review campaign artifacts. 10. Open the claim only after explicit approval. ### Exclusions Campaign rules may exclude: * token contracts; * routers; * LP pairs; * known pool addresses; * burn addresses; * known project wallets; * known treasury wallets; * dust wallets below threshold; * obvious sybil or scripted clusters; * abusive wallets; * contracts where exclusion is required by campaign rules. ### Airdrop formula WalletScore = BaseScore + sqrt(min(pDAI balance, pDAI whale cap) / threshold unit) × HolderWeight WalletAirdropTotal = CampaignAirdropPool × WalletScore / TotalEligibleScores WalletLiquidNow = WalletAirdropTotal × 5% WalletChargingFuture = WalletAirdropTotal × 95% ### Strategic Sacrifice Vesting allocation The Strategic Sacrifice Vesting Allocation is: `234,360,000 VTY` This allocation should not be released immediately as liquid VTY. The planned first sacrifice-related campaign is the Genesis Sacrifice Position Campaign. #### Genesis Sacrifice Position Campaign Planned pool: `70,308,000 VTY` Immediate liquid VTY from sacrifice: `0 VTY` The sacrifice side should produce points, position NFTs, dashboard records, badges, and possible future eligibility. It should not immediately release liquid VTY. ### Sacrifice output A sacrifice may produce: * Sacrifice Points; * Sacrifice Position NFT; * dashboard record; * badge or profile marker; * future eligibility reference; * possible future campaign relevance. A sacrifice does not create any guaranteed return, profit, repayment, treasury claim, future claim, yield, or token entitlement. ### Sacrifice points formula SacrificePoints = BasePoints + sqrt(ReferenceValue) × AssetWeight × LockMultiplier × PhaseMultiplier ### Asset weights * pDAI: 1.25 * VTY: 1.30 * WPLS: 1.00 * WETH: 1.00 * PLSX: 0.90 * HEX: 0.85 ### Lock multipliers * 90 days: 1.00x * 180 days: 1.25x * 365 days: 1.60x * 888 days: 2.20x ### Phase multipliers * Genesis: 1.30x * Early: 1.10x * Standard: 1.00x ### Sacrifice vesting allocation formula WalletSacrificeVesting = SacrificeCampaignPool × WalletSacrificePoints / TotalEligibleSacrificePoints ### Fixed-pool multiplier safety rule All multipliers are scoring multipliers only. Multipliers must not increase the total VTY allocated to any campaign beyond its fixed campaign pool cap. The correct model is: 1. define the fixed campaign pool; 2. calculate wallet points; 3. calculate total eligible points; 4. allocate each wallet a proportional share of the fixed pool. The incorrect model is: Base VTY allocation × lock multiplier × phase multiplier That model must not be used because it can exceed the published allocation. ### Pool caps The total of all wallet allocations must never exceed the fixed campaign pool. For the pDAI Holder Genesis Claim, total allocations must not exceed: `70,308,000 VTY` Immediate liquid release must not exceed: `3,515,400 VTY` For the Genesis Sacrifice Position Campaign, total allocations must not exceed: `70,308,000 VTY` Immediate liquid VTY from sacrifice must remain: `0 VTY` ### Treasury routing for sacrificed assets Default routing principle: * 99% to Vitality treasuries, protocol contracts, liquidity reserves, app reserves, or approved ecosystem buckets; * 1% to the No Expectations Address. Asset-aware routing may be used. #### pDAI sacrifice * 75% pDAI Treasury Reserve * 15% VTY/pDAI LP Reserve * 9% Ecosystem / App / Operations Reserve * 1% No Expectations Address #### WPLS sacrifice * 65% Treasury Reserve * 25% VTY/WPLS LP Reserve * 9% Ecosystem / App / Operations Reserve * 1% No Expectations Address #### WETH sacrifice * 75% Treasury Reserve * 15% Strategic Reserve / Future LP Support * 9% Ecosystem / App / Operations Reserve * 1% No Expectations Address #### PLSX / HEX sacrifice * 70% Treasury Reserve * 20% Strategic Ecosystem Reserve * 9% App / Operations / Ecosystem Reserve * 1% No Expectations Address #### VTY sacrifice * 49% Long-Term Ecosystem Reserve * 25% BurnSink or Non-Circulating Reserve * 25% Charging / Future Campaign Reserve * 1% No Expectations Address ### Claim expiry Recommended claim expiry model: * campaign claim window: 90 days from campaign opening; * charging / future allocation activation: 180 days from first claim; * optional grace period: 30 days; * unclaimed allocations after expiry return to Airdrop Reserve or Ecosystem Campaign Reserve; * unactivated allocations after expiry return to Future Campaign Reserve. ### Legal acknowledgement Before any state-changing claim, sacrifice, NFT mint, or position action, the user should: 1. connect wallet; 2. review legal / no-expectations terms; 3. sign acknowledgement; 4. optionally or mandatorily record an on-chain acknowledgement receipt depending on action type; 5. proceed only after acknowledgement is complete. ### Required no-expectations acknowledgement concepts The user should acknowledge: * no expectation of return from the work of others; * no guaranteed profit; * no guaranteed token appreciation; * no guaranteed future claim; * no guaranteed yield; * no right to treasury assets; * no refund; * no purchase of investment product; * sacrifice is voluntary and final; * future campaigns may or may not reference points or NFTs; * points and NFTs do not guarantee future VTY; * features may change, be delayed, or never launch. ### Anti-gaming rules Campaigns may use: * minimum thresholds; * wallet caps; * whale caps; * square-root scoring; * one primary sacrifice position NFT per wallet per campaign phase; * dust exclusion; * sybil review; * scripted behaviour exclusion; * abusive wallet exclusion; * future eligibility review. ### LP and market-protection strategy The current official primary pool is VTY/pDAI. VTY/pDAI pair: `0x8808a2Ae5c8B35990e32632585150436C6589B8f` LP-1 public record: `https://vitality-project.gitbook.io/vitality-token-project/lp-1-vty-pdai-protocol-owned-liquidity` The strategy is to keep official liquidity controlled and modest while using claim rules, sacrifice vesting, lock periods, position NFTs, and future eligibility to reduce immediate sell pressure. Community LP may be recognised later through separate points, badges, NFTs, or eligibility records, but no recognition mechanism should guarantee yield, return, profit, or future token allocation. ### Not live yet This page is a rules draft. It does not: * open a claim; * open sacrifice participation; * create a snapshot; * generate a Merkle root; * mint NFTs; * fund a campaign; * launch a public claim; * approve LP-2; * deploy VTY/WPLS; * deploy VTY/HEX. --- # 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://vitality-project.gitbook.io/vitality-token-project/claim-and-sacrifice-hub.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.