We develop coin-specific Android wallets around verifiable key derivation, dependable synchronisation and transaction states users can inspect. The design records which data stays on the device and which services it must trust.
We implement address formats, transaction rules, fee units, network identifiers and payment URIs for the target coin. Fixtures derived from the reference implementation test parsing and signing across supported transaction types.
BIP32, BIP39 and BIP44 derivation is applied only where the coin and its established wallet ecosystem support those standards. Backup and restore tests confirm that seed words, passphrases and derivation paths reproduce the expected accounts.
Android Keystore and hardware-backed keys protect local encryption or signing material where device capabilities permit. Biometric authorisation gates access but does not replace seed recovery or make a compromised operating system trustworthy.
We compare SPV validation with a full-node-backed API according to privacy, resource use and the coin’s proof model. Peer selection, confirmations, reorganisations and unavailable backends remain visible rather than becoming generic connection errors.
The wallet validates addresses, QR payloads, amounts and fees before asking for authorisation. Fee estimates expose their source and age because delayed blocks or a poor estimator can make a transaction uneconomic or slow.
WorkManager jobs constrain background synchronisation around network access, battery and Android lifecycle rules. Reproducible variants, release signing and Play Store submission materials are prepared without claiming that Google will approve the application.
We establish transaction formats, address schemes, derivation paths, fee behaviour and confirmation policy from maintained coin sources. Custody boundaries identify what the application stores and which remote systems can influence its view.
SPV and full-node-backed options are compared for verification, privacy, bandwidth and operational cost. Test vectors cover headers, transactions, reorganisations and recovery from stale local state.
Generation, backup, restore, biometric access, signing and broadcasting are implemented as separately testable paths. QR input, payment URIs, clipboard use and screen capture are constrained according to the threat model.
Testing covers supported Android versions, hardware-backed storage availability, process death, intermittent networks and low battery. Restore drills and transaction fixtures check that a fresh installation reaches the same keys and balances.
Release builds, signing custody, dependency records and store declarations are assembled for the client. Store review remains Google’s decision, and policy changes can require product or distribution changes after delivery.
An SPV wallet verifies header chains and transaction inclusion without downloading every block, reducing storage and bandwidth at the cost of a narrower security and privacy model. A full-node-backed wallet can centralise chain interpretation behind an API, but then availability and truthful responses depend on infrastructure operated by the client or another provider.
The appropriate model depends on the coin’s consensus, available libraries and expected device conditions. We define confirmation and reorganisation behaviour explicitly, and do not describe an API response as independent verification.
A mnemonic is a portable root secret, while Android Keystore usually protects a device-bound key used to encrypt wallet material or authorise signing. Hardware backing and biometric policy differ by device and Android version, so the wallet detects capabilities and records the fallback rather than assuming secure hardware exists.
Sensitive views can inhibit screenshots, and copied addresses can be avoided or cleared, but neither control defeats a compromised operating system. Seed display is deliberately restricted and restore is tested from an erased application. Genisys builds self-custody software and does not receive, retain or operate the client’s or users’ keys.
Android can suspend networking, stop processes and defer background jobs to preserve battery. Synchronisation therefore resumes from durable checkpoints, distinguishes stale data from confirmed state and avoids holding secret material longer than a signing operation requires.
Payment requests need equally defensive handling. QR and URI parsing validates scheme, network, address, amount and optional fields before display, while fee estimates include age and provenance. A signed transaction is not shown as settled merely because broadcast succeeded.
The client’s release key controls future updates and must be held under an agreed access and recovery procedure. Build variants isolate test and production networks, dependencies are pinned, and artefacts can be traced to reviewed source and configuration.
Google Play policies for cryptocurrency applications, declarations and target Android versions change independently of engineering delivery. We can prepare the binary and technical submission evidence, but cannot promise listing, review time or continued store availability. Qualified advisers, not Genisys, determine any legal or regulatory obligations attached to the wallet or coin.
It depends on the coin, desired verification, privacy expectations and acceptable infrastructure. SPV reduces device resources but has a defined peer and proof trust model, while a node-backed API shifts more trust and operating responsibility to that service.
It can reduce exposure, but no phone can make a seed invulnerable. We use Android Keystore protection where available, minimise plaintext lifetime and provide an explicit offline backup flow, while recognising that rooted devices, malicious input methods and user disclosure remain risks.
No. Biometrics authorise local access on one device; a seed phrase or another designed recovery method is still required after loss, reset or hardware failure.
Yes, where the coin has a defined address and payment URI format. The wallet validates network, address, amount and optional parameters before presenting a transaction for authorisation.
Genisys cannot guarantee Play Store approval. Google decides acceptance under its current policies, and the operator remains responsible for accurate declarations and any advice required about the offered activity.
No. We engineer self-custody software and test it with controlled development fixtures, but production keys remain with the client or users according to the agreed design.
Share the problem, current system and constraints. We will respond with the questions needed to define a credible next step.