GridPlus

• Name: GridPlus
• URL: https://gridplus.io/
• Category: hardware-wallet operator company / signer-routing and companion-stack release authority / SafeCard lifecycle and device-connectivity trust boundary
• Tags: bitcoin-ecosystem ethereum-ecosystem
• Summary: GridPlus belongs in companies/ because the useful question is not only what does the Lattice1 do? One named operator sits above Lattice1 hardware design, SafeCard packaging, Lattice Manager workflow, default cloud routing, self-hostable escape hatches, software release, documentation, and support. The practical leverage is in the company-run signer lifecycle: device architecture choices, companion-tool defaults, routing and connectivity policy, SafeCard handling, and the official trust story users inherit when they buy into the GridPlus stack.
• What it does:
  • Operates the Lattice1 hardware-wallet line and the SafeCard model used for PIN-protected wallet and backup handling across multiple wallets on one device
  • Ships and stewards Lattice Manager as the web-based management surface for wallet exploration, BTC send / receive flows, app-connection management, address tags, and custom routing configuration
  • Publishes SDKs, a simulator, CLI tooling, and Lattice Connect V2 through the public GitHub organization, which makes the company responsible for the developer and connectivity shell around the signer
  • Defines the default cloud-routed device-connectivity path while also documenting and shipping the self-hostable proxy route for users who want to replace that company-managed messaging layer
  • Controls the release, documentation, and support surface that tells users how to set up the device, arm the security mesh, manage SafeCards, and connect through first-party or partner wallet paths
• Key claims:
  • The Lattice1 introduction page says the device is a digital asset management hub, which is a useful first-party signal that GridPlus is packaging a broad wallet-and-routing shell rather than a narrow offline signer SKU
  • The docs say One Lattice1 device + unlimited SafeCards = unlimited wallets, which makes SafeCard lifecycle design and backup choreography part of the real operator boundary rather than a trivial accessory feature
  • The security docs describe a General Compute Environment and a Secure Compute Environment, explicitly assuming the Linux-connected side may be compromised while keeping private keys inaccessible from the internet; that architecture is a company-controlled trust story, not only a product spec
  • The setup docs say the first step is connecting the Lattice1 to the internet and recommend arming the security mesh, which is a strong reminder that GridPlus is operating a network-connected signer workflow whose defaults matter
  • The Lattice Manager docs expose third-party connection management and custom message-routing configuration, which shows the company controlling a wallet-routing surface above the hardware itself
  • The Lattice Connect V2 repository says users can remove connections to the GridPlus cloud by self-managing an HTTP server and configuring a custom device ID, which makes the default company-managed routing boundary unusually legible
• Whitepaper: No standalone company whitepaper is the point here. The strongest primary-source snapshot remains ../whitepapers/gridplus-primary-sources-2026-05-01.md, read alongside the product-layer note in ../projects/gridplus.md.
• Sources:
  • https://gridplus.io/
  • https://docs.gridplus.io/
  • https://docs.gridplus.io/lattice1/lattice1-introduction
  • https://docs.gridplus.io/lattice1/security-features
  • https://docs.gridplus.io/setup/lattice1
  • https://docs.gridplus.io/apps-and-integrations/lattice-manager
  • https://github.com/GridPlus
  • https://github.com/GridPlus/gridplus-sdk
  • https://github.com/GridPlus/lattice-connect-v2
  • ../whitepapers/gridplus-primary-sources-2026-05-01.md

Internal linkages

• Product-layer note: gridplus.
• Useful hardware-wallet company comparisons: foundation-devices, coinkite, and satoshilabs.
• Reusable lens: hardware-wallet notes often deserve a separate company cut because firmware and companion-software release, routing defaults, support workflow, and supply-chain / backup trust usually sit with one named operator.

Protocol / company boundary

• Keep gridplus focused on the product surface: Lattice1, SafeCards, Lattice Manager, SDKs, Lattice Connect, and the signer-plus-routing stack users and developers directly touch.
• Keep this entity note focused on the operator boundary above that surface: the company shell that ships the device, defines routing defaults, packages SafeCard lifecycle and support guidance, and decides how much of the connectivity stack users are expected to trust by default.
• That split matters because what does GridPlus expose? and who controls the release, routing, and trust pipeline around GridPlus? are related but not identical questions.

Control surface

• Practical leverage sits in hardware and secure-display design choices, SafeCard issuance and recovery workflow, Lattice Manager defaults, cloud-routing versus self-hosted-connectivity posture, software-release trust, and the official documentation that tells users what operating assumptions are normal.

• Even with self-hostable escape hatches, most users still begin inside the company-defined routing, setup, and support shell; that makes GridPlus the real operator boundary around the signer stack.

• Treat the durable risk here as who controls the signer lifecycle and connectivity trust pipeline around Lattice1 and SafeCards?, not only as what are the device features?

• Last reviewed: 2026-08-07 UTC