BOREAL LOCAL DEVELOPMENT HARNESS v0.2

This is a local single-process development ledger, not a peer-to-peer node,
public testnet, wallet product, exchange asset or production cryptocurrency.

REQUIRES
Python 3.11+ and cryptography 50.0.0 with ML-DSA support.
Use a project-local virtual environment for installation:
python3 -m venv .venv
.venv/bin/python -m pip install -r devnet/requirements.txt
.venv/bin/python -m devnet.demo --out /tmp/boreal-demo.json
.venv/bin/python -m unittest -v devnet.test_ledger
On Windows use .venv\Scripts\python.exe.

IMPLEMENTED
Real ML-DSA-65 signatures through PyCA cryptography and its OpenSSL backend;
network-bound signing with an ML-DSA context; versioned development addresses
with checksums; a single-signer UTXO transaction model; bounded inputs/outputs;
coinbase maturity; signature, ownership, fee and value validation; 25% integer
fee burning; staged block acceptance; full transaction commitments; fixed easy
SHA-256 development PoW; previous-block linkage; replayable chain export.
No new signature primitive was invented. Library use does not constitute an
audit or FIPS certification of this project.

The development proof hashes pow_header(block)[32] || nonce_le64, matching the
message layout of the supplied CUDA SHA-256 scanner. No CUDA integration run
has been performed. Hashing and commitment choices are development scaffolding.

DEMO
Two ephemeral ML-DSA-65 keys; three reward blocks; a signed transfer of one
development coin; a fourth block that burns one quarter of its fee; replay
by a fresh independent Chain object. Public output contains no private keys.
All demo keys are discarded. Do not send real funds or reuse generated addresses.
The replay test uses the same implementation, not an independently written node.

NOT IMPLEMENTED / UNREVIEWED
Peer networking, chainwork fork choice and reorgs, difficulty adjustment,
light verification of a final DAG, GPU-favouring PoW, production mempool policy,
wallet backup/recovery, multisignature, production serialization,
clock/peer abuse defence, mature database, release signing and security audit.
The fixed 8-bit work and 3-block coinbase maturity are development parameters.
Acceptance APIs are not hardened against arbitrary in-process Python objects.
JSON imports have duplicate-key/float rejection and a byte limit, but still
need fuzzing, nesting limits and production parser review before exposure.

REFERENCES
https://cryptography.io/en/stable/hazmat/primitives/asymmetric/mldsa/
https://csrc.nist.gov/pubs/fips/204/final

LOCAL ENCRYPTED WALLET AND INBOX (milestone 1)
Use .venv/bin/python -m devnet.wallet --help for create/address/balance/send,
submit and receipt commands. Creation and signing require a private terminal;
public address and balance do not prompt. Amounts are integer atoms. New local
states may use service --reward-address ADDRESS; existing identities stay fixed.
The wallet never writes the chain database. The file inbox permits 64 pending
32-KiB submissions, examines 16/block and retains at most 4,096 lifetime terminal
receipts. No receipt pruning, pending-fund reservation or recovery UX exists.
See reports/PROGRESS.md for a runnable command sequence and measured tests.
