Coincarnation — Whitepaper

Coincarnation is a chain-agnostic contribution & distribution protocol that revives stranded crypto value (“deadcoins” & “walking-deadcoins”) into a common unit, $MEGY. Instead of relying on a volatile market price, each phase opens a fixed supply pool and allocates MEGY pro-rata by contributed USD value. The design emphasizes fairness, auditability, and resilience via multi-source valuation, a transparent floor policy, public dashboards, and explicit governance controls.

Practically, participants contribute supported assets; the protocol normalizes them to USD using a prioritized pricing stack with safeguards. At snapshot, MEGY is distributed according to each wallet’s share of phase demand. Optional vesting, caps, and anti-sybil controls can be enabled to smooth supply and protect the system.

Users contribute assets on Solana (SOL & SPL) in Phase-1 and on major EVM chains in Phase-2. Each contribution is normalized to USD through a priority source stack. For a phase with pool Pₖ MEGY and total demand USDₖ, a user with contribution USDᵢ obtains:

allocᵢ = P_effective × (USDᵢ / USDₖ)

The P_effective depends on the phase floor policy. Settlement occurs at snapshot, after which users can claim their MEGY (optionally paying a small network fee, e.g., $0.5 in SOL). Admin/multisig governs feature flags (app_enabled, claim_open) and phase parameters, with audit logs and optional on-chain reference hashes to ensure traceability.

3.1 Phase Variables

• Pool size: Pₖ MEGY opened in phase k.
• Recorded demand: USDₖ total USD during the phase.
• Optional reference rate (UI only): r_targetₖ USD/MEGY.

3.2 Floor & Partial-Open Policy

• Monotone floor: r_floorₖ ≥ max(r_realized₍ₖ₋₁₎, r_targetₖ)
• Effective pool: P_effective = min(Pₖ, USDₖ / r_floorₖ)
• Remainder (Pₖ − P_effective) rolls into the next phase if demand is below the floor.

3.3 User Allocation

allocᵢ = P_effective × (USDᵢ / USDₖ) (subject to per-wallet caps and vesting, if enabled).

3.4 Optional Caps & Vesting

• Per-wallet cap to reduce concentration and sybil risks.
• Linear vesting or cliffs to smooth post-phase token release.

The protocol normalizes contributions to USD using a priority source stack. It short-circuits on the first successful source and applies safeguards:

1. CoinGecko (proxied; mobile-friendly)
2. Raydium (SPL pools)
3. Jupiter Aggregator
4. CoinMarketCap
5. Fallback: classify as deadcoin (manual registry path)

Where available, TWAP/VWAP is preferred; the system enforces staleness thresholds and minimum liquidity screens. Results are cached with signed provenance to avoid device/network inconsistencies. Redlist/Blacklist rules are enforced at intake time so disallowed tokens cannot enter distribution.

Coincarnation separates valuation (price), market structure (liquidity & volume), and registry status (admin/community decisions). This section explains how these layers combine into a final category and how that category drives MEGY distribution, CorePoint, Deadcoin Bonus, and voting.

1. Category → Reward Matrix (at time of contribution)

2. Metrics Layer: USD Value, Liquidity & Volume → Category

After registry overrides, the system uses the metrics layer to classify tokens. Thresholds are stored in config (e.g. healthyMinLiq, healthyMinVol, walkingDeadMinLiq, walkingDeadMinVol) and can evolve over time.

3. Registry Locks & Time

Admin and community decisions can lock a token's status (e.g. walking_dead → deadcoin). Once locked, cron and metrics reclassification respect that decision. Future contributions follow the locked category, while all past rewards remain intact (except for blacklist cases where contributions may be invalidated with refunds). This ensures that early participants are not retroactively penalized when thresholds or policies evolve.

6.1 Roles & AuthN/AuthZ

• Treasury Multisig: custody and sensitive parameter changes.
• Admin Panel: hardware-wallet signMessage → nonce → verify → coincarnation_admin cookie (HttpOnly, SameSite).
• Role separation: Ops (runtime toggles), Risk (registry/policy), Finance (treasury), Audit (read-only export).

6.2 Feature Flags

• app_enabled: global kill-switch.
• claim_open: claim window control after snapshot.
• distribution_pool, coin_rate: phase pool and reference rate parameters.
• cron_enabled: reclassifier cron guard.

6.3 Change Management

• Cooldowns: change interval for critical parameters—“announce → grace → apply”.
• On-chain ref-hash (optional): parameter set hashes written on-chain to enable public verification.
• CSV & public dashboards: external-audit-friendly visibility.

6.4 Emergency Procedures

• Global pause (app_enabled=false), per-token intake stop via registry.
• Blacklist detection → optional refund flow for past contributions.

6.5 Auditability

• admin_audit table: who changed what and when.
• Each cron run → cron_runs; diffs written to token_audit.

7.1 Status Matrix

• healthy: normal intake.
• walking_dead: intake allowed, under observation.
• deadcoin: revival-focused; special visuals/labeling.
• redlist: new intake blocked after add-date; past contributions remain valid.
• blacklist: fully disallowed; past contributions invalid; optional refunds.

7.2 Intake Rules & Guards

• Pre-check: network match, mint/address format, min-liquidity/pricing threshold.
• Intake doesn't finalize until valuation pipeline yields a valid price.
• Per-token cap and per-wallet cap are optional.

7.3 Redlist vs Blacklist

• Redlist: forward-looking ban; historical contributions kept.
• Blacklist: retroactively invalid; optional refund to originating wallet.

7.4 Reclassification

• Cron job escalates walking_dead → deadcoin based on age, price inactivity, and case/vote triggers.
• All status changes are written to token_audit.

7.5 Refunds (Blacklist-only)

• Refunds are optional and only for blacklist items.
• Each refund is deduplicated and directed to the original sender wallet.

• Dual trigger: pool threshold + minimum time (or governance override).
• Small network fee (e.g., $0.5 in SOL) to claim.
• Partial claim optional; each claim recorded with txid and fee receipt.

CorePoint aggregates contribution (USD-weighted), referrals, first-time share-on-X events, and deadcoin multipliers. It powers leaderboards and future Personal Value Currency (PVC) minting, where each wallet can eventually mint a PVC token/NFT that encodes their long-term contribution to the Fair Future Fund.

11.1 Application Security

• Admin cookie: HttpOnly, SameSite, short-lived; origin and CSRF checks.
• Idempotency keys & replay protection on all write operations.
• Rate limits; wallet allowlist for admin areas.
• Signed caching & server-side price proxy (mobile-friendly & CORS-safe).

11.2 Data Hygiene

• PII minimization; user-agent/IP kept only to the operational extent necessary.
• Log rotation & retention windows; store only when required.

11.3 Legal Posture

• Clear “no investment advice” statement; protocol rules govern outcomes.
• Non-custodial posture wherever technically feasible.
• Jurisdiction awareness; we do not perform sanctions screening ourselves, but partner-compatible integrations can be considered where appropriate.

11.4 Transparency

• Public dashboards; export.csv; audit-friendly traces.
• “Announce → grace → apply” for parameter changes and (optional) on-chain ref-hashes.

1. Phase-1: Solana live; snapshot/claim tooling; dashboards & CSV.
2. Phase-2: EVM integrations; cross-chain valuation harmonization.
3. Phase-3: Governance expansion, PVC minting, audits, OSS modules.

This document is for informational purposes and not investment advice. Distribution follows protocol rules; parameters can evolve via transparent governance.