Ceramic Built Mutable Data Streams for Web3. The Governance of Those Streams Is Still Not Local.

Ceramic addressed a real gap in Web3 infrastructure. Blockchains are good at immutable state transitions but poor at mutable, application-level data. User profiles, social graphs, preferences, documents, and other data objects that change over time do not belong on-chain. They are too large, too frequently updated, and too varied to fit the transaction model that blockchains optimize for.

Ceramic built a protocol for mutable data streams that are verifiable, decentralized, and composable. Each stream has a StreamID that persists across updates. Updates are signed by the stream's controller (typically a DID, a decentralized identifier). The stream's history is a directed acyclic graph of commits, each linking to its predecessor. Commits are anchored to a blockchain for timestamp proofs, providing an ordering guarantee without requiring blockchain consensus for every update.

ComposeDB extended this foundation with structured data models: GraphQL schemas that define the shape of data within streams, enabling queries across streams that share a common model. This is a genuine capability. Developers can define a data model once and query across all streams that conform to it, creating composable data layers that multiple applications can share.

The structural problem is not in the stream model or the data layer. It is in where governance lives.

What the stream model governs and what it does not

A Ceramic stream has clear ownership semantics. The stream's controller — identified by a DID — is the only entity authorized to commit updates. This ownership is enforced cryptographically. No intermediary can modify a stream without the controller's signature. Stream-level governance is real: the controller governs their stream.

What the stream model does not govern is anything above the individual stream level.

Data model governance. ComposeDB data models define the schema that streams conform to. A data model is created by a developer and published to the Ceramic network. Other developers can use the same model, creating interoperable data across applications. But the governance of data models — how a model can evolve, who can propose changes, how breaking changes are handled, how the relationship between models is structured — is not governed by the protocol. A model author publishes a model. If it needs to change, they publish a new version. Consumers discover the change when their queries return different results or fail. There is no mechanism for the participants using a model to collectively govern its evolution.

Namespace organization. Streams are identified by StreamIDs, which are derived from the stream's genesis commit. StreamIDs exist in a flat namespace. There is no hierarchical organization, no scoping mechanism, no way to define that a set of streams constitutes a governed namespace with shared policy. An application's streams coexist in the same global namespace as every other application's streams. Organization is imposed by applications querying for streams that match specific data models, not by namespace structure.

Network governance. Ceramic nodes discover each other and synchronize streams through libp2p. The network topology is determined by which nodes are running, which streams they are interested in, and how libp2p's pubsub and DHT mechanisms route messages. There is no mechanism for a scope of the network to define its own synchronization policy, its own caching rules, or its own governance for how streams within that scope are organized and maintained. Network-level coordination follows the same pattern as any libp2p-based system: global protocols, local execution, no scoped governance.

The anchoring layer is verification, not governance

Ceramic anchors stream commits to a blockchain (typically Ethereum) to provide timestamp proofs and ordering guarantees. The anchoring layer is a verification mechanism: it proves that a commit existed at a certain time and establishes a canonical ordering of commits within a stream.

Anchoring is not governance. The blockchain confirms when a commit happened. It does not validate whether the commit should have happened, whether it conforms to namespace policy, or whether it is consistent with the structural expectations of the scope it belongs to. Anchoring is timestamping. Governance is the layer that decides what mutations are valid within a scope and how the scope itself can evolve.

The anchoring service itself introduces a centralization point. Ceramic's architecture relies on anchor services that batch commits and submit them to the blockchain. The availability and behavior of the anchor service affects the entire network's ability to produce timestamp proofs. This is an operational dependency, and Ceramic has worked to decentralize it. But even a fully decentralized anchoring layer provides verification, not namespace governance.

What local stream governance requires

The gap is between stream-level ownership (which Ceramic solves) and namespace-level governance (which remains unaddressed). An anchor-governed adaptive index provides the missing layer.

In an anchor-governed model, each scope of the namespace is maintained by anchor nodes that hold governance authority for that scope. A set of related streams — all streams conforming to a particular data model within a particular application context, for example — becomes a governed scope. Data model evolution within the scope is proposed by participants and validated through local anchor consensus. Namespace organization is maintained by the scope's anchors: what streams belong to the scope, how they relate to each other, and how the scope's structure can change.

Cross-scope discovery works through alias delegation in the hierarchy rather than through global DHT queries. A query for streams matching a particular model in a particular context is resolved by the anchors governing that scope, not by scanning the global namespace. The scope's anchors know what belongs to the scope because they govern it.

Ceramic's stream model and the adaptive index's governance layer are complementary. Streams continue to provide mutable, verifiable data objects controlled by their owners. ComposeDB continues to provide structured schemas for composable data. What changes is the organizational layer: how streams are grouped, how data models evolve, how cross-application discovery works, and who holds authority over namespace structure. That authority distributes into the namespace itself, governed locally by the anchors responsible for each scope.