Your wallet.
Every detail.

01. Meet Onuros Wallet

Onuros Wallet is a desktop, self-custody wallet being built for shielded Onuros payments. Self-custody means the wallet keeps the material needed to control your funds on your computer. There is no website account that holds your recovery phrase for you, and no support agent who can reset your keys.

The desktop interface is built with Qt 6. Underneath it, a C++17 wallet library handles encrypted storage, recovery, sessions, local scanning interfaces, payment planning and communication with a node. The protocol defines the canonical OCWF-248 payment format: 248 bytes for the payment itself. That figure is a format size, not the total size of every network exchange, backup or wallet file.

Shielded payments are the design target. The wallet contract keeps spending keys, recovery material and decrypted notes local. It provides owner-controlled disclosure rather than an operator master viewing key. Privacy still depends on the complete implementation, your device and how you share information.

02. Download and check your package

Start with Wallet downloads on the Ecosystem page. Read the release notes before choosing a package. A development snapshot and a qualified release are different things; this guide does not certify any download as production ready.

• Windows installer: Onuros-Wallet-Windows.exe, with Qt and compiler runtime components packaged for the desktop app.
• Windows portable package: Onuros-Wallet-Windows.zip, containing the GUI, command-line tools, node probe, runtime components and documentation.
• Linux x86_64: Onuros-Wallet-Linux.tar.gz. Use the launch instructions included in the release package.

Download the adjacent .sha256 file when supplied. Compare its hash with the package you downloaded. On Windows, PowerShell's Get-FileHash -Algorithm SHA256 can calculate a file hash. On Linux, use sha256sum. Compare the full value, not just its beginning or end.

A matching checksum checks that your file matches the published checksum. It is not a substitute for a trusted signature or a security review. The current repository describes unsigned qualification candidates. Do not bypass an operating-system warning simply because a file has an Onuros name.

Keep your operating system updated, download through the official Onuros link, and install only on a computer you control. No Android, iOS or browser-wallet release is established by the desktop documentation used for this guide.

03. Create a new wallet

Choose Create wallet on the welcome screen. Onuros Wallet handles the network configuration for you. You do not need to enter a genesis ID or configure an advanced connection to create your wallet.

1. Choose where to save your wallet. If the app asks for a file location, select a private folder on your computer. Keep existing wallet files unchanged.
2. Set and confirm your password. Use a long, unique password and enter it again when asked. Keep it somewhere secure; it protects your encrypted wallet file.
3. Save your 24-word recovery phrase. Write every word down offline in the exact order shown. This phrase is your recovery backup. Never send it to anyone or enter it on a website.
4. Confirm your recovery phrase. Complete the app's confirmation step carefully. Check your written copy before finishing wallet creation.
5. Open your wallet. Once setup is complete, continue to Overview. Check the connection and synchronization status before relying on a balance or attempting a payment.

Keep both your password and recovery backup safe. Your password unlocks the encrypted file on your computer; your 24 words let you restore the wallet if you lose access to that file.

04. Protect your 24-word recovery phrase

Your recovery phrase is the backup for the wallet's root secret. Treat the words, their spelling and their order as one secret. The current implementation uses the English recovery-word list; translating the words changes the phrase.

1. Write all 24 words offline, numbered 1 through 24. Check each word against the app's display.
2. Read your copy back in order before completing the confirmation step.
3. Store it somewhere protected from other people, water and fire. If you keep a second copy, protect that location too.
4. Keep it separate from an unencrypted password note or an unlocked computer. Avoid screenshots, email, cloud notes and support tickets.

Never enter your phrase on this website, a faucet, an explorer or a support chat. The phrase belongs only in a trusted local wallet recovery flow. Someone who obtains it may be able to recreate your wallet control without knowing the password of your existing file.

The password and phrase have different jobs. The password unlocks a particular encrypted local file. The phrase recreates the root secret. Losing the password may be recoverable with the phrase; losing both the phrase and access to every usable wallet backup may make recovery impossible.

Recovery of keys does not itself restore synchronization, transaction history, preferences or all future wallet metadata. Keep a protected encrypted-file backup as well, and follow the restore instructions for the release you use.

05. Restore or open an existing wallet

Restore with recovery phrase

1. Choose Restore with recovery phrase.
2. Choose a new local file. Keep the old file and backups unchanged.
3. Use the official wallet app for the same network as your original wallet. Network identity is configured by the app; you do not need to type a genesis ID.
4. Enter the 24 words in their original order. Check spelling and spacing if validation fails.
5. Set and confirm a new password of at least 12 characters, then Continue.

The app validates the phrase and writes a new encrypted local wallet. It does not promise immediate balances: a qualified backend must authenticate and synchronize before live ownership and spendability can be established.

Open existing wallet

Choose Open existing wallet, browse to the existing encrypted file and enter that file's password. You do not need to paste your recovery phrase to open an existing file. A wrong password, a file from another network, an unreadable file or an invalid file can prevent opening.

Do not repeatedly restore over working copies. A phrase mismatch and a file-password mismatch are different problems. First confirm which workflow you selected and preserve the original file before troubleshooting.

06. Understand the Overview screen

The sidebar contains Overview, Receive, Send, Activity, Mining Rewards, Security and Settings. Overview is the place to check wallet access, connection state and verified height before attempting a payment.

The reviewed GUI shows balance values only when a wallet is open and the connection model is ready. Authenticated network synchronization is not complete in the current qualification build, so unavailable values are expected. Do not substitute numbers from a pool dashboard for a verified wallet balance.

Verified height indicates the chain position the wallet has verified when integration is available. A remote node's advertised height alone is not proof that the wallet has scanned your payments. Opening the file, connecting to a node and completing verified synchronization are separate steps.

07. Network connection and synchronization

Onuros Wallet handles its network identity and connection configuration automatically. You do not need to enter a genesis ID, select a development endpoint or manage certificates during normal setup. Testnet funds and mainnet funds belong to different networks and are not interchangeable.

The documented node transport uses mutual TLS 1.3, trusted certificate configuration and exact network identity checks. There is no intended plaintext fallback. Chain verification is separate from transport authentication: a secure connection does not by itself make the node's chain claims correct.

Use the official app and its included network configuration. If a connection fails, check the wallet status and follow official support instructions. Never send your wallet phrase or password to a node operator or accept replacement connection settings from an unsolicited message.

The wallet contract describes checks for canonical headers, parent relationships, difficulty, proof of work, commitments and rollback consistency. Missing verification or cryptographic backend support is meant to fail closed rather than fabricate a trusted balance. In the current build, required backend integrations remain incomplete.

08. Receive a shielded payment

A completed qualified receiving workflow needs to create and verify a shielded address locally, bind it to the correct network, and scan the verified chain for payments owned by your wallet. An address identifies a payment destination; it is not your recovery phrase.

When a qualified release provides address controls, check the address inside the trusted app before sharing it. Compare the destination again if you copy it between applications, because compromised clipboard software can replace an address. Share only the intended receiving address, never recovery words or spending keys.

A sender's screenshot is not confirmation. A received payment must be recognized by your synchronized wallet and meet the applicable confirmation rules before you rely on it. The current guide cannot name a Copy address button or QR-code menu that the reviewed app does not implement.

09. Send a shielded payment

The payment architecture keeps spending material on your computer. Construction and signing are local operations; submission sends the required payment data, not your recovery phrase or password. Strict OCWF-248 encoding and proof checks are part of the protocol boundary.

In a qualified send flow, review the recipient's shielded address, network, amount, fee and remaining spendable balance before authorizing a payment. Confirm the actual fee shown by that release rather than assuming a fixed price from a website. Mining rewards still within their maturity window cannot be used to fund the send.

Submission, inclusion in a block and confirmation are different states. A request accepted by a node is not automatically a confirmed payment. If a connection fails after submission, check the wallet's verified activity before trying again; do not blindly create a second payment.

Payments recorded on the chain cannot be reversed by a support agent. A small test payment is a useful check when a production-qualified network and wallet become available. This qualification build is not suitable for real-value tests.

10. Read payment activity

The Activity screen is intended to bring together shielded transfers, pool payouts and matured solo rewards after connection and synchronization. Its current desktop content is a placeholder, so a blank screen is not evidence that a synchronized wallet has no history.

When activity is available, distinguish a locally prepared payment from a submitted payment, an included payment and a confirmed one. Incoming and outgoing amounts should be interpreted with their verification state. A chain reorganization can replace recent blocks, changing confirmations or whether a transaction remains included.

For troubleshooting, record nonsecret facts such as the app version, network and an error message. Sharing an address, transaction identifier, amount or screenshot can disclose information about your activity even when a payment protocol is shielded. Share only what is necessary and only with the intended recipient.

11. Mining rewards and the 1,080-block wait

The Mining Rewards page separates immature solo rewards from spendable rewards. Solo mining rewards mature automatically under the network's consensus rule after the 1,080-block wait. There is no separate manual claim transaction required to unlock a mature solo reward.

Why a reward can be visible but unavailable

A block reward is newly created value. Its maturity rule prevents immediate spending. Until that reward reaches the required 1,080 confirmations, it remains immature and cannot fund a payment. Seeing a reward in a history screen is not the same as having it available to spend.

The wait is measured in blocks, not a guaranteed number of hours. Block production can vary, a network can pause, and a reorganization can alter the relevant chain history. Use the wallet's verified confirmation and blocks-remaining data when implemented, rather than a wall-clock countdown.

For example, a reward shown with 1,000 confirmations has 80 confirmations remaining before a 1,080-confirmation threshold. This is an illustration of the threshold, not a promise about how a particular node counts the block of inclusion. Follow the qualified wallet's consensus-derived maturity display.

Solo rewards and pool payouts are different

A solo reward is a consensus block reward payable to the destination configured for mining. A pool payout is a shielded payment made by the pool according to its accounting and payout policy. Do not apply the solo reward's 1,080-block lock automatically to every incoming pool payment.

Pool shares, unpaid pool balance and a confirmed payout in your wallet are separate records. Consult the pool's published payout rules for minimum amounts and scheduling. The wallet cannot turn unpaid shares into an on-chain payment.

Configure the payout destination carefully

The current page shows a payout-address status and explains that the miner or pool must use your verified shielded wallet address. Do not use a recovery phrase, a random address or a destination from the wrong network. Address generation and synchronized reward history still depend on the qualified backend.

The planned history includes block height, confirmation progress, blocks remaining and pool payout transaction status. Those entries are not populated by the reviewed desktop build. No button in this guide overrides the maturity rule.

12. What protects the wallet

Local wallet storage uses scrypt password-based key derivation and ChaCha20-Poly1305 authenticated encryption. A random salt and nonce are generated during encryption. Authentication is intended to reject tampered encrypted data as well as an incorrect password, rather than silently opening corrupted secrets.

The wallet file includes network identity information and is checked against the expected network when opened. Local file-writing code uses a temporary file and an atomic installation path to reduce the risk of a partially written wallet replacing a good one. Linux private-file writes use owner-only permissions.

Secret-handling code clears sensitive buffers where implemented. Session access is time bounded, and the wallet contract separates scanning authority from spending authority. The current GUI opens a local scanning session for 30 minutes and checks expiry on a timer; this is not proof that live spending is enabled.

These mechanisms address specific threats, not every possible attack. Malware on an unlocked device, a stolen phrase, a malicious download or disclosure through screenshots can defeat protections outside encrypted storage. There is no defensible promise of “100% secure” software.

Lock before leaving the computer

Use the top-bar Lock control. When locked, the control becomes Open wallet and returns you to local authentication. Locking the wallet does not replace locking your operating-system session. Keep both the wallet and your computer protected when unattended.

13. Password changes and forgotten passwords

The password protects a local encrypted file. Changing a password does not change the 24-word phrase or make a leaked phrase safe again. Passwords should be unique, long and stored securely.

If you know your recovery phrase, the Restore with recovery phrase flow can create a separate encrypted wallet file with a new password and the same root secret. That is a new-file restore, not an in-place password rotation. Preserve your original file and backup. It does not prove that history, preferences or future account metadata are reproduced.

If you forget the file password, do not send the file or phrase to someone offering to “unlock” it. Use the official app's local restore flow when your recovery phrase is available. If both the phrase and access to usable backups are lost, support has no master password.

If the phrase itself may be exposed, a new file password is insufficient: the underlying wallet secret remains exposed. Ask for release-specific instructions through official support and use a qualified wallet/network before planning any transfer to newly generated keys.

14. Backups, recovery checks and upgrades

Keep two distinct backups: the offline 24-word phrase and a protected copy of the encrypted wallet file. The phrase backs up root-secret control; the file preserves the encrypted local wallet data saved in that build.

1. Lock and close the app before copying its encrypted file.
2. Copy it to a storage device you control. Protect the copy from access and accidental deletion.
3. Record the app version and network identity separately, without publishing your private file path or secrets.
4. Keep the original intact when checking a backup. Open a copy through the official local workflow, not a website upload.
5. Before upgrading, read release notes and take a fresh backup. Never let an unfamiliar program migrate your only wallet copy.

The current Settings security dialog is informational; it is not a completed encrypted-backup export wizard. Manually copying a closed encrypted file does not require a nonexistent Export button. A copy remains protected by its original password.

Changes in protocol parameters, storage or backend availability can affect a qualification build. A newer binary is not automatically compatible with every older wallet or network. If a release documents a migration, follow that release's instructions and retain the pre-migration backup.

15. Settings, language and accessibility

Settings groups Wallet, Mining Rewards, Preferences, account-related information, Help & Support and About. Some cards explain the intended feature rather than implement it.

• Wallet security: opens information about local recovery and key protection. It does not currently expose a working phrase reveal, password reset or backup wizard.
• Mining Rewards: the shortcut opens the reward screen and its maturity explanation.
• Reduced motion: the top-bar checkbox controls the desktop depth animation. Use it if animation is distracting or uncomfortable.
• Language: the current interface strings are English. Language switching is awaiting the completed preference backend; there is no verified list of selectable languages.
• Display units and notifications: also pending the preference backend. Do not assume a unit change or notification toggle is active.
• Additional accounts: the reviewed card describes storage protection but does not provide a completed account-management workflow.
• About: check the application version and qualification status when comparing your build with these instructions.

A future interface translation must not translate your recovery words. Keep the phrase exactly as generated regardless of the language used for menus. Website language, operating-system language and wallet preference language are separate settings.

16. Troubleshooting and safe support

Help & Support provides Copy safe report and Save safe report. The report contains nonsecret diagnostics such as app version, qualification status, platform, network, connection state, whether a wallet is open, verified height and reduced-motion state.

The report deliberately excludes recovery phrases, passwords, spending/viewing keys, wallet addresses, transaction details, tokens, TLS private keys and personal paths. Review any material you attach separately; a screenshot or copied log can disclose more than the safe report.

Contact help@onuros.com or use the official Onuros Telegram. State your release version, operating system, the screen you used and the exact nonsecret error. Onuros support does not need your recovery phrase or password.

17. Wallet terms

Shielded payment

A payment using the protocol's privacy construction rather than treating public account balances as the wallet's privacy model.

Spendable balance

Value eligible for spending after wallet verification and applicable consensus checks.

Immature reward

A solo block reward still within the consensus maturity window.

Fail closed

Rejecting or withholding an operation when required validation is unavailable or fails.

Qualification candidate

A build for testing and evaluation, not a declaration of production readiness.

Use the instructions included with your installed release if its screens differ from this guide. For help, contact help@onuros.com without sharing your password or recovery words.