PHONCOIN /
PHONCHAIN
A mobile‑native blockchain secured by real smartphones through Proof‑of‑Phone Secure v4.1 (PoP‑S4.1).
This document is canonical: any chain with a different genesis hash is not the Phonchain mainnet.
1. Executive summary
PHONCHAIN is a public blockchain designed natively for smartphones. It is secured by a mobile consensus called Proof‑of‑Phone Secure v4.1 (PoP‑S4.1), where real phones submit cryptographically signed heartbeats to participate in block production.
Accessible
Anyone with a smartphone can participate. No ASICs, no specialized rigs.
Energy‑efficient
Phones solve only a light PoW puzzle and sign data — CPU stays near idle.
Sybil‑resistant
Uniqueness signals + anti‑fraud checks make large‑scale bot farming costly.
2. Motivation
Proof‑of‑Work systems concentrate mining into industrial hardware. Proof‑of‑Stake concentrates influence into the richest holders. Meanwhile, billions of smartphones already exist worldwide with secure hardware, modern crypto, and continuous connectivity. PHONCHAIN turns this existing hardware base into a global security layer.
3. Consensus — Proof‑of‑Phone Secure v4.1
Core idea
One real phone = one participant. A phone generates an Ed25519 keypair and periodically submits a signed heartbeat. Each heartbeat includes a light PoW nonce and a hashed device fingerprint.
What the phone does
- Generate Ed25519 keypair
- Create a heartbeat payload (timestamp, nonce, fingerprint, device_info)
- Solve a light PoW target (SHA‑256 hash begins with N zeros)
- Sign the payload (Ed25519)
- Send to the network via HTTPS endpoints
What the node verifies
- Signature validity (Ed25519)
- Timestamp rules (anti‑replay)
- Difficulty target (leading zeros)
- Hashed fingerprint consistency (uniqueness signals)
- Trust score / emulator / root signals
- Rate limiting (anti‑spam)
3.1 PoW vs PoS vs PoP‑S4.1
| Property | PoW | PoS | PoP‑S4.1 (PHONCHAIN) |
|---|---|---|---|
| Accessibility | Low | Medium | High (smartphone) |
| Energy | Very high | Low | Very low |
| Sybil resistance | Medium | Low | High (phone + checks + light PoW) |
| Centralization pressure | High (pools) | High (whales) | Lower (1 device = 1 participant) |
| Adoption potential | Limited | Medium | Massive (mobile) |
4. Security model (PoP‑Secure v4.1)
Anti‑emulator
Known emulator fingerprints and suspicious environments can be rejected at heartbeat validation time.
Anti‑root + Trust score
A device trust score (0–100) is computed and verified against minimum policy thresholds.
Anti‑clone (fingerprint binding)
A hashed device fingerprint acts as a privacy‑preserving uniqueness signal and can be bound to a single address.
Anti‑replay + rate limits
Strict timestamp checks and minimum intervals reduce spam and repeated proof reuse.
Attestation‑ready
The device profile includes a placeholder field for platform attestation (e.g., Google Play Integrity or equivalent). This allows stronger device authenticity guarantees without changing the protocol design.
5. Data structures
Heartbeat (PoP‑S4.1)
{
"pubkey": "…" ,
"timestamp": 1760000000,
"nonce": 12345,
"signature": "…",
"device_fingerprint": "sha256(…)",
"device_info": {
"schema": "v4",
"manufacturer": "…",
"model": "…",
"brand": "…",
"device": "…",
"hardware": "…",
"product": "…",
"android_version": "…",
"sdk_int": 34,
"is_emulator": false,
"is_rooted": false,
"latency_ms": 42,
"play_integrity": "unknown",
"trust_score": 90
}
}
Block
{
"index": 6641,
"timestamp": 1760000300,
"prev_hash": "…",
"hash": "…",
"heartbeats": [ … ],
"transactions": [ … ]
}
Note: unique miners and reward are computed from heartbeats and block height (not stored as fields in the block).
6. Monetary policy (PHC)
Reward schedule (example)
| Phase | Block heights | Reward |
|---|---|---|
| Phase 1 | 0 – 419,999 | 25 PHC |
| Phase 2 | 420,000 – 839,999 | 12.5 PHC |
| Phase 3 | 840,000 – 1,259,999 | 6.25 PHC |
Exact supply is enforced by the consensus rules in the reference node.
7. Wallet (Android)
Non‑custodial by design
- Private keys stay on device
- Seed phrase backup / restore
- Local signing (no server custody)
Network safety
- The wallet never stores IPs
- It accepts a node only if the genesis hash matches the canonical chain
- Bootstrap allows rotating endpoints without wallet updates
8. Scalability
Heartbeats are compact, verifiable with Ed25519 and SHA‑256, and can be aggregated into blocks. Nodes maintain rate limits and windows to keep performance stable as participation grows.
9. Use cases
Micropayments
Low‑cost transfers between phones.
Mobile Web3
dApps integrated directly into mobile UX.
Participation proofs
Phone‑based activity signals for incentives and identity layers.
10. Roadmap
- Devnet/Testnet: iterate thresholds, scoring, and performance metrics.
- Mainnet: stable parameters and public endpoints.
- Future: stronger attestation signals, multi‑node ecosystem, and broader tooling.
11. Conclusion
PHONCHAIN is not a cosmetic variant of existing models. It introduces a mobile‑native security layer where smartphones become the fundamental unit of participation — accessible, efficient, and verifiable.
Canonical specification
This document is canonical. The official protocol specification, data structures and mainnet genesis anchor for Phoncoin / Phonchain are published on GitHub:
https://github.com/Phoncoin/phoncoin
Any chain, client or implementation referencing a different genesis hash is not the Phonchain mainnet.