We engineer offline key or seed generation tools that make source, entropy and output verification inspectable. We also assess whether paper is appropriate, because physical copies and one-time spending create risks software cannot remove.
The generator runs entirely in the browser with no network calls, remote fonts, analytics or runtime dependencies. A self-contained single-file build can be copied to a verified air-gapped machine and retained with its checksums.
Cryptographic random values come from reviewed platform primitives and are combined with user-supplied entropy only through a documented construction. Browser identity, operating system quality and failure responses are checked because visual randomness does not establish cryptographic entropy.
We implement the target coin’s private-key encoding, address derivation and checksum rules from maintained specifications. BIP39 seeds and BIP32 paths are offered only when interoperable with the intended recovery wallet.
BIP38 can encrypt compatible private-key exports with a passphrase before printing. Test vectors cover encryption and decryption, while the interface explains that a forgotten passphrase is permanent loss rather than a recoverable account credential.
Layouts preserve text, checksums and QR quiet zones across agreed paper sizes and monochrome printers. Scanning tests use the final print path because browser scaling, toner and damaged folds can make an on-screen code unreadable on paper.
Published files include reproducible build instructions, cryptographic hashes and a procedure for checking the downloaded copy before disconnecting the network. Content Security Policy and source review reduce tampering opportunities but cannot prove that the machine or printer is uncompromised.
We establish the coin, recovery target, holding period, spending method and physical threat assumptions. If a hardware wallet or conventional seed backup is safer and simpler, we say so before building a specialised generator.
Key encoding, address derivation, random-source requirements and optional encryption are written against published standards and test vectors. Failure to obtain secure randomness stops generation rather than falling back to timestamps or user gestures alone.
All code, styles and assets are bundled into an inspectable file that performs no network requests. Print layouts keep human-readable values and QR codes paired without exposing secrets to online services.
Independent implementations confirm addresses, encrypted keys, seeds and checksums across deterministic fixtures. Air-gapped drills test printing, scanning, restoring and fully sweeping funds before the process is accepted.
The handover defines download verification, media preparation, printer handling, duplicate policy, storage and destruction. It also states that physical degradation, hidden copies and operator mistakes remain outside software guarantees.
A generator intended for air-gapped use must contain its scripts, styles, fonts and cryptographic code in the supplied artefact. Runtime network requests are blocked, tested and unnecessary. The user verifies the file and its hash on a trusted system before transferring it to a machine that remains disconnected during generation.
That boundary does not make a compromised download or computer safe. Reproducible builds, signed release information and readable source give an independent reviewer evidence to compare, but they cannot prove that firmware, storage media or a printer has not been altered.
Modern browser cryptography can provide operating-system randomness through the Web Crypto API, but the surrounding environment still matters. Unsupported APIs, embedded browsers and defective platforms must fail closed. Mouse movement and typed characters may supplement a sound source; they should not disguise a weak one.
Generation tests use known vectors for determinism where required and statistical checks only as diagnostic evidence, not proof of security. Private values are not logged or persisted by the application. Memory clearing in JavaScript is inherently limited, which is another reason to use a temporary offline environment rather than an ordinary browsing session.
Paper can be photographed, copied, misprinted, destroyed by water or fire, and retained in a printer queue or scanner memory. Lamination and duplicate storage address some hazards while introducing others, including unnoticed copies and incompatible inheritance procedures. BIP38 limits immediate use of a stolen printout but adds passphrase loss and implementation compatibility risks.
Paper wallets are a niche tool with well-documented failure modes. Genisys will recommend a hardware wallet or a properly recorded seed backup when that produces a clearer recovery and spending process. No layout can compensate for an untrusted generation machine or careless physical custody.
An imported private key can continue receiving funds and may leave change under wallet-specific control, creating ambiguity about which copy is authoritative. A paper wallet should normally be swept in full into a newly backed-up wallet, with the old key treated as exposed once scanned or entered.
A single incorrectly handled sweep can send change to an address whose key was not preserved, permanently losing that value. We test the intended recovery wallet and document a full-sweep procedure, but cannot reverse a blockchain transaction or recover destroyed keys. Qualified advisers must determine tax, reporting or other legal consequences of creating or moving the assets.
Only for narrow, carefully controlled cases. They avoid some online exposure but add generation, printing, physical storage, passphrase and spending risks, so a hardware wallet or documented seed backup is often the better answer.
Yes. We can supply a self-contained file with no runtime network requests for use on a verified air-gapped machine, together with hashes and a transfer procedure.
A supported Web Crypto implementation can provide cryptographically suitable operating-system randomness, but browser and platform integrity still require care. The tool fails if its required source is unavailable and does not substitute timestamps, Math.random or visible user activity.
BIP38 encrypts a compatible private key with a passphrase before it is printed. It does not protect a weak passphrase, compromised generator or forgotten password, and recovery software must support the same format.
Compare its cryptographic hash and, where provided, release signature against information obtained through an independent trusted channel. Rebuilding from reviewed source adds evidence, but no check can guarantee that the computer, transfer media and printer are free from compromise.
It is unsafe unless the spending wallet’s change handling is fully understood and backed up. The recommended procedure is usually to sweep the entire balance into a new wallet, because one misdirected change output can make the remainder permanently inaccessible.
Share the problem, current system and constraints. We will respond with the questions needed to define a credible next step.