PoEM Transparency & Trust

Our commitment: everything about PoEM (Proof-of-Engagement Mining) must be provably live, immutable, and verifiable—or clearly marked as in-progress. Below is a checklist of what’s live, what’s coming, and our open roadmap.

PoEM Credibility Checklist

All 10 transparency pillars live & verified [Audit, multisig, oracles, legal, source diff]
6+ months mainnet uptime, no rollbacks, minimal downtime [Status dashboard, GitHub log]
100+ validators, no entity >20% hash/stake [Live Nakamoto chart]
Sustainable: fees ≥ emissions, supply growth <2%/yr [Dune/Flipside, CSV export]
Real utility: 5,000+ daily tx, $100k+ value on flagship dApp [Explorer, analytics]
Social mining tweets must spread good: reference a good deed or positive sentiment [Verification = trust]

PoEM Tokenomics: 80% Compute, 20% Social Mining
Pillar	Concrete evidence	Status
1. Reproducible code & binaries	Tag + hash match: cloning poem-v3.0.2 and running the build script yields identical bytecode to what’s on-chain. Public diff against Dogecoin v1.14.99 shows only the new social-mining, vesting, governance, and LP-mint folders.	Live
2. On-chain contract behaviour	1-click testnet demo proving: • `registerHandle → claimSocial → vesting release` obeys the 30/100 rules. • `unlockDevTranche` releases exactly 724,500 PoEM only when oracle data confirms the milestone. • A failed-quorum DAO proposal auto-unlocks 15% of the Dev Fund.	In Progress
3. Oracle & metric integrity	≥ 7 independent oracle signers (hardware keys visible on-chain). Public dashboards (Dune/Flipside) mirroring the “Daily Active Addresses” and “dApp count” feeds.	In Progress
4. Multisig hygiene	3 / 5 keys held by separate legal entities (core dev, external auditor, community foundation). PGP-signed addresses + published key-rotation policy.	In Progress
5. Security audits closed out	“Acme Security Audit – PoEM v3.0” (or equivalent) with zero outstanding high/critical findings, and clear commit links for every medium fix.	In Progress
6. Economic soundness	Stress-test report modelling: • Social-mining emissions vs. projected hash-rate growth. • Max annual dilution if LP top-ups are hit (≤ 2%/yr). • Five-year supply ceiling stays ≤ ~76M PoEM.	Planned
7. Sybil resistance in practice	Public bounty program that tried—and failed—to break the ≥ 30-followers / 7-day rule at scale. Results published.	Planned
8. Immutable safeguards	• LP tokens from Day 0 provably locked in the multisig (no withdraw function). • Hard caps baked into LP-mint contract (2% per proposal, 6% per calendar year).	In Progress
9. Transparency UX	Live “Transparency Dashboard” that surfaces: • Dev-Fund balance & unlock history • Vesting progress for social miners & dev team • DAO proposals + turnout stats • LP multisig balance	Planned
10. Legal clarity	Public memo (or at minimum a legal-counsel statement) on how PoEM distribution aims to avoid U.S. securities issues—plus jurisdiction for the DAO foundation.	In Progress

Roadmap & Commitments

Q2 2025: Mainnet launch, code reproducibility, public repo, social-mining live, basic multisig, initial oracle set
Q3 2025: Testnet demo for contract flows, transparency dashboard MVP, first audit round
Q4 2025: Oracle expansion, bounty program, full DAO voting, legal memo publication
2026: Economic stress test, advanced transparency dashboard, ongoing audits, governance upgrades

Disclaimer: Some features described above are under active development. This page is a public commitment to transparency and verifiability. Status will be updated as milestones are achieved.

Programmatic Safeguards Against Rugs

Your friend raises a valid concern, but you're also right—there ARE ways to programmatically lock things down. Here's what's possible and what isn't:

What you CAN programmatically prevent:

Direct rug pulls
- Lock LP tokens in a contract with no withdrawal function
- Use time-locked vesting for all team tokens (immutable)
- Renounce contract ownership after deployment
- Hard-code supply caps that can't be modified
Backdoor minting
- Make the mint function immutable with fixed rules
- Require multi-sig or DAO approval for any minting
- Set absolute caps in the contract itself
Fund drainage
- Put treasury funds in time-locked contracts
- Require community votes for large withdrawals
- Use decentralised governance from day one

What's harder to prevent:

Market manipulation: Devs can coordinate dumps if they hold tokens (even vested)
Social engineering: Devs abandoning the project still harms value even if funds are safe
Hidden wallets: Devs could control undisclosed wallets from initial distribution
Oracle manipulation: External data dependencies remain a potential vector

The gold-standard approach:

// Example: Immutable supply cap
uint256 public constant MAX_SUPPLY = 69_000_000 * 10**18;
// No function can ever change this

// Example: Permanent LP lock
function lockLiquidity() external {
    // Transfer LP tokens to burn address
    // Literally impossible to retrieve
}

// Example: Renounced ownership
function renounceOwnership() public {
    owner = address(0);
    // Contract now has no admin
}

Your best bet: Launch with ownership already renounced, LP locked, and governance fully decentralised from day one. Yes, this means less flexibility, but it's the only way to prove you can't rug.

Initial Coin Distribution

Allocation	Amount	Destination
Compute Mining Pool	55.2M (80%)	`0x...` (immutable contract)
Social/Kindness Pool	13.8M (20%)	`0x...` (immutable contract)
Team/Dev/Marketing	0	None
Total	69M	100% to community

The “Unable to Rug” Guarantee

Mint new coins (no function exists)
Withdraw liquidity (LP tokens burned)
Modify contracts (ownership renounced)
Change vesting schedules (immutable)
Pause transfers (no pause function)
Upgrade contracts (no proxy pattern)

The worst we could do: Stop working on it. The protocol would continue functioning exactly as designed — forever.

Day 1 Launch Sequence

Deploy from fresh wallet (0 coin allocation)
Renounce ownership in constructor
Burn LP receipts → 0x000...dead
Publish all contract addresses
Live-stream entire process

Kindness Verification (MVP)

What qualifies: Any genuine act of kindness performed today
Limits: 1 claim/day, variety required
Phase 1: Honor system + random community checks
Phase 2: Elected validators
Banned: Fake posts, buying kindness, coordination

Verification Scripts

github.com/poem/verify
verify:no-backdoors
verify:lp-burned  
monitor:whale-alerts
audit:all-wallets

Zero Team Coins Declaration: No coins allocated to team, advisors, or marketing. No hidden wallets. No pre-mine. 100% of supply is mineable by the community through compute + kindness.

View PoEM Releases ← Back to Main Site