GrapheneOS and CalyxOS are de-Googled Android operating systems that turn a supported phone into a privacy-hardened base for Bitcoin, Lightning, Nostr, and other sovereignty tools. GrapheneOS runs only on Google Pixel devices and focuses on a hardened security model — a hardened memory allocator, enhanced verified boot, per-app network and sensor permissions, and an optional sandboxed Google Play that needs no Google account. CalyxOS uses the open-source microG re-implementation of Google services plus its Datura per-app firewall and supports a broader set of devices, including Pixel, Fairphone, and several Motorola models. For a Bitcoiner, either gives you reduced telemetry, app isolation, and stronger device security for the phone that holds your wallets, watch-only node companions, and signing-device workflows.
Why a hardened mobile OS matters for Bitcoiners
Your phone is increasingly the control surface for self-custody: it runs mobile wallets, talks to hardware signers, hosts Nostr clients, and acts as a companion to a home node. That makes the underlying operating system part of your threat model. A stock Android build ties the device to a Google account, ships a large surface of pre-installed services with broad permissions, and reports telemetry by default. None of that is uniquely malicious, but for someone practicing financial sovereignty it concentrates trust and data in places you do not control.
A de-Googled OS narrows that exposure. It removes the hard dependency on a Google account, reduces background telemetry, isolates apps from one another, and gives you granular control over what each app can reach — the network, the sensors, your contacts, your storage. The goal is not paranoia; it is reducing the number of parties who can observe your balances, your counterparties, and your habits. Mobile hardening is one layer in a wider stack. It pairs naturally with the other practices covered across our sovereignty hub: running your own node, using hardware signers, and choosing communication tools you can self-host.
GrapheneOS: the Pixel-only hardened base
GrapheneOS is built from the Android Open Source Project (AOSP) and supports Google Pixel phones exclusively. The project states that devices are “carefully chosen based on their merits rather than the project aiming to have broad device support.” Its emphasis is a strengthened security model rather than a long device list.
Memory hardening and exploit mitigation
GrapheneOS ships a hardened memory allocator (hardened_malloc) that the project describes as “leveraging modern hardware capabilities to provide substantial defenses against the most common classes of vulnerabilities (heap memory corruption),” including fully out-of-line metadata and zero-on-free with write-after-free detection. It layers on exploit mitigations such as hardware memory tagging (ARM MTE on supported Pixels) and hardware-based control flow integrity. For a device that may hold spending keys, raising the cost of memory-corruption exploits is a meaningful defensive gain.
Sandboxed Google Play — no Google account required
Many people assume a de-Googled phone cannot run apps that expect Google services. GrapheneOS addresses this with Sandboxed Google Play: the option to install the official Google Play releases “in the standard app sandbox” with “absolutely no special access or privileges.” Play services run as ordinary, unprivileged apps inside whichever user profile you choose, and no Google account is required to use the OS. The project notes that “many apps work perfectly without Play services” — and for those that need them (push messaging, certain payment SDKs), you can confine Play to a single profile.
Per-app network and sensor permissions
GrapheneOS adds a Network permission toggle that disallows “both direct and indirect access to any of the available networks,” and a Sensors permission toggle that blocks access to sensors not already covered by standard Android permissions. It also provides Storage Scopes and Contact Scopes, which let an app believe it has broad access while actually seeing only what you allow. For Bitcoin use this is practical: an offline signing or seed-handling app can be denied the network entirely, while a watch-only wallet keeps connectivity. Additional hardening includes per-connection MAC randomization on by default, an optional LTE-only mode that disables 2G/3G/5G radio code, a duress PIN that irreversibly wipes the device, and an auto-reboot timer that returns data to an at-rest encrypted state.
Why Pixel-only
The Pixel restriction is a security decision, not a branding one. GrapheneOS requires hardware features that few phones provide: a StrongBox keystore backed by a secure element, hardware key attestation, hardware memory tagging, isolated radios, and a long firmware-support window — current Pixels carry a guaranteed minimum of seven years of updates. The project bluntly notes that “broad device support would imply mainly supporting very badly secured devices unable to support our features.” Installation uses an official WebUSB installer that flashes from a browser, after which you relock the bootloader; as GrapheneOS puts it, “locking the bootloader is important as it enables full verified boot.”
CalyxOS: microG, Datura, and broader device support
CalyxOS takes a complementary approach. Instead of confining the official Play stack, it ships microG, an open-source re-implementation that “replaces some functions of Google Play Services” while, in the project’s words, not including “any advertising or location tracking.” microG is “completely optional,” so you can run a fully Google-service-free phone or enable just enough compatibility for apps that need push notifications or location APIs.
CalyxOS’s standout control is the Datura firewall, which gives “fine-grained control over network access for each app.” A single toggle next to an app turns all of its network access on or off, and a per-app dropdown lets you separately allow or block background data, Wi-Fi, mobile data, and VPN traffic. This is useful for Bitcoiners who want a wallet on Wi-Fi only, or who want to quarantine an app from the network while still using its offline features.
CalyxOS supports a wider hardware range than GrapheneOS — Google Pixel (the 6 through 9 families), Fairphone 5 and 4, and several Motorola moto g models, with more added over time. Like GrapheneOS, it “utilizes Verified Boot (including bootloader re-locking) to keep the Android security model intact,” and a relockable bootloader is a stated requirement for support; carrier-locked variants that cannot unlock the bootloader are generally unsupported. CalyxOS also bundles privacy-forward defaults: an encrypted backup and restore suite (Seedvault), the F-Droid and Aurora app stores, Tor Browser, and free VPNs from the Calyx Institute and Riseup.
GrapheneOS vs CalyxOS at a glance
| Dimension | GrapheneOS | CalyxOS |
|---|---|---|
| Supported devices | Google Pixel only | Pixel, Fairphone 5/4, several Motorola moto g |
| Google compatibility layer | Sandboxed Google Play (official Play, unprivileged, optional) | microG (open-source re-implementation, optional) |
| Per-app firewall | Network permission toggle (allow/deny all networks) | Datura firewall (per-app background, Wi-Fi, mobile, VPN) |
| Verified boot | Enhanced verified boot with rollback protection; relock after install | Verified boot with bootloader relocking on supported devices |
| Hardware requirements | Strict (secure element, hardware attestation, MTE, 7-yr updates) | Broader; requires a relockable bootloader |
| Bundled app stores | App store for GrapheneOS apps; add F-Droid / Aurora yourself | F-Droid and Aurora Store included |
| Sensor permission toggle | Yes (per-app sensors permission) | Managed via standard Android permissions |
| Install method | Official WebUSB browser installer | WebUSB / device-flasher |
Neither project is “better” in the abstract. GrapheneOS leans toward the strongest hardware-backed security on a narrow device set; CalyxOS leans toward a usable de-Googled baseline across more hardware with microG ready out of the box. Both relock the bootloader to preserve verified boot, and both let you run without a Google account.
Running Bitcoin and sovereignty apps
Mobile wallets and watch-only / node companions
Most popular open-source Bitcoin and Lightning wallets install cleanly from F-Droid, the project app store, or Aurora Store, and run without Google services. A common sovereign pattern is to keep spending keys off the phone entirely: import an extended public key (xpub) or output descriptor to run a watch-only wallet that tracks balances and builds unsigned transactions, while signing happens on separate hardware. Node companions follow the same logic — point a mobile wallet at your own full node or Electrum server over your home network or a self-hosted tunnel, so you broadcast and verify against your own copy of the chain rather than a third party. You can publish or consume open mining and network data through our open-data hub as part of the same self-verifying mindset.
Working with hardware signers
A de-Googled phone is an excellent watch-only and PSBT (Partially Signed Bitcoin Transaction) coordinator for an air-gapped signer. Depending on the device, signers pair over USB-C, NFC, animated QR codes, or microSD, letting you move an unsigned transaction to the signer and a signed one back without exposing keys to the network — and on GrapheneOS you can deny the coordinating app network access while still using QR or USB transfer. For choosing and pairing a device, see our Bitcoin signing-devices dataset, which compares connectivity and air-gap options across signers.
Nostr clients and push notifications
Nostr is a natural fit for a hardened phone: clients are typically open source and key-based, with no account tied to a phone number or email. The main practical wrinkle is push notifications, which on stock Android route through Google’s Firebase Cloud Messaging. On a de-Googled phone, some Nostr and messaging clients support UnifiedPush, an open push protocol you can self-host or point at a relay, avoiding Google’s push service entirely; alternatively, sandboxed Google Play or microG can supply push for apps that require it. If you want your Lightning wallet to pay zaps and respond to requests from a Nostr client, the bridge is Nostr Wallet Connect — see our Nostr Wallet Connect guide — and to understand the underlying event types, our Nostr NIPs reference. These tools complement other off-grid and censorship-resistant layers such as the mesh networking covered in our Reticulum guide and the privacy-preserving payments in our ecash, Cashu, and Fedimint guide.
Honest limitations
A hardened mobile OS is a trade, not a free win. Hardware support is the first constraint: GrapheneOS needs a Pixel, and CalyxOS, while broader, still supports a specific list of devices with relockable bootloaders — a carrier-locked phone may not qualify. App compatibility is the second: most open-source wallets and Nostr clients work, but some mainstream apps lean hard on Google Play services, and a minority use integrity checks (such as hardware attestation) that may behave differently or refuse to run on a custom OS even when the OS is more secure than stock. The third cost is the learning curve — flashing the OS, relocking the bootloader, organizing apps into profiles, and managing per-app network rules takes time and care, and a mistake during installation can temporarily brick a boot. None of these are reasons to avoid de-Googling; they are reasons to plan, back up, and start with a spare device if you can. The payoff is a phone whose data exposure you actually control — a fitting base for the rest of a sovereign stack.
Frequently asked questions
Do I need a Google account to use GrapheneOS or CalyxOS?
No. Neither OS requires a Google account. GrapheneOS runs without Play services — “many apps work perfectly without Play services” — and offers Sandboxed Google Play only if you choose to install it. CalyxOS ships microG as a completely optional Google-services replacement, so you can run a fully Google-free phone.
Which is more secure, GrapheneOS or CalyxOS?
They make different trade-offs. GrapheneOS targets the strongest hardware-backed security model — hardened memory allocator, enhanced verified boot, per-app network and sensor controls — but only on Pixel devices that meet strict hardware requirements. CalyxOS prioritizes a usable de-Googled baseline across more devices with microG and the Datura firewall. Both relock the bootloader to preserve verified boot. The right choice depends on your device and how much you value the broader hardware support versus the stricter security ceiling.
Can I keep my Bitcoin keys on a de-Googled phone safely?
You can, and the hardening (memory protections, app isolation, per-app network denial, encrypted storage) reduces risk versus stock Android. For larger amounts, the more sovereign pattern is watch-only on the phone with keys held on a separate hardware signer, using the phone only to build and relay PSBTs. See the signing-devices dataset for pairing and air-gap options.
Will my mobile Bitcoin wallet and Nostr apps still work?
Most open-source wallets and Nostr clients install from F-Droid, the project store, or Aurora Store and work without Google services. The main caveat is push notifications: some apps support the open UnifiedPush protocol, while others rely on Google’s Firebase messaging, for which you would enable sandboxed Google Play or microG. A small number of apps with strict integrity checks may misbehave on a custom OS.
What phones can run these operating systems?
GrapheneOS supports Google Pixel phones only, because of its hardware security requirements (secure element, hardware attestation, memory tagging, and a multi-year firmware-support window). CalyxOS supports Pixel devices plus Fairphone 5 and 4 and several Motorola moto g models, provided the bootloader can be unlocked and relocked. Carrier-locked variants that block bootloader unlocking are generally unsupported.
Is it hard to install, and can I undo it?
GrapheneOS provides an official WebUSB installer that flashes from a supported browser, and CalyxOS offers a comparable guided flasher. The process wipes the device and ends with relocking the bootloader to enable full verified boot. Both are reversible by re-flashing the stock factory image, but plan for the time, back up first, and ideally practice on a spare device before committing your daily phone.
