# Boreal development charter v0.4

Updated 8 November 2026 from Justin's instruction: build a complete, popular,
advanced and secure coin ecosystem, with mining tailored to NVIDIA datacenter
GPUs, especially B300. B300 is the primary performance target; H200 is a second
datacenter comparison, RTX 5090 remains a practical development target, and the
local RTX 3050 is suitable for small correctness checks.

These are engineering objectives. No evidence currently establishes that Boreal
is the most advanced, most secure, GPU-exclusive or ASIC-resistant cryptocurrency.
No final mining algorithm, public network, security audit or production wallet
exists. The local chain and its current monetary rules remain unchanged.

## Product scope

Deliver a specified consensus protocol, independently verifiable node, NVIDIA
miner, recoverable encrypted wallet, pool/job interface, explorer, SDK, developer
documentation, reproducible releases, website and factual community updates.
Grow actual usage and contributions around working software. Avoid features
that add attack surface without a defined user need and validation plan.

## Hardware direction

Research a shared epoch dataset and independent nonce streams alongside the
current nonce-specific experiment. The existing 128 KiB CPU candidate is an
experiment; it does not implement the proposed shared 20 GiB architecture.
Treat 20 GiB as an evaluation point, not a chosen consensus rule or an ASIC
barrier. Keep CPU verification deterministic and explicitly budget its cost.

Compare stored-dataset mining with sparse caching, checkpointing, recomputation
and host-memory alternatives. Define seed/epoch commitments and bias resistance,
dataset generation and refresh costs, nonce mixing, target encoding and exact
integer serialization before selecting a candidate. Keep every candidate
versioned and separate from the running ledger.

Optimize CUDA implementation details for the actual device: occupancy, register
pressure, coalescing, independent work streams and measured memory traffic.
Do not infer mining throughput from advertised AI FLOPS or memory bandwidth.
Do not add NVLink traffic per nonce solely to use datacenter hardware. Start
multi-GPU measurement with independent work allocation and quantify overhead.

Consensus validates computation, not a declared GPU brand. An NVIDIA-optimized
miner must not require trusting a miner's reported device identity. Retain a
portable reference for correctness and adversarial comparison. Do not assert
that tailored software excludes CPUs, FPGAs, AMD GPUs or custom silicon.

## Security standard

Use maintained standard cryptographic implementations. Existing ML-DSA-65
authorization is one component, not proof of security of the complete network.
Track upstream advisories and NIST errata. Do not invent a signature primitive
or promote a library dependency into a claim of certification.

Before public testnet: versioned canonical serialization, bounded parsing and
peer input, duplicate/replay handling, chainwork/fork-choice/reorg tests, difficulty
simulation, restart/corruption recovery, wallet backup/restore, explicit trust
boundaries, fuzzing and independent implementation checks must have evidence.
Before protecting real assets: independent reviews, resolved critical findings,
reproducible signed releases, incident/upgrade processes and user-facing key
recovery are required. Tests alone are not an audit or a security ranking.

## Acceptance scoreboard

| Track | Evidence required | Current status |
| --- | --- | --- |
| GPU correctness | Independent vectors and verified shares on named hardware | Baseline CUDA and synthetic 4 GiB probe on RTX 3050 only |
| B300 advantage | Same-work CPU/RTX 5090/H200/B300 measurements, full setup and verification costs | No B300 access or measurements |
| Energy efficiency | Valid work per joule with stated power measurement boundary | Not measured |
| Shortcut economics | Equal-output cache/recomputation experiments with work and memory accounting | Specification discussion only |
| Consensus safety | Cross-node vectors, malicious input, forks, reorgs and difficulty simulations | Local prototype only |
| Wallet safety | Encrypted keys plus tested backup, restore, recovery and failure behavior | Encrypted local CLI; recovery UX unfinished |
| Reproducibility | Source revision, build/toolchain, commands and machine-readable artifacts | Local source/tests versioned; release process unfinished |
| Independent review | Named scope, findings, remediation and retest | Not commissioned |
| Adoption | Returning testers, reproducible submissions, contributors and resolved issues | No measured public community yet |

## Near-term order

1. Reproducible hardware inventory and benchmark manifest/report tooling; record
   actual available hardware and explicitly label missing B300 measurements.
2. Time-memory tradeoff experiments against the CPU candidate, including full
   recomputation and at least one reduced-storage strategy on identical inputs.
3. Shared-dataset candidate specification with a bounded CPU reference and
   verifier-cost analysis. Retain reduced-size functional modes for local GPUs.
4. CUDA adapter and candidate kernels; verify on idle RTX 5090 hardware with
   bounded runs, then measure H200/B300 only when access is available.
5. Close wallet recovery, parser, persistence and consensus test gaps before
   advancing toward a separately versioned node/testnet implementation.

Between performance milestones, close the highest-priority open security or
reproducibility gap. Do not turn the project into an endless benchmark-only loop.
Record failed hypotheses and retire weak candidates rather than changing claims.

## Popularity and communication

Facebook and Instagram are the selected social destinations. Prepare separate
captions, demonstrations and accessible graphics tied to verified milestones.
The private website remains private until its audience is explicitly changed.
Metricool/account connection is still required for external social publishing.

No purchased engagement, fabricated usage, undisclosed sponsorship, guaranteed
returns, invented benchmarks or unsupported security superlatives. No spending,
hardware rental or unsolicited third-party outreach is authorized by this brief.
User-specific account connections and public access decisions remain separate
from ordinary local development. Existing project work may continue autonomously.

## Primary sources checked 8 November 2026

- NVIDIA DGX B300 guide: https://docs.nvidia.com/dgx/dgxb300-user-guide/introduction-to-dgxb300.html
- NVIDIA Blackwell Ultra datasheet: https://resources.nvidia.com/en-us-gpu-resources/blackwell-ultra-datasheet
- NVIDIA Blackwell tuning: https://docs.nvidia.com/cuda/blackwell-tuning-guide/
- NIST ML-DSA standard: https://csrc.nist.gov/pubs/fips/204/final

NVIDIA documents list differing B300 memory figures: the DGX guide lists
288 GB/GPU, while the Blackwell Ultra datasheet lists HGX B300 at 270 GB and
7.7 TB/s and the GB300 NVL72 variant at 279 GB and 8 TB/s. Preserve the source
and product distinction; do not invent an explanation for the discrepancy.
Use runtime inventory and free-memory queries to plan real allocations.