Technical Design of Sovereign Data Cooperatives

This article is part of the ongoing case study Tools for the Creation of Sovereign Data Cooperatives, which looks at the mechanisms needed for multiple stakeholders to jointly govern a shared data asset without handing control to a central intermediary.

Why On-Chain Consent Is Needed

From Data Silos to Data Cooperatives

Most data today sits behind a single gatekeeper. A platform, a corporation, or a single institution decides who may access a dataset and on what terms, and everyone else simply has to trust that gatekeeper to act fairly — or route around it entirely. That model breaks down for information that is naturally collective: soil measurements pooled across neighboring farms, sensor feeds shared by a cooperative, or any dataset whose value comes precisely from combining contributions from multiple, independent stakeholders. None of those stakeholders wants to hand ultimate control of the combined asset to any one of the others, or to a third-party platform, purely to make sharing practical.

A data cooperative is one answer to that tension: a group of stakeholders pools data assets under a shared, explicit governance process, retaining collective sovereignty over how the asset is used instead of ceding it to a central intermediary. Decentralized data spaces such as those built on Ocean Protocol and Pontus-X already provide much of the plumbing this requires — standardized asset representation, verifiable identities, and infrastructure for computing on data without it ever leaving its owner's environment. What they do not automatically provide is a way for a group of co-owners to jointly decide on the terms of use for something they hold together. Building an actual cooperative on top of this infrastructure means closing that gap.

Two Problems a Cooperative Must Solve

Concretely, making a cooperative work requires solving two distinct problems:

1. Representing assets and rights. Someone has to be able to say, unambiguously and verifiably, who holds what rights over which asset. This part is already solved on-chain: Ocean Protocol represents every published asset as an ERC721 token, and its ERC721Template extends the base standard with a small role hierarchy — owner, manager, deployer, metadata updater, and store updater — that governs who may act on that asset.
2. Turning many individual wills into one binding decision. Representing rights answers who is entitled to act, but not how a group with those rights agrees on whether to act at all. This is the part existing dataspace infrastructure leaves open, and it is the part a data cooperative cannot function without: as soon as an asset is co-managed, someone still has to decide, on behalf of the whole group, whether or not to update the asset metadata. Two conventional ways of solving that second problem are possible, and both are unsatisfying in a sovereign data space:

• Delegate the decision to an intermediary service. A backend could collect requests and update the asset on the group's behalf, but doing so would reintroduce exactly the kind of centralized point of control and failure that a decentralized data cooperative is meant to avoid.
• Require a multi-signature wallet for every change. This works for infrequent, high-value decisions, but is operationally heavy for something as routine as approving an algorithm's access to a dataset, and it does not scale gracefully as membership grows.

Ruling out both of those leaves a short list of requirements that any workable alternative has to satisfy, and each one maps onto a specific decision made in this design:

• The solution must be decentralized, providing this functionality to all users of the ecosystem.
• Voting power must be variable, depending on the contributions done to the cooperative, for example.
• Turning a collective decision into an actual change must still flow through the asset's existing authorization system. The cooperative can decide that something should change; only the asset's existing owner or manager should be able to make it change.

These requirements describe a specific kind of object: a way for co-owners to express consent — to approve or reject a proposed change to a shared asset — that is recorded and enforced on-chain, whose notion of voting power is not hard-wired into the mechanism itself, and whose only output is a decision rather than the change it authorizes. In practice, that means a smart contract that manages the full lifecycle of a request: a proposal to change something about an asset, put to the current co-owners for a vote, and only carried out once that vote is resolved.

Architectural Approaches to Shared Data Governance

Because Ocean Protocol represents datasets as ERC721 tokens (Data NFTs), transferring "ownership" to a cooperative inherently means transferring the NFT to a smart contract that acts on behalf of the collective. Implementing this shared governance model generally falls into one of four architectural approaches, each with distinct trade-offs regarding scalability, friction, and ecosystem compatibility.

1. Multi-Signature Wallets

The most straightforward approach is to transfer the ERC721 ownership to a shared smart contract wallet, such as a Gnosis Safe.

• How it works: A set of predefined co-owners holds signing keys. Any change to the dataset—such as updating metadata or approving a new compute-to-data algorithm—requires an $M$-of-$N$ threshold of signatures (e.g., 3 out of 5 owners must sign).
• The Reality: This is highly secure and requires no custom smart contract development. However, it treats all members equally (no variable voting power based on data contribution) and causes severe operational bottlenecks. Coordinating signatures for routine access requests becomes paralyzing as the cooperative grows beyond a handful of members.

2. Standardized DAO Frameworks

To solve the scalability and variable-weight issues of a multi-sig, a cooperative can deploy a full Decentralized Autonomous Organization (DAO) architecture, utilizing standards like OpenZeppelin's Governor contracts.

• How it works: The ERC721 Data NFT is owned by a Timelock/Governor contract. Members hold ERC20 or ERC721 "Data Shares" representing their contribution to the pool. When an algorithm requests access, a formal proposal is submitted to the DAO. Members vote using their token weight. If passed, the Governor contract automatically executes the transaction to update the ERC721 metadata.
• The Reality: This provides robust, variable-weight voting. But it is a heavy abstraction. It forces the cooperative to manage an entirely separate token economy just to vote on dataset updates. Furthermore, standard Governor contracts allow for arbitrary calldata execution, which introduces a massive security surface area when the only goal is to manage a dataset's access controls.

3. Fractionalized Data NFTs

Rather than focusing purely on governance, this approach focuses on the economic pooling of the asset.

• How it works: The original ERC721 Data NFT is locked in a vault contract, which mints fractional ERC20 tokens in return. These tokens entitle the holders to a share of the revenue generated when the dataset is consumed.
• The Reality: While excellent for automating revenue distribution among data contributors, fractionalization natively ignores governance. If an AI researcher wants to run a new algorithm on the data, owning 10% of the revenue shares doesn't mechanically translate to a way to approve or deny that researcher's access. It solves the economics, but leaves the governance problem unsolved.

4. Custom Metadata Managers

To avoid the friction of a multi-sig and the bloat of a full DAO, the ideal solution bridges the gap by keeping the consensus mechanism lightweight and tailored exclusively to the asset's lifecycle.

• How it works: The ERC721 Data NFT remains largely unmodified. Instead of transferring absolute ownership to a DAO, the cooperative designates a specialized smart contract as the authorized "Manager" or "Metadata Updater" in the Ocean Protocol hierarchy. This contract is explicitly designed to handle requests, query external oracles for voting weights (without needing a dedicated ERC20), and execute only predefined dataset updates.
• The Reality: This approach hits all the requirements. It allows for variable voting power, remains decentralized, prevents arbitrary code execution, and avoids bottlenecking.

This fourth approach, decoupling the voting logic into a specialized, pluggable contract while respecting the existing ERC721 roles, forms the exact blueprint for the Metadata Request Manager.

Designing the Metadata Request Manager

To build a cooperative that actually scales without breaking existing infrastructure, we will pursue the fourth approach: a custom, protocol-native manager.

While standard governance tools like OpenZeppelin's Governor family are the industry default, adopting them directly introduces unnecessary friction. They require assets to inherit specific standards like ERC721Votes, which would leave every dataset already published in the ecosystem incompatible with the new cooperative layer. Furthermore, they often rely on arbitrary code execution and strict ERC20 token balances, which overcomplicates the precise goal of managing dataset access.

Instead, the chosen design implements the Metadata Request Manager as an external, standalone contract. By keeping the manager separate from the Data NFT itself, it provides immediate backward compatibility with all deployed assets. The design relies on three core principles to make shared governance safe and practical:

First, voting weight is resolved through a pluggable oracle rather than a hardcoded token balance. The manager queries this oracle to determine a member's voting power, keeping the voting mechanics completely independent from how the cooperative decides to weigh contributions.

Second, the system trades flexibility for safety. Rather than allowing a proposal to execute arbitrary calldata, the contract only recognizes a fixed, enumerated set of request types specifically tailored to data sharing (such as approving algorithms or granting network access). This closes off massive security attack surfaces.

Finally, it decouples the decision from the execution. The contract's only job is to tally the votes and resolve whether a change is approved by the collective. Applying that approved change to the dataset's actual metadata still requires an ordinary transaction submitted through Ocean Protocol's existing authorization hierarchy.

The following data model outlines exactly how this manager structures and processes those requests.

Data Model

The contract organizes state around three entities: a Request, the individual SubRequests it bundles, and the MetadataRequestVotes cast against it.

A single Request can bundle several SubRequests of different types in one submission — for example, asking to trust a new algorithm and grant it network access in the same request — because each carries its own independent yesWeight/noWeight tally. This lets co-owners approve part of a request while rejecting another part, rather than forcing an all-or-nothing vote.

Two enumerations drive the model:

Status	Meaning
Pending	Open for voting; not yet past its expiry
Cancelled	Withdrawn by the requester before resolution
Approved	Every bundled sub-request reached majority "yes" weight
Resolved	Some, but not all, sub-requests were approved
Rejected	No sub-request reached majority "yes" weight

RequestType	Effect on the dataset
AllowNetworkAccess	Permits a given algorithm to reach the dataset during compute-to-data execution
TrustedAlgorithm	Adds an algorithm to the dataset's trusted-algorithm list
TrustedAlgorithmPublisher	Trusts an entire publisher, so any algorithm they publish is allowed to run against the dataset

Votes are cast as an inFavourBitmap: a single integer whose bits map to the sub-requests inside a Request, so one transaction can express a position on every bundled sub-request at once, weighted by the voter's resolved voting power.

Request Lifecycle

A request moves through a small state machine, driven by three entry points — createRequest, vote, and finalize — plus an escape hatch, cancelRequest, available to the original requester while the request is still pending.

Every request carries an expiresAt timestamp, capped by a contract-wide MAX_EXPIRE_DURATION (30 days by default, adjustable by the contract owner). Votes can only be cast before that deadline; finalize can only be called after it. This gives co-owners a bounded, predictable window to respond, instead of leaving a request open indefinitely.

The full interaction between a requester, the co-owners who vote, the oracle, and the eventual on-chain update looks like this:

Note the last step: finalize only computes and emits which sub-requests were approved — it does not itself touch the dataset's NFT. Applying the approved change is left to a follow-up transaction signed by whoever already holds owner or manager rights on that asset. This two-transaction split is what keeps the design non-invasive: consensus-building is fully on-chain and trustless, while the actual state mutation continues to flow through Ocean Protocol's existing, unmodified permission system.