Cowrie Research

bubble-protocol

3 min read

Bubble Protocol

  • Name: Bubble Protocol
  • URL: https://bubbleprotocol.com/
  • Category: contract-governed storage-access middleware / guardian-enforced private-data wrapper
  • Summary: Bubble Protocol is storage-access middleware, not a storage-network anchor. The useful split is simple: a contract defines permissions, a Guardian enforces them, and a DataServer stores bytes wherever the operator wants.
  • What it does:
    • Defines a protocol for access-controlled off-chain storage where blockchains govern who can read, write, append, list, or execute specific files and directories
    • Uses a minimal on-chain AccessControlledStorage interface whose getAccessPermissions(user, contentId) method returns POSIX-like access bits for off-chain content
    • Treats each contract-controlled off-chain content container as a bubble, with globally unique IDs derived from contract identity plus storage-service location
    • Provides a server-side Guardian that validates request syntax, checks on-chain permissions, verifies the bubble has not been terminated, and only then forwards permitted actions to a storage backend
    • Lets the backend DataServer be user-defined, so bubble content can live on a filesystem, database, CMS, decentralized storage network, RAM test harness, or other infrastructure
    • Offers a client SDK with ContentManager, Bubble, BubbleFactory, and DeployableBubble abstractions for reading, writing, encrypting, creating, and managing bubbles
    • Supports optional multi-user encrypted bubbles where per-user metadata files contain the bubble encryption key encrypted to each user’s public key
    • Adds optional subscriptions and notification flows so bubbles can work as simple backend state for messaging, social, or collaborative applications
    • Models data lifecycle inside the smart contract itself, including a terminated state where the storage system is required to delete the bubble’s content
  • Key claims:
    • The real claim is policy decomposition. Bubble says any contract that implements one access-check method can govern stored content, which keeps the permission surface visible instead of burying it in backend code.
    • The Guardian/DataServer split is the point. The Guardian checks syntax, permissions, and bubble state against the controlling contract; the DataServer can be whatever storage backend the operator wants.
    • Bubble’s Content ID design matters because it binds chain, controller contract, storage provider, and file identity together. That is a different model from content-addressed storage where object identity changes when bytes change.
    • The lifecycle model is stronger than the branding suggests. The contract can encode data-state transitions and even termination, which makes storage deletion policy part of the protocol surface instead of a private operator promise.
    • The decentralization story is narrow on purpose. Bubble does not solve durability; it pushes access policy onchain while leaving storage trust with the chosen offchain provider.
    • Optional encryption and per-user key distribution add another explicit layer, but they do not change the main read: Bubble is policy and enforcement middleware over arbitrary storage.
  • Whitepaper: Bubble Protocol has an official whitepaper PDF at https://bubbleprotocol.com/docs/whitepaper.pdf, downloaded in this pass to ../whitepapers/bubble-protocol-whitepaper.pdf. The strongest accessible primary-source text in this pass came from the official site and Bubble SDK materials; see ../whitepapers/bubble-protocol-primary-sources-2026-05-13.md.
  • Sources:

Control surface

  • Power sits with the contract author defining permissions, the Guardian software actually enforcing them, the storage operator behind the DataServer, and any key-sharing workflow used for encrypted bubbles.

  • Read Bubble as access-control middleware over arbitrary storage, not as a durability network.

  • Last reviewed: 2026-06-12 UTC

Graph View