BENEFICIAL-GENESIS-PROGRAM-001 — primary research roadmap

[Natoshi-moto]

BENEFICIAL-GENESIS-PROGRAM-001

Strategic decision

Beneficial Genesis is now the operator's primary research focus.

This program coordinates future work while preserving the existing governance boundary:

• STATUS.json remains unchanged;
• R016 remains canonical;
• Beneficial Genesis remains integrated, noncanonical research until separately promoted;
• no live funds, charity solicitation, token issuance, or mainnet deployment is authorized.

Current accepted research base

Merged proposal stack:

main merge: 22ce8c11297ad4c08606277ee83dc845797ba220

Evidence lineage:

Claude design
→ controlling review
→ Grok breaker findings
→ Codex repair
→ fresh Grok differential retest
→ 43 agreements / 0 disagreements / 0 crashes

Research objective

Determine whether Beneficial Genesis can become a technically sound, economically defensible, legally intelligible and operationally safe post-quantum migration mechanism in which qualifying source-chain assets are transferred directly to immutable charity destinations and cryptographically bind a new-ledger allocation claim.

Program tracks

Track A — Economic and mechanism safety

Test whether the fixed-pool proportional allocation creates unacceptable:

• whale concentration;
• donation timing games;
• charity rebate or circular-funding attacks;
• custodial/exchange capture;
• source-asset selection distortions;
• governance capture;
• sale-like or investment-contract characteristics;
• incentives to donate stolen or sanctioned assets;
• adverse selection around a quantum-compromise cutoff.

Deliverables must include explicit failure conditions and alternatives, not only parameter tuning.

Track B — Real Bitcoin receipt verification

Replace synthetic Bitcoin-like objects with bounded, independently reproduced Bitcoin semantics:

• transaction serialization and txid/wtxid distinctions;
• supported script templates;
• exact OP_RETURN commitment encoding;
• SegWit/Taproot authorization boundaries;
• header-chain and difficulty validation;
• Merkle inclusion;
• confirmation and reorganisation policy;
• SPV/eclipse limitations;
• deterministic fixture corpus from public historical transactions only, with no live charity addresses.

Track C — Real post-quantum admission

Replace synthetic HMAC stand-ins with real post-quantum primitives:

• ML-DSA primary;
• SLH-DSA fallback or recovery role;
• canonical key/signature encodings;
• domain separation;
• key rotation and compromise policy;
• hardware-wallet and signing-boundary requirements;
• cross-language vectors and independent verifier parity.

Track D — Charity attestation and immutable destination governance

Design a genesis ceremony that can establish, without mutable runtime governance:

• legal-entity identity;
• exact destination scripts/descriptors;
• charity authorization signatures;
• validity windows;
• key compromise and operational rotation policy;
• archival evidence;
• no-rebate declarations and audit limitations;
• global-jurisdiction inclusion criteria.

The protocol must distinguish what cryptography proves from what social/legal attestations assert.

Track E — Ledger integration and consensus boundary

Specify how Beneficial Genesis interfaces with an actual ledger without becoming its consensus mechanism:

• genesis allocation import;
• claim admission state machine;
• epoch close and allocation finalization;
• nullifier persistence and reorg rollback;
• validator/PQ key admission;
• custody and transfer restrictions;
• deterministic replay;
• testnet-only integration gates.

Track F — Legal, tax and public-interest review

Produce jurisdiction-scoped issue maps, not legal conclusions:

• charitable-donation treatment where tokens are received;
• crypto financial-promotion rules;
• token classification;
• sanctions/AML exposure;
• charity acceptance and disposal policies;
• donor privacy and public-chain linkage;
• consumer-risk language;
• prohibition on claiming backing, redemption or guaranteed value.

External qualified counsel is required before any public or live-funds phase.

Gating order

1. Economic red-team + real-Bitcoin feasibility
2. Real PQ verifier vectors
3. Charity-attestation ceremony design
4. Integrated closed testnet
5. External technical/economic/legal review
6. Separate operator-authorized promotion decision

No later gate may reinterpret an earlier synthetic pass as production assurance.

Immediate priorities

1. BGEN-ECON-REDTEAM-001 — adversarial economics and mechanism-necessity analysis.
2. BGEN-BITCOIN-RECEIPT-001 — bounded real-Bitcoin receipt feasibility and vector pack.
3. Publish PUBLIC_TEST_SEEDS into machine-readable synthetic constants as a small reproducibility cleanup, without confusing this with real PQ work.

Program discipline

Each task must use:

• exact subject commits;
• bounded write paths;
• explicit authority/nonclaims;
• separate Designer, Breaker and Reproducer seats where load-bearing;
• deterministic artifacts and receipts;
• no status promotion or R-round assignment without a distinct operator decision.

Definition of success

The program succeeds only if it can state, with evidence:

1. exactly what a donation receipt proves;
2. exactly what it does not prove;
3. why the allocation mechanism is necessary and resistant to strategic abuse;
4. how real Bitcoin and real PQ cryptography are verified independently;
5. how charity destinations are authenticated and frozen safely;
6. how the mechanism integrates with a ledger without becoming a disguised presale, custodian or consensus shortcut;
7. which risks remain irreducibly social, legal or operational.