Unlinked subscription architecture
An unlinked subscription architecture tries to combine simple purchasing with compartmentalized trust. The customer gets one bill, but each service gets only the minimum entitlement information it needs.
The central operator still becomes a trust point. It knows billing data, support history, shipping records when hardware is sold, and the fact that a customer bought the bundle. The design goal is therefore not “no single liability.” It is fewer cross-service links and no single provider that sees identity, network activity, stored files, mail, and recovery data all at once.
IVPN Unlinked Access shows one approach: derive service-specific tokens from the central account and let services verify subscription status without storing the central account identifier.
Obscura trust 2-party relays and QUIC shows a related principle: split “who the user is” from “what the user does” between parties that cannot individually reconstruct the whole picture.
For a GrapheneOS phone bundle, the practical design should keep provisioning separate from trust. The seller can install GrapheneOS on a supported Pixel, lock the bootloader, and help the user verify the installation. After that, the user should be able to factory-reset the device and redeem the subscription through a post-reset setup flow.
That flow can install apps from official sources, redeem service-specific entitlement tokens, and give the user recovery codes. It should not require the reseller to know the user’s mail account, VPN account, cloud-storage account, DNS profile, or app credentials.
This architecture is legally and operationally easier when each provider has an explicit reseller, partner, or voucher agreement. Ordinary consumer terms often prohibit reselling, account sharing, or making the service available to third parties.
A fixed partner-issued voucher is the smallest implementation. It can separate purchase from redemption without creating a central subscription account or customer balance. Privacy voucher shop should prove that narrow flow before the venture derives tokens or coordinates a multi-service bundle.