Documentation

NERO is a workspace for your wallet, your data, and what you choose to reveal. It has four tools and one rule: it describes what it does, and nothing more. This page says what each tool does, what it stores, where requests go, and where each protection ends.

Overview

No account or sign-up is needed. Read-only lookups and local notes do not require a wallet. No seed phrase or private key is requested. This application is unaudited.

Privacy explanation

Public Solana accounts, balances, transfers and program instructions remain public. Connecting a wallet or hiding a balance on screen does not change the blockchain.

What is never claimed

Anonymity, untraceability, zero-knowledge protection, mixing, private execution and private trading are not implemented. Fresh Solana addresses do not provide these guarantees.

Wallet Inspector

Address

Solana addresses are Base58-encoded public keys. The inspector reads the SOL balance with getBalance, account information with getAccountInfo, and recent signatures with getSignaturesForAddress. One SOL equals 1,000,000,000 lamports. Executable accounts identify programs.

Recent activity

The latest ten signatures are shown with their confirmation state. This is a recent activity view, not an exhaustive transaction history. The provider may limit historical data.

Transaction

Look up a transaction signature with getTransaction to see its slot, execution status and fee. Supported transaction versions include legacy and version 0.

Proposed call

Solana programs receive transaction instructions. Simulation can use simulateTransaction to report logs and execution errors before signing. The simulation and signing controls are not connected in this edition.

Allowances

Solana SPL token accounts may name a delegate with a delegated amount. getTokenAccountsByOwner reads token account information. Revocation is not connected. The inspector never signs or broadcasts a transaction.

Provider errors are shown explicitly. No invented balances, transactions or token prices are substituted.

Notes Vault

Key hierarchy

passphrase ──PBKDF2-HMAC-SHA-256 (600,000 iterations, 128-bit random salt)──▶ KEK
KEK        ──AES-256-GCM (96-bit random IV, AAD = vault header)──▶ wraps the 256-bit vault key
vault key  ──AES-256-GCM (fresh 96-bit random IV per save, AAD = record id)──▶ one note per record

• The work factor is the OWASP Password Storage Cheat Sheet figure for PBKDF2-HMAC-SHA256. Salt length follows NIST SP 800-132, IV length NIST SP 800-38D. The passphrase is normalised with Unicode NFKC before derivation.
• Every random value comes from crypto.getRandomValues. A new IV is generated for every encryption, including every edit of the same note.
• A note’s title, text, linked address or transaction hash, network and timestamps are one JSON document, sealed as one ciphertext. The record id is bound as additional authenticated data, so a ciphertext cannot be moved to another record.
• The vault key is a non-extractable CryptoKey. The passphrase, the derived key and the plaintext are never written to storage and never placed in a request.
• Locking drops the key and the decrypted notes from memory; an unsaved draft is sealed first. The vault also locks itself after the idle time set in the Privacy Panel.
• Changing the passphrase re-wraps the vault key under a new salt; note records are untouched.

What you must know

• A forgotten passphrase cannot be recovered. NERO never sees it, so nobody can reset it.
• Clearing browser data removes the vault. An exported backup is the only copy that survives.
• Encryption protects the stored notes. It does not protect an unlocked vault from a compromised device, a malicious browser extension or a script running in the page.
• Record count, each ciphertext’s size (plaintext + 16 bytes), the KDF parameters and the salt are visible to anyone with the browser profile.

Limits: 160 characters per title, 60,000 characters per note (256 KB sealed), plain text only. Note text is always rendered as text, never as markup.

Backup format

An export is a JSON document (*.marblevault.json) holding exactly what IndexedDB holds, base64-encoded. It can be exported while the vault is locked, because it is ciphertext. Only the passphrase opens it.

{
  "format": "marbleprivacy-vault-backup",
  "version": 1,
  "exportedAt": "ISO-8601",
  "vault": {
    "vaultId": "uuid",
    "createdAt": "ISO-8601",
    "kdf":    { "name": "PBKDF2", "hash": "SHA-256", "iterations": 600000, "salt": "base64 (16 bytes)" },
    "cipher": { "name": "AES-GCM", "keyLength": 256, "ivLength": 96, "tagLength": 128 },
    "wrappedKey": { "iv": "base64 (12 bytes)", "data": "base64 (32 + 16 bytes)" }
  },
  "notes": [
    { "id": "uuid", "order": 1,
      "sealed": { "iv": "base64", "data": "base64 — AES-GCM(JSON{title,body,ref,tag,createdAt,updatedAt})" },
      "ciphertextBytes": 345 }
  ]
}

• wrappedKey AAD: marbleprivacy:v1:vault-key:<vaultId>:<version>:<kdf>:<hash>:<iterations>:<cipher>:<keyLength>:<ivLength>:<tagLength>
• notes[].sealed AAD: marbleprivacy:v1:note:<id>

An imported file is treated as untrusted. Before any key derivation: format id and version, vault id shape, KDF name and hash, iterations within 100,000–5,000,000, salt 16–64 bytes, cipher parameters, IV lengths, ciphertext sizes, duplicate ids, at most 5,000 notes and 96 MB. Then the passphrase must unwrap the key and every note must authenticate and decode — with each field type-checked and length-capped — before the current vault is replaced, in one transaction.

Screen Privacy

• One switch, in the sidebar and in the Privacy Panel. When it is on, balances, addresses, transaction hashes and amounts are not drawn — they are not in the page at all — until you press the reveal control next to one. Typed addresses, hashes and amounts show as dots.
• Turning it on hides again everything you had revealed one by one. Explorer links and copy buttons are concealed with the value they belong to.
• In a signing dialog the transaction details are concealed like everything else, and the sign button stays disabled until you reveal them. Nothing is signed unread.
• It is screen concealment for shared screens, recordings and screenshots. It changes nothing on any chain and nothing a provider receives.

Stealth addresses on Solana

Solana accounts are public. A fresh receiving address separates activity from an existing account but does not hide the sender, recipient, amount or timing of a transfer.

Receiving

Use a public address provided by your Solana wallet. This page does not create, retain or request private keys.

Sending

The form validates a Solana address and previews the workflow. Transaction signing and broadcasting are not connected. No funds move through this interface.

Boundaries

No stealth-payment program, registry, announcer or relayer is connected. Moving funds from a fresh address to a known wallet can connect the two accounts.

Shielded pools and private trading

No shielded-pool, private-swap or private-execution integration is connected in this edition. SOL and SPL token transfers remain public.

An integration would need verified Solana program addresses, reproducible source, a documented SDK, supported assets, scoped audit reports and tests against the deployed program. This interface makes no claim that any particular protocol satisfies those requirements.

Networks and providers

The static edition sends read-only requests directly to the selected public RPC endpoint. Providers may rate-limit or reject browser requests. When that happens, the inspector shows the error.

Private Helius credentials are not embedded in this site. A private RPC should be connected through a server relay before use.

Local data

The Notes Vault stores encrypted records in IndexedDB. Screen privacy, motion and other preferences are kept on this device. Clearing browser storage removes this local data.

A vault backup contains encrypted records. Keep the passphrase and exported backup safe; a forgotten passphrase cannot be recovered.

$NERO

$NERO · Solana

The SPL mint address has not been supplied for this edition and is not published here. No unrelated token address is presented as the official mint.

The workspace does not require token ownership. Holding a token does not change the visibility of public blockchain data.

Setup and deployment

This edition consists of local HTML pages, styles, fonts, images and JavaScript. Serve the dist directory using an HTTP server. All seven routes are included.

The Solana inspector uses public read-only RPC methods. The optional wallet connection supports an injected Phantom or Solflare provider. Sending, revocation, simulation and stealth transactions are not connected.

For a private provider, configure a server-side RPC relay and keep credentials in server environment variables. Never put RPC API keys in browser JavaScript.

Limits

• Public Solana data remains public.
• Privacy on screen does not alter blockchain visibility.
• Notes are local; clearing browser data removes them.
• RPC history may be incomplete or unavailable.
• No private transfers, swaps or stealth protocol is implemented.
• No transaction is signed or broadcast by the inspector.
• This application is unaudited.