This is a living design document. No ledger or wallet has been implemented yet.

PIXEL — P1START native currency (PXL)

Status: Design phase. No live ledger, miner, or wallet exists yet. When implementation lands, update newdocs/pixel-currency.md and platform-docs/docs/reference/pixel-currency.md in the same change.

Where this lives: newdocs/pixel-currency.md (source of truth) — mirrored for the published book at platform-docs/docs/reference/pixel-currency.md.

Audience: founders, systems architects, game/economy designers, and future implementers of payments inside P1START.

Platform vs PXL (execution order): P1START is an OS first. Kernel, drivers, scheduler, VFS, IPC/WM, SDK (cstd / p1window), and control-plane daemons must reach reviewable contracts before any ledger, consensus, or mining work. This document stays the product/narrative spec for PIXEL; shipping it is not gated on cryptocurrency. Optional IPC sketches (e.g. cstd::pxl_wallet) exist for future alignment only and are not on the default init path.

Note

This page is mirrored from newdocs/pixel-currency.md. Prefer editing newdocs/pixel-currency.md first, then sync the body here so Git grep and newdocs/ navigation stay aligned.

1. Identity

Field

Value

Currency name

PIXEL (spoken: “pixel”, plural natural in English)

Ticker

PXL

Full formal name

PIXEL Coin

Slogan

Every pixel has value.

Colloquial framing

People pay in pixels — amounts, tips, and prices are denominated in PXL; the OS and apps surface that as “PIXEL” in UI copy.

Why this name fits P1START

  • Ties directly to graphics, games, and the compositor (real pixels on screen).

  • Reads as money in conversation (“send 420 PXL”, “this pack costs 69 PXL”) without borrowing another project’s ticker or chain identity.

  • Avoids implying a bridge or wrap of an external asset unless one is explicitly built later.

2. Philosophy — digital oil for the OS, not digital gold

Intent (non-binding narrative, binding engineering goals below):

  • PXL is the native money of P1START — not a fork of Dogecoin, Bitcoin, or anything else. It is the unit of account for the platform economy this OS is meant to host.

  • We intentionally kept the part of Dogecoin many people called a “mistake”: no hard cap, steady per-block issuance, no halvings. For an OS, that shape is load-bearing: the platform needs perpetual issuance so gas, rewards, day-to-day liquidity never hit a subsidy cliff or a scarcity-hoarding equilibrium that freezes circulation.

  • Mental model: most cryptocurrencies chase scarce digital gold. PXL is digital oil — meant to be spent, tipped, gambled with, and circulated inside the OS. The platform needs money that stays cheap and usable for micropayments, in-game purchases, micro-apps, tipping, and creator rewards even ten or twenty years from now. A hard cap encourages hoarding; we want the opposite.

  • Any future peg, bridge, or swap to other assets is a separate, explicit product decision.

2.1 Core invariants (policy)

These are real commitments for the currency narrative and, once implemented, for the ledger rules unless governance/spec explicitly revises them:

  1. Uncapped total supply — never a hard maximum; new PXL enter via issuance rules, not a one-time story only.

  2. No halving cliff — no baked-in schedule that drops subsidy to zero and dumps security overnight onto fees.

  3. No protocol-mandated burning — PXL is not destroyed at consensus to “manage” supply (see §3.2).

  4. One native fungible unit — PXL only at the base layer; no ERC-20-style parallel token protocol in core. Richer things are artifacts (§4), not new circulating fungibles.

Design principles

  1. Spend-first culture — circulation beats permanent mattress mentality for OS money.

  2. Wallet as OS, not “a crypto app” — payments, backup prompts, and confirmations should feel native to P1START (exact UX TBD).

  3. Transparency — issuance and consensus rules are documented and versioned here and in any chain spec repo.

  4. No false promises — numeric targets in §3 are pre-genesis and not on-chain guarantees until implemented.

3. Monetary policy — target parameters (Dogecoin-class inflation)

The table below is the current documented target band for economic shape: steady issuance, no hard cap, no halving cliff. Block subsidy stays tunable until genesis is frozen; a higher illustrative band (e.g. 10,000 PXL/block, ~5.3B/year) remains available for modeling if security or distribution analysis demands it.

Parameter

Target

Notes

Block time

60 seconds

Tuning subject to consensus layer and network RTT.

Block subsidy (new issuance)

1,000 PXL per block

Fixed per block until governance/spec explicitly changes it (no automatic halving schedule).

Maximum supply

None

Deliberately uncapped total supply.

Issuance trajectory

~526 million PXL / year from subsidy

At 60 s/block: 1,000 × (365.25 × 24 × 3600 / 60) ≈ 5.26×10⁸ PXL/year from subsidy alone before fees (order of magnitude ~½ billion / year).

Halvings

None planned

Long-term security must be designed via fees, stake, sponsorship, or mixed models as the chain matures.

Fees

  • Goal: Low and predictable fees for normal OS use — tips, microtransactions, in-game purchases, micro-apps. Exact fee market depends on consensus, block size, and mempool policy (TBD). Fees accrue to validators/miners (or equivalent); no fee burning (§3.2).

Issuance and psychology

Subsidy is material while the network is small, then new issuance / total float shrinks as a percentage over time — without halvings or other artificial scarcity tricks. The aim is simple: keep PXL psychologically cheap to use inside the OS.

Relationship to Dogecoin’s “infinite money” genesis

  • The deliberate lesson: predictable, ongoing issuance keeps utility money from behaving like collectible digital gold inside an OS.

  • Numbers here are P1START’s — not a claim about any other network’s history, founders, or governance.

3.1 “Eternal gas” — utility money vs deflation myths

Framing: Treat PXL as perpetual fuel: always more minted under a known rule, so the system never “runs out of block rewards” the way a hard-capped coin eventually does relative to subsidy.

Does this cause a deflationary spiral?
No — in the sense usually meant. A hard cap encourages hoarding and SoV mindset. PXL targets medium-of-exchange: purchasing power may drift down (dilution) relative to demand; that differs from a deflationary spiral driven by fixed supply + hoarding. The dominant risk for uncapped issuance is the other way: too much subsidy or too little adoption → dilution or loss of credibility — so tuning matters.

Inflation rate over time: With fixed absolute subsidy per block (e.g. 1,000 PXL), stock grows ~linearly while flow from subsidy is constant — so new issuance / total stock → 0 over many years. No cap; the rate damps without halvings.

“Healthy but not ridiculous”: This ~½B PXL/year subsidy band is chosen so issuance is material early but not multi-billions unless governance revises it upward.

3.2 Explicit non-goals (minting and supply)

  • No consensus-level burn — PXL transferred as fees or spent in-app is not destroyed by protocol rule to “offset” unlimited supply. (Application-layer escrow or locking is orthogonal; the ledger does not shrink the supply schedule via burn.)

  • No core “fungible token standard” competing with PXL — avoid Ethereum-style multi-token complexity in the base layer. One native liquid unit; artifacts (§4) attach data/identity without inventing new circulating pump-and-dump surfaces at consensus.

4. Digital artifacts and NFTs — without smart-contract soup

Goal: Support unique digital items — art, voxel models, micro-apps, collectibles, authenticated builds — without Ethereum-style smart contracts at the base layer.

Current direction (summary): default = on-chain hash + pointer (content lives off-chain; see §4.2). Full on-chain file storage (ordinal-class) = research only (§4.4) unless we explicitly accept base-layer cost. That yields provenance and authenticity with minimal ledger bloat.

4.1 Tension: “ordinals are simple” vs reality

Inscription / ordinal-style models (bind payload to specific sub-units of PXL, move UTXO ⇒ move artifact) are conceptually clean — no ABI graph.

In practice, as critics note, they still load the base ledger:

  • Validators and full nodes must decide what counts as valid witness data, size limits, replay, and long-term storage policy.

  • Wallets need coin control and indexing so users don’t destroy artifacts when spending “normal” fees.

  • That is a second layer of rules on top of “plain” UTXO transfers — a hack in the social/implementation sense, even if not a separate ERC-20 token.

So: PXL stays Dogecoin-simple as money; artifacts should default to patterns that minimize how much extra consensus behavior you inherit.

4.3 Optional: separate artifact layer (still not ERC-20)

If even hash-in-tx feels too heavy for consensus v0, artifacts can live in userland / daemon registries (signed manifests, app-specific DBs) with optional anchors to PXL txids for timestamping / ordering. Money and “collectibles DB” stay logically separate — simpler to implement, weaker global ordering guarantees until anchored.

4.4 Research / later: heavy inscriptions (ordinal-class)

Full “every atom of PXL can carry bytes” might be revisited only after:

  • explicit byte budget per block,

  • pruning / archive roles for nodes,

  • wallet UX for inscribed vs fungible change.

Until then, treat §4.2 as the default narrative for “NFT support without ETH complexity.” §4.4 is not a commitment.

Out of scope for v0 spec: commitment format, hash algorithm, max payload size, royalties, transfers of artifact rights separate from PXL — artifact RFC once ledger milestones exist.

5. Role inside P1START

PXL should feel like a native part of the operating system, not a bolted-on cryptocurrency.

Experience targets

  • Wallet: non-custodial, on first boot or clear opt-in; users hold keys; backup/recovery before ship.

  • Payments in apps and games feel natural — as easy as pressing START (exact UX TBD).

  • Use cases: tipping, cosmetics, micro-app payments, UGC rewards, bandwidth / compute metering, Proof-of-Uptime (or equivalent) rewards — first-class, not demos.

  • Artifacts: clean ownership and verifiable provenance via §4 (commitment-first).

Area

Direction

Wallet

Non-custodial; keys user-owned; recovery flows specified before ship; legal/custody posture reviewed before release.

Denomination

Services quote in PXL; no silent fiat conversion in core unless configured.

App payments

IPC/syscall payment intents (subs, purchases, royalties, splits) — spec + future IPC only until the platform surface is stable. Optional stub: cstd::pxl_wallet / wire 290 (apps/p1wallet, not started by init).

Gaming

Optionals: matchmaking deposits, cosmetics, seasons, UGC payouts.

Compute / network

Optional bundled metering (relay, build minutes) where it helps abuse prevention.

Tipping

Shell, games, WM-hosted apps where policy allows.

Artifacts

Hash + pointer default (§4); ordinal-class only if explicitly accepted later.

UX mantra: Press START to transact.

6. Technical workstreams (to be designed / implemented)

Work is not ordered as a commitment; dependencies will emerge once consensus is chosen.

  1. Ledger and consensus — PoW, PoS, BFT federation, or app-chain settlement: trade-offs for home users, validators, and game cheating resistance must be written down before genesis.

  2. Networking — peer discovery, tx propagation, DoS limits; interaction with P1START’s existing kernel network stack (Networking overview).

  3. Wallet cryptography — key derivation, storage (TPM/secure element if available), signing API for userland.

  4. Kernel vs userland boundary — what runs in ring 0 (minimal) vs daemons (init-adjacent wallet service, indexer, etc.).

  5. Fair initial distribution — genesis allocation, faucet, mining, airdrop to builders: high governance risk; document decisions here when made.

  6. Artifacts — default hash + pointer commitments (§4.2); optional side registries (§4.3); ordinal-class payloads (§4.4) only if an explicit future spec accepts node/pruning/wallet costs.

  7. Regulatory and fraud — jurisdiction, KYC/AML where required by law, scam and phishing patterns in OS-level payment UI; legal review is out of scope for this doc but not for the project.

7. Brand and visuals (reference only)

  • Retro + arcade cues (glowing “START”, coin-edge pixel art) and modern cyberpunk cues were discussed as dual visual lanes; final art direction lives outside this spec.

  • Mascot or campaign characters are optional; monetary policy does not depend on them.

8. Risks (no sugarcoating)

  • Continuous issuance → 1 PXL will likely lose purchasing power over time unless real usage grows faster than issuance. Intentional for digital oil; not a bug to “fix” with a cap or burn.

  • Long-term security cannot rely on block rewards forever — fees, stake, sponsorship, or mixed models must carry weight as the network ages.

  • Fair launch / early distribution — genesis, faucet, mining, airdrops: high governance risk; design carefully.

  • Wallet + payments in an OS → regulatory and consumer-protection exposure is real. Cannot be ignored; legal review, non-custodial defaults, honest UX.

  • Dilution — subsidy too high vs adoption → unit feels worthless; governance/economics, not code alone.

  • Artifacts — commitment + pointer limits load; full inscription (§4.4) still stresses storage and fairness if ever pursued.

This is still a design document. The ledger spec and running code define final behavior. When implementation lands, this file must be updated to match reality.