Your wallet.
Your recovery.

1. Start with approved DGL software

Obtain a project-approved DarkGangLumonol-wallet-cli release for your operating system and processor. Confirm the release and its published checksum or signature through a trusted DGL channel before running it. Do not use an unverified attachment or substitute a standard Monero wallet for DGL.

A DGL wallet release for macOS or Windows has not been verified for this guide. Those sections show command syntax to use after a compatible release is approved. They are not download links or a claim that a supported binary is available. On a Mac, the build must match Intel or Apple Silicon; on Windows and Linux, confirm the intended architecture too.

If you need an approved release, use the project's contact details in the onboarding guide. Share your operating system and architecture, never recovery credentials.

2. Create a wallet offline

1. Use a trusted computer and a private folder outside cloud-synced folders. Open a private terminal in the approved wallet application's folder.
2. Turn off terminal recording and screen sharing. For a fully disconnected setup, disconnect the computer from the network. The --offline flag keeps the wallet from communicating with a daemon; it does not disconnect the rest of your computer.
3. Run the command for your system below. my-dgl-wallet is an example filename; choose a new name that does not overwrite an existing wallet.
4. Choose a strong, unique wallet-file password when the wallet prompts you. Keep passwords and recovery words out of command-line arguments and shell history.
5. Write down all 25 recovery words in their exact order on paper or metal. The CLI also displays a private view key: keep the whole terminal private. Do not photograph, screenshot, print through a shared printer or record this screen.
6. Record your public receiving address, seed language and the wallet's creation or restore height, if shown. If you choose an optional seed offset, preserve it securely too. Follow the backup verification steps before relying on the wallet.

A standard newly generated seed uses a blank seed offset unless you deliberately choose one. A seed offset is an additional recovery credential, not the wallet-file password. Keep any offset separate from the seed where practical, with a recovery plan that preserves both.

Linux / Terminal

After receiving and verifying the approved Linux binary, create a new wallet:

./DarkGangLumonol-wallet-cli --offline --generate-new-wallet "my-dgl-wallet"

To reopen that existing wallet later:

./DarkGangLumonol-wallet-cli --offline --wallet-file "my-dgl-wallet"

macOS / Terminal

Release availability remains unverified. First obtain a project-approved Mac build for your Intel or Apple Silicon computer. With that verified build, the command syntax is:

./DarkGangLumonol-wallet-cli --offline --generate-new-wallet "my-dgl-wallet"

To reopen the same wallet:

./DarkGangLumonol-wallet-cli --offline --wallet-file "my-dgl-wallet"

Do not bypass macOS security warnings for an unknown download. Confirm its origin and the project's verification instructions first.

Windows / PowerShell

Release availability remains unverified. After the project supplies a verified Windows build for your computer, open PowerShell in its folder and use:

.\DarkGangLumonol-wallet-cli.exe --offline --generate-new-wallet "my-dgl-wallet"

To reopen the same wallet:

.\DarkGangLumonol-wallet-cli.exe --offline --wallet-file "my-dgl-wallet"

Offline creation does not synchronize a balance or send a transaction. You do not need a daemon, VPN or mining pool to generate your address. Later, use the approved DGL network setup to synchronize and verify balances. Pool mining uses only your public address; follow the mining guide for connection requirements.

3. Restore with your recovery words

Standard seed restoration creates new local wallet files and a new wallet-file password. It does not reveal or require recovery of the old local password. Keep your existing wallet files untouched and restore into a different, unused filename.

Linux or macOS / Terminal

./DarkGangLumonol-wallet-cli --offline --restore-deterministic-wallet --generate-new-wallet "restored-dgl-wallet" --restore-height 0

Windows / PowerShell

.\DarkGangLumonol-wallet-cli.exe --offline --restore-deterministic-wallet --generate-new-wallet "restored-dgl-wallet" --restore-height 0

1. Use an approved DGL build for your system, on a trusted computer in a private terminal.
2. Enter the seed only in the wallet's interactive recovery prompt. Choose a new local wallet-file password when prompted. Do not add seed words or passwords to the command.
3. If the wallet asks for a seed offset, enter the exact offset originally used. Leave it blank only if the original wallet used no offset. A wrong offset can create a different wallet without an error.
4. Compare the restored public receiving address with your known original address before using the wallet. A matching address checks the standard seed-and-offset recovery without sending funds.

The examples use restore height 0 so a later online synchronization can scan from the beginning. If you know the original wallet's correct creation height, an earlier-or-equal height can reduce scanning. A height later than the first receipt can hide older incoming transactions. Use 0 when unsure.

An address alone cannot recover a wallet. If you have neither the seed and any required offset nor usable wallet files with their password, DGL support cannot reconstruct the private spending credentials from the address.

4. Protect your backups

Keep an offline recovery copy

Keep two offline recovery backups in separate secure locations you control. Paper is simple; a suitable metal backup can improve durability. Check every word and its order. Protect the seed from theft as carefully as the wallet itself. Preserve any required seed offset through a separate, secure recovery plan.

Never send seed words, private keys or wallet files to support or upload them to a website. Avoid plaintext notes, photos, email drafts, chat messages and cloud-synced documents.

Optional encrypted file backups

An encrypted backup can supplement the offline seed copy. Use a strong backup password that is different from the wallet-file password, and keep a separate way to recover it. Losing that password may make the encrypted backup unusable.

Create a new container file. Never choose an existing seed document as the new VeraCrypt container's filename: that overwrites the document rather than encrypting its contents. Keep the original untouched until you have verified independent recovery backups.

For wallet-file backups, close the wallet first, then preserve the wallet basename file and its associated .keys file together inside the encrypted backup. You also need the wallet-file password for file-based access. A cache or public address by itself is not a recovery backup. The seed and exact optional offset remain the primary deterministic recovery method.

Create the encrypted destination before writing any digital recovery note. When possible, write the note directly inside the mounted encrypted volume with a local editor that does not save unencrypted autosaves elsewhere. A mounted volume is accessible while unlocked: close files and eject it when finished.

Drive encryption and containers help protect stored data. They do not make a compromised computer safe, recover a lost password or replace a separate backup.

FileVault, BitLocker and LUKS protect a locked or powered-off device. Once you sign in and unlock the storage, ordinary applications can access available files. Close recovery documents and explicitly eject or unmount a separate encrypted backup when finished; closing the encryption application's window alone may leave it mounted.

Already have recovery words in Notepad or TextEdit?

1. Work privately on your trusted laptop. Make and verify an offline recovery copy before removing or replacing anything.
2. For Windows or Linux, create a new standard VeraCrypt file container using the official instructions above. On macOS, an AES-encrypted Disk Utility image is another option. Use a new filename, with a long, unique password recorded separately from the encrypted file.
3. Mount the new encrypted destination and copy your existing document inside. This does not encrypt or remove its old copies. Do not upload the document or paste its words into a website.
4. Close the document, unmount the destination, then reopen it with the backup password to privately verify the backup. Keep a second protected offline copy in a separate secure location.
5. After verification, review old plaintext files, editor session copies, trash, clipboard history and synced backups. Windows Notepad can retain session tabs; an encrypted saved file does not clear those copies. OneDrive recovery and version history may retain older copies too.

Choose an editor or secure-note tool that does not save plaintext autosaves outside the encrypted destination. See VeraCrypt's explanation of application data leaks. Never delete your only recovery copy, and do not assume SSD deletion revokes an earlier exposure.

5. Verify before cleaning up

1. Read the offline seed copy back carefully. Check its word order, language and any required offset.
2. On the trusted offline computer, restore to a new test filename using the recovery steps. Confirm that the public address matches your known wallet address. Do not send a payment as a backup test.
3. For an encrypted backup, eject it, reopen it with its backup password, and confirm its contents are readable. For a wallet-file backup, verify a separate restored copy opens with the wallet-file password and displays the expected address. Keep the original files intact during this check.
4. Confirm both offline recovery copies and any required encryption recovery keys remain accessible. Keep at least one recovery path independent of the computer and its disk.
5. Only after verification, remove unnecessary plaintext notes, screenshots, editor autosaves, clipboard entries, terminal scrollback or shell-history entries that contain secrets, and unwanted cloud copies or version history. Review your own backup and sync settings so a hidden copy is not overlooked. Never paste these records into support tools.

Deletion is not guaranteed erasure. SSDs, flash drives, snapshots, backups and cloud history may retain earlier copies. Emptying the trash or overwriting a file does not prove that every copy is gone; read VeraCrypt's wear-leveling explanation. Creating an encrypted copy later does not erase earlier plaintext. Avoid making digital plaintext copies in the first place.

If recovery words may have been exposed, encrypting the note or changing the local wallet password does not revoke those words. Treat the wallet as compromised and get guidance on securing your funds using verified software. Share only public information when asking for help.