[ANN] Remzar — Rust L1 Blockchain with ML-DSA-65 and ML-KEM-768

Hello everyone,

I am announcing Remzar, a working Rust-based Layer-1 blockchain that I built as a single interactive executable. It is not a token on another chain and it is not a theoretical proposal. Remzar is a new L1 blockchain with its own wallet system, node runtime, peer-to-peer networking, block production, transaction handling, local database storage, audit tools, and command-line menu interface.

The project is post-quantum-oriented and integrates FIPS 203 / ML-KEM-768 and FIPS 204 / ML-DSA-65 into core areas of the system, including wallet signatures, block-batch signing, and peer-to-peer key-establishment design.

This ANN is intended to be technical and direct: no hype, no investment claims, no token sale announcement. I am posting Remzar here for technical visibility, discussion, feedback, and future node-operator interest.

-------------------------------------------------------------------------------------------------

Remzar — Rust-Based Post-Quantum-Oriented Layer-1 Blockchain

Website: https://www.remzar.com/
Whitepaper: available on the website
Contact: [remzarchain@gmail.com](mailto:remzarchain@gmail.com)
Native asset: REMZAR
Ticker: ZAR
Protocol version: 1.0.0
Planned public launch date: 2026-06-26

Overview

Remzar is a working Rust-based Layer-1 blockchain built as a single interactive executable.

It is not a token on another chain. It is a new L1 blockchain with its own node, wallet system, peer-to-peer networking, block production, transaction handling, local storage, audit tools, and interactive CLI interface.

The design goal is simple: one executable that lets an operator create wallets, start a node, send coins, inspect live chain activity, export logs, send peer-to-peer messages or files, create audit reports, and use certificate/NFT/RWA-style data anchoring tools without needing separate wallet software, explorer software, external database tools, or hosted infrastructure.

Remzar is currently in a private working stage. The planned public launch date is 2026-06-26. Early binary access is controlled and provided only to serious node operators by request.

Core Technical Summary

Implementation language: Rust, edition 2024
Deployment model at launch: Windows executable
Node model: single interactive CLI application
Consensus: Proof of Registry
Block interval: 30 seconds
Default node port: 36213
Maximum block size: 2 MiB
Maximum transactions per block: 7,500 active hard cap
Storage: RocksDB-backed local storage
Hashing: BLAKE3-style 64-byte commitments
Signature model: one ML-DSA-65 signature per block batch
Wallet protection: Argon2id, AES-GCM, encrypted wallet files, zeroization discipline
Native asset: REMZAR / ZAR
Maximum supply: 200,000,000 ZAR
Issuance: validator block rewards only
Genesis reward: 0 ZAR
Premine: none configured

Post-Quantum Cryptography

Remzar is built around NIST post-quantum cryptography standards.

FIPS 204 / ML-DSA-65

Remzar uses ML-DSA-65 for post-quantum digital signatures.

The important design choice is that Remzar does not require one post-quantum signature verification per transaction inside a block. Instead, transactions are hashed into a Merkle root, and the Merkle root is signed once for the full block batch.

This makes post-quantum signature verification a block-level operation instead of a per-transaction bottleneck.

FIPS 203 / ML-KEM-768

Remzar includes ML-KEM-768 for post-quantum key encapsulation and post-quantum session/key-establishment design in Remzar-specific peer-to-peer transport flows.

The networking and transport layer are treated as a security boundary. A full production review should classify every connection path as classical, hybrid, or post-quantum depending on the complete handshake, identity binding, session-key usage, replay handling, downgrade resistance, and dependency behavior.

Consensus: Proof of Registry

Remzar does not use open-ended Proof-of-Work mining.

The consensus model is Proof of Registry. Validators must be known to the chain before they can propose blocks and earn rewards. Leader selection is deterministic and based on registry state and chain state.

The model includes:

* explicit validator registry
* validator warmup
* quarantine rules
* heartbeat renewal
* lease expiry
* dead-peer eviction
* deterministic leader selection
* deterministic failover rounds inside each 30-second slot

The purpose is to avoid an energy-race mining model while keeping block production bounded, auditable, and reproducible by nodes.

Interactive CLI System

Remzar is operated through a built-in interactive CLI menu system. The menu is shown on the Remzar About page:

https://www.remzar.com/about.html

The operator runs the Windows executable and selects a numbered option from the menu. The goal is to keep the full node workflow inside one application instead of requiring separate wallet software, explorer tools, database tools, or external scripts.

Current menu operations include:

1. Setup Database
2. Generate New Wallet
3. Start Node
4. View Blockchain Console
5. Send Remzar Coin
6. Receive Remzar Coin
7. View Participant Status
8. Check Wallet Balance
9. List Wallets
10. Create Certificate / NFT / RWA Certificate
11. Send Chat over P2P
12. Send File over P2P
13. Wallet Utilities
14. Backup Wallet
15. Debug / Validate Wallet Storage Keys
16. Export Debug Logs
17. Audit Report
18. Optional Game Module
19. FAQ / Built-in User Manual
20. Safe Exit

Examples:

Press 2 to create encrypted wallets.
Press 3 to start the node.
Press 4 to view the live blockchain console.
Press 5 to send coins.
Press 17 to export a chain audit report.
Press 19 to open the built-in user manual.

This CLI system is part of Remzar’s design goal: a self-contained L1 blockchain node that can be operated locally from one executable.

The goal is to make the full node lifecycle available from one local application.

Wallet System

Remzar wallets are encrypted local wallet files.

The wallet system uses:

* ML-DSA-65 keypairs
* encrypted wallet files
* passphrase protection
* Argon2id passphrase hardening
* AES-GCM authenticated encryption
* zeroization discipline for sensitive buffers
* wallet addresses derived from public-key commitments

Wallet generation, wallet listing, balance checks, backups, transaction signing, and wallet validation are built into the CLI.

Block and Transaction Model

Remzar uses bounded validation rules and fixed protocol limits.

The block batch model is:

1. Transactions are created and serialized deterministically.
2. Transactions are hashed into 64-byte transaction IDs.
3. Transaction IDs are committed into a Merkle root.
4. The Merkle root is signed once with ML-DSA-65.
5. Peers verify leader eligibility, block bounds, Merkle commitment, signature, and state transition.

This keeps verification simple and auditable.

Auditability

Auditability is built into the node.

The operator can:

* inspect chain state locally
* view live chain activity
* export logs
* export JSON/PDF-style audit reports
* verify selected block ranges
* inspect transaction and block data
* produce local records without relying on a centralized explorer

This is intended for operators, merchants, organizations, and technical reviewers who want local verification instead of hosted infrastructure.

Certificate / NFT / Data Anchoring Utility

Remzar includes a Certificate / NFT / RWA-style utility path.

The purpose is data anchoring and receipt generation.

The intended model is:

1. Hash a file or data object.
2. Submit a record to the chain.
3. Create a receipt or certificate.
4. Verify the record later against committed chain data.

Large files are not intended to be stored directly in the L1 block body. The chain stores hashes, commitments, and records for verification.

Tokenomics

Native asset: REMZAR
Ticker: ZAR
Maximum supply: 200,000,000 ZAR

Current configuration:

* no protocol-level premine
* no founder allocation configured
* no treasury mint configured
* no staking bucket configured
* no gaming supply bucket configured
* issuance comes from validator block rewards only
* genesis reward is 0 ZAR

Reward schedule:

Genesis: 0 ZAR
Step 1: 20 ZAR per block for 500,000 blocks
Step 2: 10 ZAR per block for 500,000 blocks
Step 3: 5 ZAR per block for 500,000 blocks
Step 4: 2 ZAR per block for 500,000 blocks
Stabilized tail: 1 ZAR per block until the maximum supply is exhausted

When the maximum supply cap is reached, block rewards stop permanently.

Current Release Status

Current status:

* working private chain/demo exists
* solo-founder implementation
* Windows executable at launch
* Linux, macOS, and Docker are future targets
* no public GitHub repository at this time
* binary access before public launch is permission-based
* planned public launch date is 2026-06-26

How controlled access works:

1. Contact the founder by email.
2. Request access as a serious node operator or technical reviewer.
3. If approved, receive the executable package.
4. Run the Windows .exe.
5. Follow the interactive CLI menu.
6. Generate a wallet, start a node, connect to peers, and use the built-in tools.

Networking

Remzar uses a libp2p-based peer-to-peer networking layer for peer discovery, gossip, request/response exchange, peer identity, and transport multiplexing.

Default node port: 36213

Public bootstrap information will be published closer to launch. During the private working/demo stage, bootstrap access is controlled.

Security Status

Remzar is a working blockchain implementation, but it is still a new network and should be treated carefully.

Important notes:

* Remzar is not described as “quantum-proof forever.”
* No investment claim is made.
* No profit claim is made.
* No token sale is announced here.
* No external third-party security audit is claimed in this announcement.
* Operators should test carefully and use the software at their own risk.
* The full system should be reviewed end-to-end, including cryptography, serialization, networking, storage, key handling, consensus logic, and release binaries.

Links

Website:
https://www.remzar.com/

Contact:
[remzarchain@gmail.com]

Whitepaper:
Available on the Remzar website.

Closing

Remzar is a single-binary Rust Layer-1 blockchain built around local operation, Proof of Registry consensus, post-quantum-oriented cryptographic components, encrypted wallets, bounded validation, peer-to-peer utilities, data anchoring tools, and built-in auditability.

This thread is for technical discussion, implementation feedback, node operation questions, and public launch updates.

No hype. No investment claims. No token sale announcement. This is a technical announcement for a working L1 blockchain implementation.

Thanks for the comment. I understand the concern, and I will address it directly.

For any new blockchain project, especially one that is currently distributed as an executable during a private/pre-launch stage, it is reasonable for people to ask about safety, verification, explorer access, public data, and source availability. I do not take that personally.

That said, calling it “malware” is not accurate. Remzar is a working Rust-based Layer-1 blockchain implementation. It is not a token on another chain, and it is not a theoretical whitepaper-only project. It has its own node runtime, wallet system, peer-to-peer networking, block production, transaction handling, RocksDB-backed local storage, local chain inspection tools, audit export tools, and interactive CLI interface.

To be clear about the current status:

* Remzar is currently in a private working/pre-launch stage.
* Early binary access is controlled and intended for serious technical reviewers and node-operator testing. If not its already months into its stages....
* I am not claiming a public GitHub repository at this stage.
* I am not claiming a completed third-party security audit at this stage.
* I am not asking anyone to blindly trust or run software without their own checks.
* Anyone testing the executable should run it in a VM/sandbox first, scan it, inspect its network behavior, review hashes/checksums when provided, and treat it like any other new blockchain binary.

The reason the first launch target is a Windows executable is practical: the goal is to make full-node operation simple enough that a non-developer can run a node, create a wallet, inspect the chain, send transactions, export reports, and use the system from one local application. I also have Linux/Docker built and ready but not intended to be used as the .exe good enough, but the first operator experience is designed around a single interactive executable.

On the explorer point: Remzar does not currently have a public hosted web explorer like Bitcoin block explorers or Etherscan-style websites. That is fair to point out.

However, Remzar have a built-in local explorer and audit functionality inside the node itself and that is the whole point of remzar. The design is not based on forcing users to trust a third-party hosted explorer. The operator can inspect chain activity directly from the local node.

Menu 4 provides the local blockchain console:

╭─────────────────────────────╮
│ Remzar Blockchain Console
├─────────────────────────────┤
│ [1] Live Chain View (real-time)
│ [2] Display Latest Block
│ [3] Display Last 50 Blocks
│ [4] Display Genesis Block
│ [5] Search Block Range
│ [6] Exit to Main Menu
╰────────────────────────────╯

Here is a [1] Live Chain View (real-time) example;

2026-06-13T11:31:26Z accepted: < | block: 10 | txs: 3 | reward: 20/199999800 | hash: c7f791b0a242bb0af316fe59bfcecfcf...9be6641b4f5c1ee3f8d19f9f182311be
2026-06-13T11:31:55Z minted: > | block: 11 | txs: 2 | reward: 20/199999780 | hash: fb665d91120a534dc86bbe033a5c7a95...a01373a31410fea98e01e2365988b0b1
2026-06-13T11:32:26Z accepted: < | block: 12 | txs: 1 | reward: 20/199999760 | hash: 5d90af2f6f3e636ab9e82099d5ff24c1...15d98750c7199185e0180fb150bcd125
2026-06-13T11:32:56Z accepted: < | block: 13 | txs: 3 | reward: 20/199999740 | hash: 3a091de8402eea0de9e9230c4aab79ed...5572e3beeaeee1e2c9bbe28456ecc62f
2026-06-13T11:33:25Z minted: > | block: 14 | txs: 1 | reward: 20/199999720 | hash: 125bb32a0f03bfade9a1f143481a52d9...2f93f353963f54df95e447602525d06b
2026-06-13T11:33:56Z accepted: < | block: 15 | txs: 2 | reward: 20/199999700 | hash: c740a55322cdeff0a2e228751c6f30eb...a3468c9931d67a6aae01d78e1dbba9e7
2026-06-13T11:34:26Z accepted: < | block: 16 | txs: 1 | reward: 20/199999680 | hash: 19441d2fca49d7b83080fe313a61545e...75cf3691631117999fc41bea6ff3a36e
2026-06-13T11:34:56Z accepted: < | block: 17 | txs: 1 | reward: 20/199999660 | hash: dbda87a8e4bf36f7429fb286fb6cce78...4d05008f18313a7277a3663cb2efbfd3
2026-06-13T11:35:26Z accepted: < | block: 18 | txs: 1 | reward: 20/199999640 | hash: fbad1d389502ed61bc2caae22914688e...9f03caca36d40e720faa59a7345505a6
2026-06-13T11:35:56Z accepted: < | block: 19 | txs: 2 | reward: 20/199999620 | hash: 887eedaeff7b94ded4c2f2200164ec32...0c07119ac019bf353c7aa2959561911b
2026-06-13T11:36:25Z minted: > | block: 20 | txs: 2 | reward: 20/199999600 | hash: 48a07165efcb7be1f2deece182134ed5...b411e8d09fcf2b3871e96782f6fdf135
2026-06-13T11:36:56Z accepted: < | block: 21 | txs: 2 | reward: 20/199999580 | hash: 81de66c5bbe72301b40bf27d6aeffe86...7296c675651e6f6e1e6ead478ac9d954
2026-06-13T11:37:26Z accepted: < | block: 22 | txs: 1 | reward: 20/199999560 | hash: f92038d2adf56ce6d70105383782ab92...19e4c42a21479c88cf8db3006548d9a7
2026-06-13T11:37:56Z accepted: < | block: 23 | txs: 2 | reward: 20/199999540 | hash: d8dacecf37767d2dbb5909308357f815...95414b62015c5dcb8d2559acc0af7fe9
2026-06-13T11:38:26Z accepted: < | block: 24 | txs: 1 | reward: 20/199999520 | hash: b54a08b5660c9d2c0d9963588c66dc6f...890718bfc25ebd31b4895426555914d2
2026-06-13T11:38:56Z accepted: < | block: 25 | txs: 2 | reward: 20/199999500 | hash: 92f4c32431b486c6fbd6ce5ed4b7350a...880b837b30a83f25cecdcc73f28f0b5b
2026-06-13T11:39:26Z accepted: < | block: 26 | txs: 1 | reward: 20/199999480 | hash: 7ffffc36416c23187d5976d66539c584...4bc6950e76f312f8f055a27b2d1b90a2
2026-06-13T11:39:56Z minted: > | block: 27 | txs: 1 | reward: 20/199999460 | hash: 28c6c2834c08150edfb837949c71f1d6...2796f20c829148a283e63fd623bd08c6
2026-06-13T11:40:25Z accepted: < | block: 28 | txs: 1 | reward: 20/199999440 | hash: 5691283d4949d453025c328447d93224...217ddc97cca579af5b1fbe6dba26dde2
2026-06-13T11:40:56Z accepted: < | block: 29 | txs: 2 | reward: 20/199999420 | hash: c987bbb8ac9f60b46204e63163f5b849...4d20ba00300552ae60cdea91ae4321e7
2026-06-13T11:41:25Z accepted: < | block: 30 | txs: 2 | reward: 20/199999400 | hash: 4592b65df7a210bbb9e9cce8916606a4...6fa5d2e6a3b0d49e344294ec97000d61
2026-06-13T11:41:56Z accepted: < | block: 31 | txs: 2 | reward: 20/199999380 | hash: 16370be0a7fda8986106bf87ac33da7b...00234c028ac5fdfbaea70b8768ce8629
2026-06-13T11:42:26Z minted: > | block: 32 | txs: 1 | reward: 20/199999360 | hash: 91116eb009c5a4dc733605bd685275ee...1ce6c1662e2a20d8e2fca1db1055d04c
2026-06-13T11:42:55Z accepted: < | block: 33 | txs: 2 | reward: 20/199999340 | hash: ef9aa3ac81dddf44df60895e2cfc105e...a0f55e511803bbecd180f3ef05186bf2
2026-06-13T11:43:25Z accepted: < | block: 34 | txs: 1 | reward: 20/199999320 | hash: ee516ff86fcfe0d2ca9e4ea1ea6e44c4...4a09752358bfc368060433e3b4ff9279
2026-06-13T11:43:56Z minted: > | block: 35 | txs: 2 | reward: 20/199999300 | hash: 16221103227a323194b2babdd748af30...37905c7a24a8113e36da748e4b2bfbd1
2026-06-13T11:44:26Z accepted: < | block: 36 | txs: 1 | reward: 20/199999280 | hash: a44852e831c45f7bc8d9b326ada3ef3c...9d370532e3a95719c65beaa3d3a8d9d6
2026-06-13T11:44:56Z accepted: < | block: 37 | txs: 1 | reward: 20/199999260 | hash: 9b5b6abb29ee12b0372387738168930e...86d3c91edd49b66848d15bfad68eafa2
2026-06-13T11:45:26Z accepted: < | block: 38 | txs: 1 | reward: 20/199999240 | hash: 5c08300553e93c5e6f80aa9ab9a01367...63cb6c7e694fa0f5b94a500ed849c198
2026-06-13T11:45:56Z accepted: < | block: 39 | txs: 2 | reward: 20/199999220 | hash: 3045f210045c89b1f1a5b94970d2e686...f29cf4b1909d678d124c12d15a3d1aa8
2026-06-13T11:46:26Z accepted: < | block: 40 | txs: 2 | reward: 20/199999200 | hash: 6a4d253378a7d58358c4385d62aa222a...c159e28b801e5bdb1b68f6a93b84d033
2026-06-13T11:46:56Z minted: > | block: 41 | txs: 2 | reward: 20/199999180 | hash: af142511ed1f497b51668538d2ef6599...286b4163a847f29b6e1bbabd1e5e4b62

Lets move on to Menu 5;
Menu 5 — Sending Remzar Coin
To show that the transaction system is not only a menu label, here is the actual send flow from Menu 5.
Menu 5 supports:
╭──────────────────────────────────╮
│ Remzar Coin Send System
├──────────────────────────────────┤
│ [1] Send to Single Public Recipient
│ [2] Send to Private Receive Address
│ [3] Send to Multiple Public Recipients (2-10)
│ [4] Exit to Main Menu
╰──────────────────────────────────╯
Example send operation:
Enter your command choice (0=menu, 1-20): 5
Blockchain has already started.

Do you want to send coins? (yes/no): yes

Enter your wallet address (sender):
rfbebd3fcdd2271d09d5a4cdffd05b0e5ea8787079dc1084b9d874e9d460f4b532a639c7a4acf3b 285b6a0c45043bf6a0b76b240ed977e73e28f619fe3fbdf4c7

Enter passphrase for this wallet: [hidden]
Confirm your passphrase: [hidden]

Select Send Mode:
  [1] Send to Single Public Recipient
  [2] Send to Private Receive Address
  [3] Send to Multiple Public Recipients (2-10)
  [4] Exit (Back to Menu)

Enter choice (1-4): 1

Enter recipient's public address:
r12634eed48c566aad04b4a708ba7c874f016d30297f955ab78883ed4da26ff936b321b591eb7b1 a2297d0a124c5eddf24aaa5a7c3643812e4a5055e430880bdb

Enter amount to send:
2.44445
The node then displays the final confirmation:
You are about to send 2.44445000 ZAR from:

  rfbebd3fcdd2271d09d5a4cdffd05b0e5ea8787079dc1084b9d874e9d460f4b532a639c7a4acf3b 285b6a0c45043bf6a0b76b240ed977e73e28f619fe3fbdf4c7

to public recipient:

  r12634eed48c566aad04b4a708ba7c874f016d30297f955ab78883ed4da26ff936b321b591eb7b1 a2297d0a124c5eddf24aaa5a7c3643812e4a5055e430880bdb

Do you want to proceed? (yes/no): yes
Result:
Transaction queued & broadcast:

2.44445000 ZAR

from:
rfbebd3fcdd2271d09d5a4cdffd05b0e5ea8787079dc1084b9d874e9d460f4b532a639c7a4acf3b 285b6a0c45043bf6a0b76b240ed977e73e28f619fe3fbdf4c7

to:
r12634eed48c566aad04b4a708ba7c874f016d30297f955ab78883ed4da26ff936b321b591eb7b1 a2297d0a124c5eddf24aaa5a7c3643812e4a5055e430880bdb
This shows the actual user-side send flow:
╭────────────────────────────────╮
│ Menu 5 Transaction Flow
├─────────────────────────────────┤
│ [1] Start from the running node
│ [2] Unlock sender wallet with passphrase
│ [3] Choose public, private, or multi-recipient send
│ [4] Enter recipient address
│ [5] Enter amount
│ [6] Confirm transaction
│ [7] Queue and broadcast transaction
│ [8] Verify later through Menu 17 audit export
╰──────────────────────────────────╯
Now the important part is that this same send appears later in the local audit export.

Here is the larger system menu to show the scope of what is already built into the single executable:

╭────────────────────────────────╮
│ Remzar Management
├────────────────────────────────┤
│ [1] Setup Database
│ [2] Generate New Wallet
│ [3] Start Node
│ [4] View Blockchain Console
│ [5] Send Remzar Coin
│ [6] Receive Remzar Coin
│ [7] View Participant Status
│ [8] Check Wallet Balance
│ [9] List Wallets
│ [10] Create Certificate / NFT / RWA Certificate
│ [11] Send Chat over P2P
│ [12] Send File over P2P
│ [13] Wallet Utilities
│ [14] Backup Wallet
│ [15] Debug / Validate Wallet Storage Keys
│ [16] Export Debug Logs
│ [17] Audit Report
│ [18] Optional Game Module
│ [19] FAQ / Built-in User Manual
│ [20] Safe Exit
╰──────────────────────────────────╯

Some examples of what the executable currently includes:

1. Wallet system
   Remzar can generate encrypted wallet files, create single wallets, create multiple wallets, generate private receive addresses, and create wallet QR codes. Wallets are protected with passphrase-based encryption and are stored locally.

2. Node operation
   A user can start the node from inside the same application. The node handles peer-to-peer networking, chain state, block handling, local storage, and synchronization behavior.

3. Transactions
   Menu 5 allows sending ZAR to a single public recipient, to a private receive address, or to multiple public recipients.

4. Local balance checking
   Menu 8 allows local wallet authentication and balance checking.

5. Built-in chain console
   Menu 4 allows the operator to inspect live chain activity, latest blocks, last 50 blocks, genesis block, and selected block ranges.

6. Certificate / NFT / RWA anchoring
   Menu 10 supports certificate/NFT-style records, legal document records, software release records, Digital I.D.-style records, RWA-style certificates, verification, transfer, and export functions. The purpose is data anchoring and proof generation, not storing large files directly inside the L1 block body.

Here is Menu 10 directly from the node interface:

╭──────────────────────────────────╮
│ Certificate / NFT Creation (Mint NftMintTx)
├───────────────────────────────────┤
│ Do you want to create a new certificate / NFT?
│
│ Select certificate / category type:
│
│ [1] Standard NFT (art / media / generic)
│ [2] Badge / Trophy (1-of-1 token)
│ [3] Legal document
│ [4] Certificate
│ [5] Software release
│ [6] Verify existing certificate / NFT
│ [7] Transfer certificate / NFT to another wallet
│ [8] Export certificate / NFT from chain
│ [9] Digital I.D
│ [10] RWA / Real-World Asset Certificate
│ [11] Cancel (return to main menu)
╰───────────────────────────────────╯

This is not just a basic “mint image” menu. It is a broader data-anchoring path. The intended model is:

╭──────────────────────────────────╮
│ Remzar Data Anchoring Model
├───────────────────────────────────┤
│ [1] Hash a file, certificate, document, or record
│ [2] Submit the commitment to the chain
│ [3] Create a local receipt / certificate
│ [4] Verify the record later against chain data
│ [5] Export or transfer the record when needed
╰───────────────────────────────────╯

Large files are not intended to be stored directly in the L1 block body. The chain stores hashes, commitments, transaction records, and verification data.

7. P2P utilities
   Menu 11 supports signed off-chain P2P chat. Menu 12 supports signed P2P file transfer/chunking.

Menu 17 provides local audit export:

╭───────────────────────────────────╮
│ Remzar Audit Report
├────────────────────────────────────┤
│ Export selected block ranges
│ Export chain data as JSON
│ Export chain data as PDF
│ Verify selected block ranges locally
│ Inspect committed block and transaction data
╰────────────────────────────────────╯

So when I say “explorer,” I am referring to the built-in node-side explorer/audit tools, not a public hosted web explorer. A public web explorer can be added later, but the first design priority is local verification by the operator.

8. Audit reports
   Menu 17 exports selected block ranges as JSON or PDF audit reports. This is important because the operator does not need a centralized website to inspect what their local node has accepted.

Menu 17 — Local Audit Report / Built-In Chain Explorer

Menu 17 is the second part of Remzar’s built-in explorer system. Menu 4 gives the operator a live console view, latest block view, genesis block view, and block-range search. Menu 17 goes deeper by exporting selected block ranges into JSON or PDF audit reports.

This is important because the chain does not require a third-party hosted explorer for local verification. A node operator can export block data directly from the local chain database.

Example audit command:

Enter your command choice (0=menu, 1-20): 17
Do you want to audit your blockchain? (yes/no): yes

Audit reports directory is ready:
data\005.audit_reports

Enter the directory path where you want to store the audit reports:
C:\Users\...\Remzar-Public\data\005.audit_reports

Enter the FULL path to your blockchain database folder:
C:\Users\...\Remzar-Public\data\002.blockchain_db

Enter block index or range:
15300-15325

Select audit export format:
  1) Export as JSON
  2) Export as PDF
  3) Back to menu

Enter choice (1–3): 1

Wrote:
data\005.audit_reports\audit_report.json

For this demonstration, I exported blocks 15300 through 15325. The audit report contains:

```json
{
  "chain_id": "remzar",
  "block_span": 26,
  "total_tx": 35
}
```

The real JSON file contains the full wallet addresses, block hashes, previous hashes, Merkle roots, and guardian signatures. For forum readability, I am truncating long fields below using a `first 32 characters ... last 32 characters` display format. The values are not shortened in the actual JSON audit report.

Below are several examples from the exported block range.

```json
{
  "index": 15300,
  "timestamp": 1781315932,
  "size": 7467,
  "tx_count": 2,
  "transactions": [
   {
   "kind": "reward",
   "sender": null,
   "receiver": "r57b4f409c850c1b5cc672bcc228eb7f...e0020c06d156ae5fcba3591299b19c26",
   "amount": 2000000000
   },
   {
   "kind": "register_node",
   "sender": null,
   "receiver": "rfbebd3fcdd2271d09d5a4cdffd05b0e...b76b240ed977e73e28f619fe3fbdf4c7",
   "amount": null
   }
  ],
  "current_hash": "21b1572e7509c1937c2b9b0be5584c0d...40f5a146993f1d64d627756fc30f86ec",
  "previous_hash": "c5e99134a145846a4f277ff335fd5783...2f431e2a3aa7dd7a175625e161c78069",
  "merkle_root": "ceaf21e7b3978a2e62e63dc6aad42679...8828eecb335131d8a0892ca569705cd9",
  "guardian_sig": "9bb8af5ec93a0428ad7607a40daba26e...e3f200000000000000000b10151d242f"
}
```

```json
{
  "index": 15301,
  "timestamp": 1781315980,
  "size": 7467,
  "tx_count": 2,
  "transactions": [
   {
   "kind": "reward",
   "sender": null,
   "receiver": "r57b4f409c850c1b5cc672bcc228eb7f...e0020c06d156ae5fcba3591299b19c26",
   "amount": 2000000000
   },
   {
   "kind": "register_node",
   "sender": null,
   "receiver": "r57b4f409c850c1b5cc672bcc228eb7f...e0020c06d156ae5fcba3591299b19c26",
   "amount": null
   }
  ],
  "current_hash": "64a53c65ec6618cf54fbb2ae21ffadb5...6a10aad0612cda68042afed87ddd3ef2",
  "previous_hash": "21b1572e7509c1937c2b9b0be5584c0d...40f5a146993f1d64d627756fc30f86ec",
  "merkle_root": "6825deaef0e355d4022dae721544a42d...ad0136d71c74967193deca99bd775675",
  "guardian_sig": "006d7b0f0a177420cc27120bb15187c7...00000000000000000000090f151d2127"
}
```

```json
{
  "index": 15302,
  "timestamp": 1781316026,
  "size": 7333,
  "tx_count": 1,
  "transactions": [
   {
   "kind": "reward",
   "sender": null,
   "receiver": "rfbebd3fcdd2271d09d5a4cdffd05b0e...b76b240ed977e73e28f619fe3fbdf4c7",
   "amount": 2000000000
   }
  ],
  "current_hash": "e5c567e011f0f50cda7fecbed73780f6...c2f29abd7e3aadba29c5dde2690ea9a3",
  "previous_hash": "64a53c65ec6618cf54fbb2ae21ffadb5...6a10aad0612cda68042afed87ddd3ef2",
  "merkle_root": "5c33ec42eb18302a23d96ae9bd835c1b...897624ad4d34eb9cfc900f978f38a7a6",
  "guardian_sig": "b702a09bb79f26e6d7d77c72c2f5a8c2...00000000000000000000070a0f13171c"
}
```

```json
{
  "index": 15303,
  "timestamp": 1781316058,
  "size": 7332,
  "tx_count": 1,
  "transactions": [
   {
   "kind": "reward",
   "sender": null,
   "receiver": "r30c4bf3c4e81576623aed6ec5dc02945...0f32958ee0f3880481eca50f285915fe",
   "amount": 2000000000
   }
  ],
  "current_hash": "37a83d6c1f4d7c2541137493482d5d95...1eb3e8dcb4eaf3f986ee429fc2a0df3c",
  "previous_hash": "e5c567e011f0f50cda7fecbed73780f6...c2f29abd7e3aadba29c5dde2690ea9a3",
  "merkle_root": "b917d3c3f5a1a9d8381be31b4b6e66f0...52399b5d1e93232c860c63e67dbb0c9b",
  "guardian_sig": "ab5f48a3940e516612ca8888afd6485c...000000000000000000000a101722262c"
}
```

```json
{
  "index": 15304,
  "timestamp": 1781316116,
  "size": 7332,
  "tx_count": 1,
  "transactions": [
   {
   "kind": "reward",
   "sender": null,
   "receiver": "rfbebd3fcdd2271d09d5a4cdffd05b0e...b76b240ed977e73e28f619fe3fbdf4c7",
   "amount": 2000000000
   }
  ],
  "current_hash": "a0e3bb582d44ee307f772255aac5b533...51ac0086cf9c902d82a79fa9bbf91e53",
  "previous_hash": "37a83d6c1f4d7c2541137493482d5d95...1eb3e8dcb4eaf3f986ee429fc2a0df3c",
  "merkle_root": "42cfd99dca03f3980af26c08e87a8e5b...7646b98b8de5c72a169b687c0613ea67",
  "guardian_sig": "4f28a50b0827b30bf4f838592403c0a3...00000000000000000000070c15212b2c"
}
```

```json
{
  "index": 15305,
  "timestamp": 1781316147,
  "size": 7332,
  "tx_count": 1,
  "transactions": [
   {
   "kind": "reward",
   "sender": null,
   "receiver": "rfbebd3fcdd2271d09d5a4cdffd05b0e...b76b240ed977e73e28f619fe3fbdf4c7",
   "amount": 2000000000
   }
  ],
  "current_hash": "bd6797bdf48cb13629630d1a8776779a...517e111279d735491eaea654d9786205",
  "previous_hash": "a0e3bb582d44ee307f772255aac5b533...51ac0086cf9c902d82a79fa9bbf91e53",
  "merkle_root": "a7253b7d90e9cdda052eed502a5558b3...392fa275ecca441d1a340dcdd7772be9",
  "guardian_sig": "97b7bb3fe9f48f023e60f36c6cc8af07...000000000000000000000b11171b252b"
}
```

The first blocks above show normal chain production, validator rewards, node registration activity, block hashes, previous-block linkage, Merkle commitments, and guardian signatures.

Now here is the stronger proof example: block 15319. This one demonstrates that Menu 5’s send feature is not just a displayed menu option. It appears inside the exported chain audit as an actual transfer transaction.

```json
{
  "index": 15319,
  "timestamp": 1781316670,
  "size": 7600,
  "tx_count": 2,
  "transactions": [
   {
   "kind": "reward",
   "sender": null,
   "receiver": "r57b4f409c850c1b5cc672bcc228eb7f...e0020c06d156ae5fcba3591299b19c26",
   "amount": 2000000000
   },
   {
   "kind": "transfer",
   "sender": "rfbebd3fcdd2271d09d5a4cdffd05b0e...b76b240ed977e73e28f619fe3fbdf4c7",
   "receiver": "r12634eed48c566aad04b4a708ba7c87...4aaa5a7c3643812e4a5055e430880bdb",
   "amount": 244445000
   }
  ],
  "current_hash": "6ff56c8e6cc539a74ba18bd5095019b6...d22468884e80a8e961e076e221a33ef9",
  "previous_hash": "036e0cea522a3a99a1ac3daf044c124b...8dcf9e0e9c71dd855bf82694efd12c40",
  "merkle_root": "c07e16ec549db9fed7cb0e31f507b4b3...b91fba2fa5d39cac604e7c62134f5126",
  "guardian_sig": "15f90dfdb4cc23c2eee66a9d81c5b256...00000000000000000000070d101a2227"
}
```

Block 15319 is useful because it demonstrates more than block production. It shows the send feature working inside an audited block.

The block contains:

* one validator reward transaction
* one normal transfer transaction
* sender address
* receiver address
* transfer amount
* previous block hash
* current block hash
* Merkle root
* guardian signature

The transfer amount is `244445000` atomic units, which corresponds to the earlier demonstrated send of `2.44445000 ZAR`.

So Menu 17 is not just a debug screen. It is a built-in local audit/export tool. It lets an operator select a block range, export the chain data, and verify actual block contents without relying on a centralized explorer website.

A hosted public explorer can still be added later, but Remzar already includes local chain inspection and JSON/PDF audit export inside the node itself.

The philosophy of Remzar is simple: one energy-efficient, post-quantum-oriented Layer-1 chain, operated from one local executable, with bounded validation, deterministic Proof of Registry consensus, transparent issuance, and local auditability.

I agree that more public visibility will improve trust. Public screenshots, release hashes, test outputs, public bootstrap details, a hosted explorer, reproducible builds, source release, and third-party security review are all valid things for the community to ask for as the project moves from private testing toward public launch.

But the current private executable access is not “privately spreading malware.” It is controlled early access to a working blockchain implementation before public launch. The correct technical criticism is that the project is early but ready with more public verification material.

I welcome technical review, but I want the criticism to be accurate. Remzar is a real working L1 blockchain implementation, period.