Token Classification, Rewards & Voting
How price, liquidity, volume and registry status map to categories, rewards (MEGY, CorePoint, Deadcoin Bonus) and voting.
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.
- Once a token is classified as deadcoin, no further MEGY is ever distributed for new Coincarnations of that asset.
- CorePoint from Coincarnation contribution requires USD value > 0. If the token has truly zero USD value, contribution-based CP is not awarded; only a Deadcoin Bonus may apply.
- Past rewards are never revoked, except for blacklisted tokens where the protocol may invalidate past contributions and offer refunds.
1. Category → Reward Matrix (at time of contribution)
| Category at intake | USD Value | MEGY from pool | CorePoint (Contribution) | Deadcoin Bonus | Voting |
|---|---|---|---|---|---|
| healthy | > 0 | ✅ Yes (pool-proportional) | ✅ Yes (USD-weighted CP) | 🚫 No | 🚫 No (no deadcoin vote) |
| walking_dead (metrics) | > 0 | ✅ Yes (pool-proportional) | ✅ Yes (USD-weighted CP) | 🚫 No (until it becomes deadcoin) | ⚠️ Maybe – if backend marks it voteEligible=true (WD → deadcoin vote). |
| deadcoin (registry, USD > 0) | > 0 | 🚫 No | ✅ Yes (Coincarnation contribution CP) | ✅ Yes (Deadcoin Bonus, extra CP) | 🚫 No (status already final) |
| deadcoin (price-layer, USD = 0) | = 0 / not found | 🚫 No | 🚫 No (no USD → no contrib CP) | ✅ Yes (Deadcoin Bonus only) | ⚠️ Optional – can be escalated into registry deadcoin via admin/governance. |
| redlist | n/a | 🚫 No for new intake (past contributions stay as originally classified). | Past CP kept as-is; no new intake CP. | No new bonus | By governance only |
| blacklist | n/a | 🚫 No (intake fully blocked) | 🚫 No – past CP can be invalidated with optional refunds. | 🚫 No | Admin / governance only (risk event). |
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.
| Condition | Category | Reason |
|---|---|---|
Price not found or usdValue ≤ 0 | deadcoin | Price-layer deadcoin (no usable valuation). |
No DEX signal (no pools, liq = 0, dexSource = 'none') | deadcoin | Metrics-layer deadcoin (reason = 'no_data'). |
0 < liq < walkingDeadMinLiq | walking_dead | Illiquid but with some on-chain signal (reason = 'illiquid'). |
liq ≥ healthyMinLiq and volume ≥ healthyMinVol | healthy | Strong liquidity & volume (reason = 'healthy'). |
walkingDeadMinLiq ≤ liq < healthyMinLiq and volume ≤ walkingDeadMinVol | walking_dead | Adequate liquidity but very low activity (reason = 'low_activity'). |
walkingDeadMinLiq ≤ liq < healthyMinLiq and volume > walkingDeadMinVol | walking_dead | Borderline case, not yet healthy (reason = 'subhealthy'). |
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.