Vault: Monero and Zcash, keys where they belongBoard: Settlement (private)
Moneyero
Hero Member
★★★★★
Moneyero
Activity: 0.1
Merit: honest
Online
Vault: Monero and Zcash, keys where they belong« on: today »

This is the savings screen. Your Monero wallet and your Zcash wallet live here, on your own computer, and so does the encrypted key the trading screen uses. Desktop app only: a web page must never hold keys.

How to use it, first time

  1. In Settings, create a master password. It locks everything in this screen.
  2. Open Vault › Monero and click create wallet. It shows you 25 words, once. Write them on paper. Those words are the money.
  3. To receive: click new address, give that address to the person paying you. One address per person, every time. It is one click, so there is no reason not to.
  4. To send: paste the address, type the amount, click prepare. The exact fee appears. Nothing moves until you click broadcast.
  5. Zcash works the same way, with one extra rule: there is shielded money (private) and transparent money (public). Keep it shielded. Anything transparent is shown in yellow with a shield all button.

Coin control, in plain words

Your Monero balance is really a pile of separate coins, one per payment you received. The Outputs table shows them. You can freeze a coin so the wallet never spends it (do this to any tiny deposit you did not expect: it may be someone trying to trace you). You can tick coins so the next payment uses only those. And you can churn a coin, which sends it to yourself so its past no longer touches its future. The app warns you before you combine coins in a way that reveals something.

Quote
Why not a reimplementation. Moneyero runs the official Monero and Zcash wallet software and talks to it; it does not reinvent their cryptography. The reference wallets have a decade of review behind them. Moneyero adds the supervision, the warnings and the interface.
Monero
Main treasury
★★★★★
XMR
Private by default
Online
Re: Vault — technical details: Monero« Reply #1 »

Process

You point Moneyero at the official monero-wallet-rpc binary (verify its signature from getmonero.org). It is launched bound to 127.0.0.1 with a random per-session digest login and a wallet directory inside the application data folder. Logs are captured locally. The process is stopped when the application exits.

Wallets

  • Create, open, or restore from a 25-word seed with restore height and optional seed offset.
  • Wallet files are encrypted by the wallet process with the password you choose.
  • The seed is shown once, by the wallet process, at creation. It is never stored or transmitted by Moneyero. Viewing it later requires the vault to be unlocked and is audited.

Node

  • Your own monerod or a remote node, switchable at runtime with SSL mode and trusted flag.
  • When the tunnel switch is on, the wallet is started with --proxy so the daemon connection goes through Tor.
  • Wallet height is shown against daemon height; the node warning names what a remote node can see.

Operations

BalanceTotal, unlocked, blocks to unlock, per-subaddress breakdown
ReceiveSubaddresses with labels and used or fresh state; one click for a new one
SendAddress validated, then transfer with do_not_relay to obtain the exact fee, then relay_tx after you confirm
Coin controlEvery output the wallet owns, listed. Freeze any of them out of future spends, pick exactly which ones a send may use, or churn one to a fresh subaddress of your own. Warnings before you act: merging outputs from different subaddresses proves common ownership, dust spent with real funds links them
HistoryIn, out, pending, pool and failed transfers with confirmations and lock state
MaintenanceRefresh, store, rescan
Zcash
Shielded treasury
★★★★
ZEC
Private when shielded
Online
Re: Vault — technical details: Zcash, transparent kept visible« Reply #2 »

Backend

Moneyero speaks the zcashd wallet JSON-RPC surface, which zallet, its successor, preserves. Credentials come from the vault or the node's cookie file. The node process can be started and stopped from the Vault if you provide the binary path.

Pools and addresses

  • Orchard, Sapling and transparent balances are shown separately. Transparent balance is flagged until shielded.
  • Unified (u1), Sapling (zs) and transparent (t1) address creation, with receiver types listed for unified addresses.
  • Per-address balances from the unspent sets.

Sending

  • z_sendmany with an explicit privacy policy. Default FullPrivacy. Any lower policy is a critical warning.
  • Memos only to shielded recipients.
  • Shield everything transparent in one action with z_mergetoaddress; operation status is tracked.

Keys

ImportSpending keys, viewing keys and transparent WIF keys, with optional rescan
ExportViewing keys on request (vault unlocked, audited)
Restore from seedDone in the node itself: wallet.dat for zcashd, import-mnemonic for zallet
Light client. The current backend is the full-node wallet. A lightwalletd-based client is on the roadmap; the RPC adapter is the integration seam. See known limits.
SOL signer
Trading key
★★★
SOL
Encrypted locally
Re: Vault — technical details: the trading key, encrypted locally« Reply #3 »
  • Master password → Argon2id (64 MiB, 3 passes, 1 lane) → XChaCha20-Poly1305 with a random 24-byte nonce per secret.
  • Holds API keys, RPC credentials and the Solana trading key. Monero and Zcash keys never enter it.
  • Key material is zeroised on lock. Password change re-encrypts every secret in one transaction.
  • Generate or import (base58 or solana-keygen JSON). Public key shown; secret exportable for backup, audited.
  • Signing operates on transaction message bytes in Rust; each signature is logged with a hash of the message.
  • Fund this key only with what you intend to trade. Treasury belongs in Monero or shielded Zcash.