Technical Whitepaper · Version 1.0 · March 2026

DUMPYC: A Protocol for Blockchain Hygiene
on Solana

A permissionless burn protocol that converts dead meme coins into a scarce, deflationary token governed by a Bitcoin-style halving schedule.

Abstract

Solana's low transaction costs and permissionless token creation have made it the most active blockchain for retail token launches. This same accessibility has produced an ecosystem cluttered with hundreds of thousands of abandoned meme coins, failed project tokens, and zero-value assets occupying wallet space, inflating token account rent, and degrading the experience for legitimate participants.

DUMPYC is a permissionless burn protocol that converts this waste into a productive asset. Users burn unwanted SPL and Token-2022 tokens in exchange for DUMPYC — a fixed-supply, deflationary token governed by a Bitcoin-style halving schedule. The protocol requires no admin allowlist, supports any token with a Jupiter price feed, and enforces all safety guarantees at the smart contract level with oracle co-signing.

The result is a self-sustaining incentive loop: the more blockchain clutter that exists, the more valuable the cleanup mechanism becomes. Every DUMPYC token in existence is proof of cleanup work performed.

1. The Dust Problem

1.1 The Scale of Solana Wallet Clutter

Since 2021, Solana has hosted millions of token mints. The 2023–2025 meme coin supercycle alone produced hundreds of thousands of new tokens, the vast majority of which have since gone to zero. Wallet scanners routinely surface 50–200 distinct token accounts for active users — most of them holding assets worth fractions of a cent.

This is not merely an aesthetic problem. Each SPL token account on Solana requires a rent deposit of approximately 0.002 SOL (~$0.30 at current prices). A wallet with 100 dead token accounts has roughly $30 in capital locked in rent that cannot be recovered without explicitly closing each account. For retail users who accumulated tokens across multiple bull cycles, this locked capital sits silently idle.

Beyond rent, dust tokens impose cognitive load. Users must mentally filter noise from signal every time they open their wallet. They complicate portfolio tracking, confuse tax reporting, and serve as vectors for airdrop scam tokens — zero-value tokens designed to prompt unsuspecting users into interacting with malicious contracts.

1.2 Why Existing Solutions Fall Short

Existing approaches to wallet cleanup fall into two categories:

Neither approach creates a sustainable, ecosystem-wide flywheel for blockchain hygiene.

1.3 The DUMPYC Thesis

DUMPYC's thesis is simple: burning should be rewarded. When a user destroys a low-value token, they are performing a service to the ecosystem — reducing noise, freeing rent, and acknowledging that the token has failed its promise. That service should have a market price.

2. Protocol Overview

2.1 The Burn Flow

The DUMPYC burn flow is four steps. Every step is either enforced on-chain or cryptographically committed to by the oracle's signature — the user cannot be given a worse rate than what they agreed to.

2.2 Permissionless Token Support

The protocol supports any SPL token or Token-2022 token that passes automated qualification criteria. There is no admin-curated allowlist. When a user attempts to burn a token, the oracle evaluates it in real time and creates a TokenConfig PDA on-chain if it qualifies — all within the same transaction.

Removing the allowlist is the most important design decision in the protocol. An admin-curated list is fundamentally at odds with a cleanup protocol — if an admin must approve tokens, the long tail of genuinely worthless tokens (the ones most in need of cleanup) will never get approved.

3. Tokenomics

3.1 Supply Model

DUMPYC has a hard cap of 420,000,000,069 tokens (approximately 420 billion, with 6 decimal places). The supply is not pre-minted. Every DUMPYC in existence was minted in exchange for burned tokens — there are no team allocations, investor rounds, or genesis distributions.

This mint-on-demand model has a critical implication: every DUMPYC represents real economic value destroyed. The circulating supply is a direct measure of the cleanup work the protocol has performed.

3.2 Halving Schedule

DUMPYC uses a Bitcoin-inspired halving schedule. The minting rate halves every 1,000,000,000 DUMPYC (1 billion tokens) minted. Early participants receive proportionally more DUMPYC per dollar burned than later participants, rewarding early adoption while preventing hyper-inflation from late-stage bulk burning.

Burns that cross epoch boundaries receive a blended rate, calculated precisely on-chain using integer arithmetic with u128 intermediates to avoid overflow.

3.3 Protocol Fee

Every burn incurs a 5% protocol fee (configurable up to 10% maximum by admin). The fee splits into two streams with distinct purposes:

3.4 Burn Credits System

Burn credits are the protocol's mechanism for rewarding account closure — the most impactful form of cleanup. Credits accumulate with every burn but are only minted when the user redeems them by closing a token account.

This design means credits function as a deferred reward for wallet cleanup. A user who burns tokens but never closes accounts never receives their credits. A user who actively closes accounts receives bonus DUMPYC on top of their normal burn rewards. Even a token account with zero balance can be closed to unlock credits.

3.5 Liquidity Discount

Not all tokens have equal liquidity. A user attempting to burn $100,000 of a thinly-traded token cannot realistically extract $100,000 of value from the market — the trade itself would move the price substantially. The protocol models this reality with a sliding liquidity discount applied by the oracle.

The oracle probes Jupiter's routing engine to measure expected price impact at the burn size. This discount is baked into the oracle's signed price, so the on-chain program enforces exactly what was agreed. The 10% floor ensures that no token — regardless of liquidity — is ever valued at absolute zero.

4. Technical Architecture

4.1 On-Chain Program

The DUMPYC program is built with Anchor 0.32.1 on Solana. It uses three account types stored as PDAs (Program Derived Addresses), giving deterministic, trustless account resolution:

4.2 Oracle Architecture

The oracle is a server-side service co-deployed with the Next.js frontend. It performs four functions: price sourcing from Jupiter's Price API, TWAP tracking with Redis persistence, liquidity assessment via Jupiter's Quote API, and transaction co-signing.

The oracle's private key never leaves the server. The on-chain program requires the oracle's Ed25519 signature on every burn_for_dumpyc call. A compromised user client cannot mint DUMPYC at an arbitrary price.

4.3 Halving Algorithm

The halving calculation runs entirely on-chain. Burns crossing epoch boundaries receive precisely blended rates — the program iterates through epochs, filling each before moving to the next:

All arithmetic uses u128 intermediates with explicit overflow checks. The overflow-checks = true compiler flag in the release profile ensures arithmetic panics cleanly rather than silently wrapping.

4.4 Token Qualification

Every token is evaluated at quote time across five dimensions. Tokens are classified into tiers that affect daily burn caps but never block access entirely.

5. Security Model

5.1 Attack Surface

5.2 Trust Assumptions

DUMPYC makes two explicit trust assumptions in its MVP architecture:

6. Ecosystem Value

7. Roadmap

Appendix: Key Parameters

DUMPYC is experimental software. This document describes the protocol's design and is not financial advice. The oracle is centralized at launch; see Section 5.2 for trust assumptions.