Technical design of sovereign data cooperatives

This article is part of the ongoing case study Tools for Creating Sovereign Data Cooperatives, which examines the mechanisms required for multiple stakeholders to jointly govern a shared data asset without ceding control to a central intermediary.

Why chained consent is necessary

From data silos to data cooperatives

Most data today resides behind a single guardian. A platform, a corporation, or a single institution decides who can access a dataset and on what terms, and everyone else simply has to trust that this guardian will act fairly, or avoid it altogether. This model breaks down for information that is naturally collective: soil measurements aggregated among neighboring farms, sensor streams shared by a cooperative, or any dataset whose value comes precisely from combining contributions from multiple independent stakeholders. None of these stakeholders wants to hand over ultimate control of the combined asset to any of the others, or to a third-party platform, purely to make sharing practical.

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

Two problems a cooperative must solve

Specifically, for a cooperative to work, two distinct problems must be solved:

1. Represent assets and rights. Someone must be able to state, in an unambiguous and verifiable way, who holds which rights over which asset. This part is already solved on-chain: Ocean Protocol represents each published asset as an ERC721 token, and its ERC721Template extends the base standard with a small hierarchy of roles — owner, manager, deployer, metadata updater, and marketplace updater — that governs who can act on that asset.
2. Turn many individual wills into a binding decision. Representing rights answers who has the right to act, but not how a group with those rights agrees whether to act or not. This is the part that existing data space infrastructure leaves open, and it is the part without which a data cooperative cannot function: as soon as an asset is co-managed, someone still has to decide, on behalf of the entire group, whether or not to update the asset's metadata. Two conventional ways to solve that second problem are possible, and both are unsatisfactory in a sovereign data space:

• Delegate the decision to an intermediary service. A backend could collect requests and update the asset on behalf of the group, but doing so would reintroduce exactly the kind of centralized point of control and failure that a decentralized data cooperative aims to avoid.
• Require a multisig wallet for every change. This works for infrequent, high-value decisions, but it 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 options leaves a short list of requirements that any viable alternative must satisfy, and each corresponds to a specific decision made in this design:

• The solution must be decentralized, providing this functionality to all users in the ecosystem.
• Voting power must be variable, depending on the contributions made 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 existing owner or manager of the asset should be able to make it change.

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

Architectural approaches for shared data governance

Since 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 is generally framed within one of four architectural approaches, each with different trade-offs in terms of scalability, friction, and ecosystem compatibility.

1. Multisig wallets

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

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

2. Standardized DAO frameworks

To address the scalability and variable-weight issues of a multisig, a cooperative can deploy a full Decentralized Autonomous Organization (DAO) architecture, using standards such as the Governor contracts from OpenZeppelin.

• How it works: The ERC721 Data NFT is owned by a Timelock/Governor contract. Members hold ERC20 or ERC721 "Data Shares" that represent their contribution to the pool. When an algorithm requests access, a formal proposal is sent to the DAO. Members vote using the weight of their token. If approved, the Governor contract automatically executes the transaction to update the ERC721 metadata.
• The reality: This provides robust, weighted voting. However, it is a heavy abstraction. It forces the cooperative to manage a completely separate token economy just to vote on dataset updates. Furthermore, standard Governor contracts allow the arbitrary execution of calldata, which introduces a massive security attack surface when the sole objective is managing access controls for a dataset.

3. Fractionalized Data NFT

Instead of 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 in turn mints fractional ERC20 tokens. These tokens grant holders 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 does not mechanically translate into a way to approve or deny that researcher's access. It solves the economics, but leaves the governance problem unresolved.

4. Custom Metadata Managers

To avoid the friction of a multisig and the overhead of a full DAO, the ideal solution bridges the gap by maintaining a lightweight consensus mechanism 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 the need for a dedicated ERC20), and execute only predefined dataset updates.
• The reality: This approach meets all the requirements. It allows for variable voting power, remains decentralized, avoids arbitrary code execution, and prevents bottlenecks.

This fourth approach, which decouples the voting logic into a specialized and pluggable contract while respecting the existing ERC721 roles, constitutes the exact plan for the Metadata Request Manager.

Metadata Request Manager Design

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

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

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 compatibility with all deployed assets. The design is based on three fundamental principles to make shared governance secure 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 of how the cooperative decides to weight contributions.

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

Finally, it decouples the decision from the execution. The sole function of the contract is to count votes and resolve whether a change is approved by the collective. Applying that approved change to the actual dataset metadata still requires an ordinary transaction sent through the existing authorization hierarchy of Ocean Protocol.

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

Data model

The contract organizes state around three entities: a Request, the individual SubRequest it groups, and the MetadataRequestVote issued against it.

A single Request can bundle several SubRequest of different types into the same proposal — for example, requesting to trust a new algorithm and granting it access to the network in the same request — because each one carries its own independent count of yesWeight/noWeight. This allows co-owners to approve part of a request while rejecting another part, instead of forcing an all-or-nothing vote.

Two enumerations drive the model:

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

RequestType	Effect on the dataset
AllowNetworkAccess	Allows a given algorithm to access the dataset during compute-to-data execution
TrustedAlgorithm	Adds an algorithm to the dataset's list of trusted algorithms
TrustedAlgorithmPublisher	Trusts a full publisher, so any algorithm they publish can be run against the dataset

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

Request lifecycle

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

stateDiagram-v2 [] --> Pending: createRequest() Pending --> Cancelled: cancelRequest() (requester only) Pending --> Approved: finalize() — all subrequests win Pending --> Resolved: finalize() — some subrequests win Pending --> Rejected: finalize() — no subrequest wins Cancelled --> [] Approved --> [] Resolved --> [] Rejected --> [*]

Each request carries a timestamp expiresAt, bounded by a MAX_EXPIRE_DURATION at the contract level (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 limited and predictable time window to respond, rather than leaving a request open indefinitely.

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

sequenceDiagram participant Requester participant CoOwners as Dataset Co-Owner(s) participant Manager as MetadataRequestManager participant Oracle as VotingWeight

Requester->>Manager: createRequest(dataset, algorithm, requestTypes[], data[], expiresIn) Manager-->>Requester: RequestCreated

loop while Pending CoOwners->>Manager: vote(requestId, inFavourBitmap, reason) Manager->>Oracle: getWeight(voter, dataset) Oracle-->>Manager: weight Manager->>Manager: accumulate yesWeight / noWeight per SubRequest Manager-->>CoOwners: RequestVoted end

Note over Manager: after expiresAt Requester->>Manager: finalize(requestId) Manager->>Manager: compare yesWeight vs noWeight per SubRequest Manager-->>Requester: RequestVotingFinished + RequestApplied (approved types, data) CoOwners->>CoOwners: send regular owner/manager transaction applying the approved changes

Note the last step: finalize only computes and emits which subrequests were approved — it does not touch the dataset NFT itself. Applying the approved change is left to a follow-up transaction signed by whoever already holds the owner or manager rights over 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 the existing, unmodified Ocean Protocol permission system.