This page shows things you can do with Ocean...

• As a builder

• As a data scientist

• As an OCEAN holder

• Become an Ocean ambassador

Let's explore each...

What builders can do

To dive deeper, please go to Developers page.

What data scientists can do

To dive deeper, please go to Data Scientists page.

What OCEAN holders can do

Become an Ocean Ambassador

Next: OCEAN: The Ocean token

Back: What is Ocean?

Ocean's mission is to level the playing field for AI and data.

How? By helping _you_** monetize AI models and data, while preserving privacy.**

Ocean is a decentralized data exchange protocol to drive AI. Its core tech is:

• Data NFTs & datatokens, to enable token-gated access control, data wallets, data DAOs, and more.

• Compute-to-data: buy & sell private data, while preserving privacy

Ocean Users Are...

• Developers. Build token-gated AI dApps & APIs

• Data scientists. Earn via predictions & challenges

• OCEAN holders. Earn rewards by running prediction bots on DeFi crypto tokens to accurately predict their price directions in 5 minutes and 1 Hour timeframe.

• Ocean ambassadors

Quick Links

• Why Ocean? and What is Ocean?

• What can you do with Ocean?

• OCEAN: The Ocean token

• Networks, Bridges

• FAQ, Glossary

Next: Why Ocean?

Back: Docs main

The Ocean Token (OCEAN) was the utility token powering the Ocean Protocol ecosystem, used for staking, governance, and purchasing data services, enabling secure, transparent, and decentralized data exchange and monetization.

The ASI Token

On March 26th, Ocean Protocol, SingularityNET, and Fetch.ai joined forces to form the Superintelligence Alliance and announced a strategic merger of their tokens—OCEAN, FET, and AGIX—into a single unified token called “ASI.” The primary vision behind this Alliance is to empower individuals with the freedom to own and control their data and AI, while upholding each person’s autonomy and sovereignty in the emerging AI-driven economy.

Starting with FET as the base token of the Alliance, the FET token will be renamed ASI, with an additional 1.48 Billion tokens minted: 867 million ASI allocated to AGIX holders and 611 million ASI allocated to OCEAN token holders. The total supply of ASI tokens will be 2.63 Billion tokens.

If you are holding OCEAN tokens on the Ethereum network, then you can participate in the Phase 1 migration to FET here.

For more info, navigate to this section of our official website.

Next: Networks

Back: What can you do with Ocean?

What is Ocean?

Ocean is a decentralized data exchange protocol.

AI lives on data; Ocean facilitates it.

Ocean has two specific parts:

• A live tech stack. At the core is Datatokens and Compute-to-Data

• A lively community. This includes builders, data scientists, and Ocean Ambassadors. Ocean's community is active on social media.

Let's drill into each.

Tech: Ocean data NFTs and datatokens

These enable decentralized access control, via token-gating. Key principles:

• Publish data services as ERC721 data NFTs and ERC20 datatokens

• You can access the dataset / data service if you hold 1.0 datatokens

• Consuming data services = spending datatokens

Crypto wallets, exchanges, and DAOs become data wallets, exchanges, and DAOs.

Data can be on Azure or AWS, Filecoin or Arweave, REST APIs or smart contract feeds. Data may be raw AI training data, feature vectors, trained models, even AI model predictions, or non-AI data.

Tech: Ocean Compute-to-Data

This enables one buy & sell private data, while preserving privacy

• Private data is valuable: using it can improve research and business outcomes. But concerns over privacy and control make it hard to access.

• Compute-to-Data (C2D) grants access run compute against the data, on the same premises of the data. Only the results are visible to the consumer. The data never leaves the premises. Decentralized blockchain technology does the handshaking.

• C2D enables people to sell private data while preserving privacy, as an opportunity for companies to monetize their data assets.

• C2D can also be used for data sharing in science or technology contexts, with lower liability risk, because the data doesn't move.

Community: Ocean Ecosystem

Community: Ocean Ambassadors

Community: Social Media

Ocean was founded to level the playing field for AI and data.

Ocean Protocol Concepts

Intellectual Property (IP) Concepts

Web3 Fundamentals

Decentralized Finance (DeFi) fundamentals

Data Science Terminology

Congrats! You've completed this quick introduction to Ocean.

Next: Jump to Docs main and click on your interest.

Back: FAQ

Ocean Protocol's smart contracts and OCEAN are deployed on multiple public networks: several production chains, and several testnets too.

The file address.json holds up-to-date deployment addresses for all Ocean contracts.

On tokens:

• You need the network's native token to pay for gas to make transactions: ETH for Ethereum mainnet, MATIC for Polygon, etc. You typically get these from exchanges.

• You may get OCEAN from an exchange, and bridge it as needed.

• For testnets, you'll need "fake" native tokens to pay for gas, and "fake" OCEAN. Typically, you get these from faucets.

• Below, we give token-related instructions, for each network.

Networks Summary

Here are the networks that Ocean is deployed to.

Production Networks:

• Ethereum mainnet

• Polygon mainnet

• Oasis Sapphire mainnet

• BNB Smart Chain

• Energy Web Chain

• Optimism (OP) Mainnet

• Moonriver

Test Networks:

• Görli

• Sepolia

• Oasis Sapphire testnet

• Optimism (OP) Sepolia

The rest of this doc gives details for each network. You can skip it until you need the reference information.

Production Networks

Ethereum Mainnet

Wallet. To connect to Ethereum mainnet with e.g. MetaMask, click on the network name dropdown and select "Ethereum mainnet" from the list.

Polygon Mainnet

Wallet. If you can't find Polygon Mainnet as a predefined network, follow Polygon's guide.

Bridge. Follow the Polygon Bridge guide in our docs.

Oasis Sapphire Mainnet

Ocean Predictoor is deployed on Oasis Sapphire mainnet for its ability to keep EVM transactions private. This deployment does do not currently support ocean.js, ocean.py, or Ocean Market.

Wallet. If you cannot find Oasis Sapphire Mainnet as a predefined network, fyou can manually connect by entering the following during import: Network Name: Oasis Sapphire, RPC URL: https://sapphire.oasis.io, Chain ID: 23294, Token: ROSE. For further info, see Oasis tokens docs.

Bridge. Use Celer to bridge OCEAN from Ethereum mainnet to Oasis Sapphire mainnet.

BNB Smart Chain

This is one of the Binance-spawned chains. BNB is the token of Binance.

Wallet. If BNB Smart Chain is not listed as a predefined network in your wallet, see Binance's Guide to manually connect.

Bridge. Our BNB Smart Chain Bridge Guide describes how to get OCEAN to BNB Smart Chain.

Energy Web Chain (EWC)

This is the chain for Energy Web Foundation.

Wallet. If you cannot find Energy Web Chain as a predefined network in your wallet, you can manually connect to it by following this guide.

Bridge. To bridge assets between Ethereum Mainnet and Energy Web Chain and Ethereum mainnet, you can use Omni bridge by Carbonswap.

Optimism (OP) Mainnet

Wallet. If you cannot find Optimism as a predefined network in your wallet, you can manually connect to with this OP guide.

Bridge. Follow the OP Bridge guide.

Moonriver

Moonriver is an EVM-based parachain of Kusama.

Wallet. If Moonriver is not listed as a predefined network in your wallet, you can manually connect to it by following Moonriver's guide.

Bridge. To bridge assets between Moonriver and Ethereum mainnet, you can use the Celer.

Test Networks

Unlike production networks, tokens on test networks do not hold real economic value.

Sepolia

Wallet. To connect with e.g. MetaMask, select "Sepolia" from the network dropdown list(enable "Show test networks").

Oasis Sapphire Testnet

Ocean Predictoor is deployed on Oasis Sapphire testnet. This deployment does do not currently support ocean.js, ocean.py, or Ocean Market.

Wallet. If you cannot find Oasis Sapphire Testnet as a predefined network, you can manually connect to it by entering the following during import: Network Name: Oasis Sapphire Testnet, RPC URL: https://testnet.sapphire.oasis.dev, Chain ID: 23295, Token: ROSE. For further info, see Oasis tokens docs.

Optimism (OP) Sepolia

Wallet. If OP Sepolia is not listed as a predefined network, follow OP's Guide.

Next: Bridges

Back: OCEAN: the Ocean token

Contents:

• Basic concepts

• Using wallets

• Host assets

Let's dive in!

Basic concepts

For blockchain beginners

Using wallets

Data Storage

Antique Stuff 🏺

If you have OCEAN in old pools, this will help.

If you'd like to migrate your OCEAN tokens to FET, please follow the instructions below according to the network where you currently hold your tokens:

2. Polygon - For OCEAN tokens on the Polygon network, first swap them to the Polygon (POL) token, then send it to an exchange that jas listed FET and do rest of the conversion there. You might come across the name "Matic" in some places instead of "Polygon" because the network is still using its old brand name in certain instances. Don't worry though, it's the same network whether you see Matic or Polygon.

3. Binance Smart Chain (BEP-20) - If you hold OCEAN tokens on the Binance Smart Chain network, transfer them to Binance on the BEP-20 network, where you can convert them to FET.

Have some questions about Ocean Protocol?

General

About OCEAN

Ocean Nodes

Grants, challenges, and ecosystem

Data security

Data marketplaces & Ocean Market

Contacting Ocean core team

You'll need to know a thing or two about blockchains to understand Ocean Protocol's tech... Let's get started with the basics 🧑‍🏫

Blockchain: The backbone of Ocean

Blockchain is a revolutionary technology that enables the decentralized nature of Ocean. At its core, blockchain is a distributed ledger that securely records and verifies transactions across a network of computers. It operates on the following key concepts that ensure trust and immutability:

• Decentralization: Blockchain eliminates the need for intermediaries by enabling a peer-to-peer network where transactions are validated collectively. This decentralized structure reduces reliance on centralized authorities, enhances transparency, and promotes a more inclusive data economy.

• Immutability: Once a transaction is recorded on the blockchain, it becomes virtually impossible to alter or tamper with. The data is stored in blocks, which are cryptographically linked together, forming an unchangeable chain of information. Immutability ensures the integrity and reliability of data, providing a foundation of trust in the Ocean ecosystem. Furthermore, it enables reliable traceability of historical transactions.

• Consensus Mechanisms: Blockchain networks employ consensus mechanisms to validate and agree upon the state of the ledger. These mechanisms ensure that all participants validate transactions without relying on a central authority, crucially maintaining a reliable view of the blockchain's history. The consensus mechanisms make it difficult for malicious actors to manipulate the blockchain's history or conduct fraudulent transactions. Popular consensus mechanisms include Proof of Work (PoW) and Proof of Stake (PoS).

Ocean harnesses the power of blockchain to facilitate secure and auditable data exchange. This ensures that data transactions are transparent, verifiable, and tamper-proof. Here's how Ocean uses blockchains:

• Data Asset Representation: Data assets in Ocean are represented as non-fungible tokens (NFTs) on the blockchain. NFTs provide a unique identifier for each data asset, allowing for seamless tracking, ownership verification, and access control. Through NFTs and datatokens, data assets become easily tradable and interoperable within the Ocean ecosystem.

• Smart Contracts: Ocean uses smart contracts to automate and enforce the terms of data exchange. Smart contracts act as self-executing agreements that facilitate the transfer of data assets between parties based on predefined conditions - they are the exact mechanisms of decentralization. This enables cyber-secure data transactions and eliminates the need for intermediaries.

• Tamper-Proof Audit Trail: Every data transaction on Ocean is recorded on the blockchain, creating an immutable and tamper-proof audit trail. This ensures the transparency and traceability of data usage, providing data scientists with a verifiable record of the data transaction history. Data scientists can query addresses of data transfers on-chain to understand data usage.

By integrating blockchain technology, Ocean establishes a trusted infrastructure for data exchange. It empowers individuals and organizations to securely share, monetize, and leverage data assets while maintaining control and privacy.

The most important thing to remember is that wherever you host your asset... it needs to be reachable & downloadable. It cannot live behind a private firewall such as a private Github repo. You need to use a proper hosting service!

The URL to your asset is encrypted in the publishing process!

Publish. Cool. Things.

If you want to publish cool things on the Ocean Marketplace, then you'll first need a place to host your assets as Ocean doesn't store data; you're responsible for hosting it on your chosen service and providing the necessary details for publication. You have SO many options where to host your asset including centralized and decentralized storage systems. Places to host may include: Github, IPFS, Arweave, AWS, Azure, Google Cloud, and your own personal home server (if that's you, then you probably don't need a tutorial on hosting assets). Really, anywhere with a downloadable link to your asset is fine.

In this section, we'll walk you through three options to store your assets: Arweave (decentralized storage), AWS (centralized storage), and Azure (centralized storage). Let's goooooo!

Read on, if you are interested in the security details!

Security Considerations

We recommend implementing a security policy that allows only the Provider's IP address to access the file and blocks requests from other unauthorized actors is recommended. Since not all hosting services provide this feature, you must carefully consider the security features while choosing a hosting service.

Ocean Protocol users require an ERC-20 compatible wallet to manage their OCEAN and ETH tokens. In this guide, we will provide some recommendations for different wallet options.

What is a wallet?

In the blockchain world, a wallet is a software program that stores cryptocurrencies secured by private keys to allow users to interact with the blockchain network. Private keys are used to sign transactions and provide proof of ownership for the digital assets stored on the blockchain. Wallets can be used to send and receive digital currencies, view account balances, and monitor transaction history. There are several types of wallets, including desktop wallets, mobile wallets, hardware wallets, and web-based wallets. Each type of wallet has its own unique features, advantages, and security considerations.

Recommendations

Related Terminology

When you set up a new wallet, it might generate a seed phrase for you. Store that seed phrase somewhere secure and non-digital (e.g. on paper in a safe). It's extremely secret and sensitive. Anyone with your wallet's seed phrase could spend all tokens of all the accounts in your wallet.

Once your wallet is set up, it will have one or more accounts.

Each account has several balances, e.g. an Ether balance, an OCEAN balance, and maybe other balances. All balances start at zero.

An account's Ether balance might be 7.1 ETH in the Ethereum Mainnet, 2.39 ETH in Görli testnet. You can move ETH from one network to another only with a special setup exchange or bridge. Also, you can't transfer tokens from networks holding value such as Ethereum mainnet to networks not holding value, i.e., testnets like Görli. The same is true of the OCEAN balances.

Each account has one private key and one address. The address can be calculated from the private key. You must keep the private key secret because it's what's needed to spend/transfer ETH and OCEAN (or to sign transactions of any kind). You can share the address with others. In fact, if you want someone to send some ETH or OCEAN to an account, you give them the account's address.

Before you can publish or purchase assets, you will need a crypto wallet. As Metamask is one of the most popular crypto wallets around, we made a tutorial to show you how to get started with Metamask to use Ocean's tech.

Set up

• Install MetaMask. The wallet provides a friendly user interface that will help you through each step. MetaMask gives you two options: importing an existing wallet or creating a new one. Choose to Create a Wallet:

• In the next step create a new password for your wallet. Read through and accept the terms and conditions. After that, MetaMask will generate Secret Backup Phrase for you. Write it down and store it in a safe place.

• Continue forward. On the next page, MetaMask will ask you to confirm the backup phrase. Select the words in the correct sequence:

• Voila! Your account is now created. You can access MetaMask via the browser extension in the top right corner of your browser.

• You can now manage ETH and OCEAN with your wallet. You can copy your account address to the clipboard from the options. When you want someone to send ETH or OCEAN to you, you will have to give them that address. It's not a secret.

Set Up Custom Network

Sometimes it is required to use custom or external networks in MetaMask. We can add a new one through MetaMask's Settings.

Open the Settings menu and find the Networks option. When you open it, you'll be able to see all available networks your MetaMask wallet currently use. Click the Add Network button.

There are a few empty inputs we need to fill in:

• Network Name: this is the name that MetaMask is going to use to differentiate your network from the rest.

• New RPC URL: to operate with a network we need an endpoint (RPC). This can be a public or private URL.

• Chain Id: each chain has an Id

• Currency Symbol: it's the currency symbol MetaMask uses for your network

• Block Explorer URL: MetaMask uses this to provide a direct link to the network block explorer when a new transaction happens

When all the inputs are filled just click Save. MetaMask will automatically switch to the new network.

What is Ocean Uploader?

What decentralized storage options are available?

Currently, we support Arweave and IPFS. We may support other storage options in the future.

Amazon Web Services

AWS provides various options to host data and multiple configuration possibilities. Publishers are required to do their research and decide what would be the right choice. The below steps provide one of the possible ways to host data using an AWS S3 bucket and publish it on Ocean Marketplace.

Prerequisite

Step 1 - Create a storage account

Go to AWS portal

Go to the AWS portal for S3: https://aws.amazon.com/s3/ and select from the upper right corner Create an AWS account as shown below.

Fill in the details

Create a bucket

After logging into the new account, search for the available services and select S3 type of storage.

To create an S3 bucket, choose Create bucket.

Fill in the form with the necessary information. Then, the bucket is up & running.

Step 2 - Upload asset on S3 bucket

Now, the asset can be uploaded by selecting the bucket name and choosing Upload in the Objects tab.

Add files to the bucket

Get the files and add them to the bucket.

The permissions and properties can be set afterward, for the moment keep them as default.

After selecting Upload, make sure that the status is Succeeded.

Step 3 - Access the Object URL on S3 Bucket

By default, the permissions of accessing the file from the S3 bucket are set to private. To publish an asset on the market, the S3 URL needs to be public. This step shows how to set up access control policies to grant permissions to others.

Editing permissions

Go to the Permissions tab and select Edit and then uncheck Block all public access boxes to give everyone read access to the object and click Save.

If editing the permissions is unavailable, modify the Object Ownership by enabling the ACLs as shown below.

Modifying bucket policy

To have the bucket granted public access, its policy needs to be modified likewise.

Note that the <BUCKET-NAME> must be chosen from the personal buckets dashboard.

After saving the changes, the bucket should appear as Public access.

Verify the object URL on public access

Select the file from the bucket that needs verification and select Open. Now download the file on your system.

Step 4 - Get the S3 Bucket Link & Publish Asset on Market

Now that the S3 endpoint has public access, the asset will be hosted successfully.

Microsoft Azure

Azure provides various options to host data and multiple configuration possibilities. Publishers are required to do their research and decide what would be the right choice. The below steps provide one of the possible ways to host data using Azure storage and publish it on Ocean Marketplace.

Prerequisite

Step 1 - Create a storage account

Go to Azure portal

Go to the Azure portal: https://portal.azure.com/#home and select Storage accounts as shown below.

Create a new storage account

Fill in the details

Storage account created

Step 2 - Create a blob container

Step 3 - Upload a file

Step 4 - Share the file

Select the file to be published and click Generate SAS

Configure the SAS details and click Generate SAS token and URL

Copy the generated link

Step 5 - Publish the asset using the generated link

Now, copy and paste the link into the Publish page in the Ocean Marketplace.

Using Arweave with Uploader

Arweave

Step 1 - Get a new wallet and AR tokens

At the time of writing, the faucet provides 0.02 AR which is more than enough to upload a file.

Step 2 - Load the key file into the arweave.app web wallet

Step 3 - Upload file

Select the newly imported wallet by clicking the "blockies" style icon in the top left corner of the screen. Select Send. Click the Data field and select the file you wish to upload.

The fee in AR tokens will be calculated based on the size of the file and displayed near the bottom middle part of the screen. Select Submit to submit the transaction.

After submitting the transaction, select Transactions and wait until the transaction appears and eventually finalizes. This can take over 5 minutes so please be patient.

Step 4 - Copy the transaction ID

Once the transaction finalizes, select it, and copy the transaction ID.

Step 5 - Publish the asset with the transaction ID

What can you build with Ocean?

1. Token-gated dApps & REST APIs: monetize by making your dApp or its REST API token-gated. Here's how.

2. AI dApps: monetize your AI dApp by token-gating on AI training data, feature vectors, models, or predictions.

3. Data Markets: build a decentralized data market. Here's how

4. Private user profile data: storing user profile data on your centralized server exposes you to liability. Instead, have it on-chain encrypted by the user's wallet, and just-in-time decrypt for the app. Video, slides.

Example live dapps:

• Data Markets: Acentrik Market for enterprises, and Ocean Market for general.

• Token-gated dapps: Autobot for analytics, and Ocean Waves for music.

• Token-gated feeds: Ocean Predictoor for AI prediction feeds

How do developers start using Ocean?

• App level: Use an Ocean Template.

• Library level: Use ocean.js is a library built for the key environment of dApp developers: JavaScript. Import it & use it your frontend or NodeJS.

• Contract level: Call Ocean contracts on Eth mainnet or other chains.

Developer Docs Quick-links

• Architecture - blockchain/contracts layer, middleware, dapps

• Earning revenue: code to get payment, fractional $, community $

• Schemas: Metadata, identifiers/DIDs, identifier objects/DDOs, storage, fine-grained permissions

• Components:

  • Barge - local chain for testing

  • Ocean subgraph - grabbing event data from the chain

  • Ocean CLI - command-line interface

  • Compute-to-data - practical privacy approach

  • Aquarius - metadata cache

  • Provider - handshaking for access control

• FAQ

Next: Architecture

Fungible tokens are a type of digital asset that are identical and interchangeable with each other. Each unit of a fungible token holds the same value and can be exchanged on a one-to-one basis. This means that one unit of a fungible token is indistinguishable from another unit of the same token. Examples of fungible tokens include cryptocurrencies like Bitcoin (BTC) and Ethereum (ETH), where each unit of the token is equivalent to any other unit of the same token. Fungible tokens are widely used for transactions, trading, and as a means of representing value within blockchain-based ecosystems.

What is a Datatoken?

Datatokens are fundamental within Ocean Protocol, representing a key mechanism to access data assets in a decentralized manner. In simple terms, a datatoken is an ERC20-compliant token that serves as access control for a data/service represented by a data NFT.

Datatokens enable data assets to be tokenized, allowing them to be easily traded, shared, and accessed within the Ocean Protocol ecosystem. Each datatoken is associated with a particular data asset, and its value is derived from the underlying dataset's availability, scarcity, and demand.

By using datatokens, data owners can retain ownership and control over their data while still enabling others to access and utilize it based on predefined license terms. These license terms define the conditions under which the data can be accessed, used, and potentially shared by data consumers.

Understanding Datatokens and Licenses

Each datatoken represents a sub-license from the base intellectual property (IP) owner, enabling users to access and consume the associated dataset. The license terms can be set by the data NFT owner or default to a predefined "good default" license. The fungible nature of ERC20 tokens aligns perfectly with the fungibility of licenses, facilitating seamless exchangeability and interoperability between different datatokens.

By adopting the ERC20 standard for datatokens, Ocean Protocol ensures compatibility and interoperability with a wide array of ERC20-based wallets, decentralized exchanges (DEXes), decentralized autonomous organizations (DAOs), and other blockchain-based platforms. This standardized approach enables users to effortlessly transfer, purchase, exchange, or receive datatokens through various means such as marketplaces, exchanges, or airdrops.

Utilizing Datatokens

Data owners and consumers can engage with datatokens in numerous ways. Datatokens can be acquired through transfers or obtained by purchasing them on dedicated marketplaces or exchanges. Once in possession of the datatokens, users gain access to the corresponding dataset, enabling them to utilize the data within the boundaries set by the associated license terms.

Once someone has generated datatokens, they can be used in any ERC20 exchange, centralized or decentralized. In addition, Ocean provides a convenient default marketplace that is tuned for data: Ocean Market. It’s a vendor-neutral reference data marketplace for use by the Ocean community.

You can publish a data NFT initially with no ERC20 datatoken contracts. This means you simply aren’t ready to grant access to your data asset yet (sub-license it). Then, you can publish one or more ERC20 datatoken contracts against the data NFT. One datatoken contract might grant consume rights for 1 day, another for 1 week, etc. Each different datatoken contract is for different license terms.

Liquidity pools and dynamic pricing used to be supported in previous versions of the Ocean Market. However, these features have been deprecated and now we advise everyone to remove their liquidity from the remaining pools. It is no longer possible to do this via Ocean Market, so please follow this guide to remove your liquidity via etherscan.

Remove liquidity using Etherscan

Get your balance of pool share tokens

1. Go to the pool's Etherscan/Polygonscan page. You can find it by inspecting your transactions on your account's Etherscan page under Erc20 Token Txns.

2. Click View All and look for Ocean Pool Token (OPT) transfers. Those transactions always come from the pool contract, which you can click on.

3. On the pool contract page, go to Contract -> Read Contract.

4. Go to field 20. balanceOf and insert your ETH address. This will retrieve your pool share token balance in wei.

5. Copy this number as later you will use it as the poolAmountIn parameter.

6. Go to field 55. totalSupply to get the total amount of pool shares, in wei.

7. Divide the number by 2 to get the maximum of pool shares you can send in one pool exit transaction. If your number retrieved in former step is bigger, you have to send multiple transactions.

8. Go to Contract -> Write Contract and connect your wallet. Be sure to have your wallet connected to network of the pool.

9. Go to the field 5. exitswapPoolAmountIn

• For poolAmountIn add your pool shares in wei

• For minAmountOut use anything, like 1

• Hit Write

10. Confirm transaction in Metamask

Google Storage

Google Cloud Storage is a scalable and reliable object storage service provided by Google Cloud. It allows you to store and retrieve large amounts of unstructured data, such as files, with high availability and durability. You can organize your data in buckets and benefit from features like access control, encryption, and lifecycle management. With various storage classes available, you can optimize cost and performance based on your data needs. Google Cloud Storage integrates seamlessly with other Google Cloud services and provides APIs for easy integration and management.

Prerequisite

Create an account on Google Cloud. Users might also be asked to provide payment details and billing addresses that are out of this tutorial's scope.

Step 1 - Create a storage account

Go to Google Cloud console

In the Google Cloud console, go to the Cloud Storage Buckets page

Create a new bucket

Fill in the details

Allow access to your recently created Bucket

Step 2 - Upload a file

Step 3 - Change your file's access (optional)

If your bucket's access policy is restricted, on the menu on the right click on Edit access (skip this step if your bucket is publicly accessible)

Step 4 - Share the file

Open the file and copy the generated link

Step 5 - Publish the asset using the generated link

Now, copy and paste the link into the Publish page in the Ocean Marketplace.

Ocean Nodes are a vital part of the Ocean Protocol core technology stack. The Ocean Nodes monorepo that replaces the three previous components: Provider, Aquarius and subgraph. It has been designed to significantly simplify the process of starting the Ocean stack - it runs everything you need with one simple command.

It integrates multiple services for secure and efficient data operations, utilizing technologies like libp2p for peer-to-peer communication. Its modular and scalable architecture supports various use cases, from simple data retrieval to complex compute-to-data (C2D) tasks.

The node is structured into separate layers, including the network layer for communication, and the components layer for core services like the Indexer and Provider. This layered architecture ensures efficient data management and high security.

Flexibility and extensibility are key features of Ocean Node, allowing multiple compute engines, such as Docker and Kubernetes, to be managed within the same framework. The orchestration layer coordinates interactions between the core node and execution environments, ensuring the smooth operation of compute tasks.

For details on how to run a node see the readme in the GitHub repository.

However, your nodes must meet specific criteria in order to be eligible for incentives. Here’s what’s required:

1. Public Accessibility: Nodes must have a public IP address

2. API and P2P Ports: Nodes must expose both HTTP API and P2P ports to facilitate seamless communication within the network

You can easily check the eligibility of the nodes by connecting to the Ocean Nodes Dashboard and looking for the green status indicator next to your IP address

Follow the steps to install the Node and be eligible for rewards-

1. Find your public IP: You’ll need this for the configuration. You can easily find it by googling “my IP”

2. Run the Quickstart Guide: If you’ve already deployed a node, we recommend either redeploying with the guide or ensuring that your environment variables are correct and you’re running the latest version

3. Get your Node ID: After starting the node, you can retrieve the ID from the console

1. Expose Your Node to the Internet: From a different device, check if your node is accessible by running - telnet{your ip}{P2P_ipV4BindTcpPort}

2. To forward the node port, please follow the instructions provided by your router manufacturer — ex: Asus, TpLink, Huawei, Mercusys etc.

Verify eligibility on the Ocean Node Dashboard: Check https://nodes.oceanprotocol.com/ and search for your peerID to ensure your node is correctly configured.

Ocean Nodes replace the Provider:

• The Node is the only component that can access your data

• It performs checks on-chain for buyer permissions and payments

• Encrypts the URL and metadata during publish

• Decrypts the URL when the dataset is downloaded or a compute job is started

• Provides access to data assets by streaming data (and never the URL)

• Provides compute services (connects to C2D environment)

• Typically run by the Data owner

Ocean Nodes replace Aquarius:

• A new component called Indexer replaces the functionality of Aquarius.

• The indexer acts as a cache for on-chain data. It stores the metadata from the smart contract events off-chain in a Typesense database.

• It monitors events: It continually checks for MetadataCreated and MetadataUpdated events, processing these events and updating them in the database.

• Serves as an API: It provides a REST API that fetches data from the off-chain datastore.

• Offers easy query access: The API provides a convenient method to access metadata without scanning the blockchain.

Ocean Nodes replace the Subgraph:

• Indexing the data from the smart contact events.

• The data is indexed and updated in real-time.

• Providing an API which receives and responds to queries.

• Simplifying the development experience for anyone building on Ocean.

API

For details on all of the HTTP endpoints exposed by the Ocean Nodes API, refer to the API.md file in the github repository.

Compute to Data (C2D)

The Ocean nodes provide a convenient and easy way to run a compute-to-data environment. This gives you the opportunity to monetize your node as you can charge fees for using the C2D environment and there are also additional incentives provided Ocean Protocol Foundation (OPF). Soon we will also be releasing C2D V2 which will provide different environments and new ways to pay for computation.

For more details on the C2D V2 architecture, refer to the documentation in the repository:\

In summary: A data NFT serves as a representation of the copyright or exclusive license for a data asset on the blockchain, known as the base IP. Datatokens, on the other hand, function as a crucial mechanism for decentralized access to data assets.

For a specific data NFT, multiple ERC20 datatoken contracts can exist. Here's the main concept: Owning 1.0 datatokens grants you the ability to consume the corresponding dataset. Essentially, it acts as a sub-license from the base IP, allowing you to utilize the dataset according to the specified license terms (when provided by the publisher). License terms can be established with a "good default" or by the Data NFT owner.

The choice to employ the ERC20 fungible token standard for datatokens is logical, as licenses themselves are fungible. This standard ensures compatibility and interoperability of datatokens with ERC20-based wallets, decentralized exchanges (DEXes), decentralized autonomous organizations (DAOs), and other relevant platforms. Datatokens can be transferred, acquired through marketplaces or exchanges, distributed via airdrops, and more.

You can publish a data NFT initially with no ERC20 datatoken contracts. This means you simply aren’t ready to grant access to your data asset yet (sub-license it). Then, you can publish one or more ERC20 datatoken contracts against the data NFT. One datatoken contract might grant consume rights for 1 day, another for 1 week, etc. Each different datatoken contract is for different license terms.

For a more comprehensive exploration of intellectual property and its practical connections with ERC721 and ERC20, you can read the blog post written by Trent McConaghy, co-founder of Ocean Protocol. It delves into the subject matter in detail and provides valuable insights.

DataNFTs and Datatokens example:

• In step 1, Alice publishes her dataset with Ocean: this means deploying an ERC721 data NFT contract (claiming copyright/base IP), then an ERC20 datatoken contract (license against base IP). Then Alice mints an ERC20 datatokens

• In step 2, Alice transfers 1.0 of them to Bob's wallet; now he has a license to be able to download that dataset.

What happends under the hood? 🤔

Publishing with smart contracts in Ocean Protocol involves a well-defined process that streamlines the publishing of data assets. It provides a systematic approach to ensure efficient management and exchange of data within the Ocean Protocol ecosystem. By leveraging smart contracts, publishers can securely create and deploy data NFTs, allowing them to tokenize and represent their data assets. Additionally, the flexibility of the smart contracts enables publishers to define pricing schemas for datatokens, facilitating fair and transparent transactions. This publishing framework empowers data publishers by providing them with greater control and access to a global marketplace, while ensuring trust, immutability, and traceability of their published data assets.

The smart contracts publishing includes the following steps:

1. The data publisher initiates the creation of a new data NFT.

2. The data NFT factory deploys the template for the new data NFT.

3. The data NFT template creates the data NFT contract.

4. The address of the newly created data NFT is available to the data publisher.

5. The publisher is now able to create datatokens with pricing schema for the data NFT. To accomplish this, the publisher initiates a call to the data NFT contract, specifically requesting the creation of a new datatoken with a fixed rate schema.

6. The data NFT contract deploys a new datatoken and a fixed rate schema by interacting with the datatoken template contract.

7. The datatoken contract is created (Datatoken-1 contract).

8. The datatoken template generates a new fixed rate schema for Datatoken-1.

9. The address of Datatoken-1 is now available to the data publisher.

10. Optionally, the publisher can create a new datatoken (Datatoken-2) with a free price schema.

11. The data NFT contract interacts with the Datatoken Template contract to create a new datatoken and a dispenser schema.

12. The datatoken templated deploys the Datatoken-2 contract.

13. The datatoken templated creates a dispenser for the Datatoken-2 contract.

Below is a visual representation that illustrates the flow:

We have some awesome hands-on experience when it comes to publishing a data NFT and minting datatokens.

• Publish using ocean.py

• Publish using ocean.js

Other References

• Data & NFTs 1: Practical Connections of ERC721 with Intellectual Property

• Data & NFTs 2: Leveraging ERC20 Fungibility

• Data & NFTs 3: Combining ERC721 & ERC20

• Fungibility sightings in NFTs

A non-fungible token stored on the blockchain represents a unique asset. NFTs can represent images, videos, digital art, or any piece of information. NFTs can be traded, and allow the transfer of copyright/base IP. EIP-721 defines an interface for handling NFTs on EVM-compatible blockchains. The creator of the NFT can deploy a new contract on Ethereum or any Blockchain supporting NFT-related interface and also, transfer the ownership of copyright/base IP through transfer transactions.

What is a Data NFT?

A data NFT represents the copyright (or exclusive license against copyright) for a data asset on the blockchain — we call this the “base IP”. When a user publishes a dataset in Ocean, they create a new NFT as part of the process. This data NFT is proof of your claim of base IP. Assuming a valid claim, you are entitled to the revenue from that asset, just like a title deed gives you the right to receive rent.

The data NFT smart contract holds metadata about the data asset, stores roles like “who can mint datatokens” or “who controls fees”, and an open-ended key-value store to enable custom fields.

If you have the private key that controls the NFT, you own that NFT. The owner has the claim on the base IP and is the default recipient of any revenue. They can also assign another account to receive revenue. This enables the publisher to sell their base IP and the revenues that come with it. When the Data NFT is transferred to another user, all the information about roles and where the revenue should be sent is reset. The default recipient of the revenue is the new owner of the data NFT.

Key Features and Functionality

Data NFTs offer several key features and functionalities within the Ocean Protocol ecosystem:

1. Ownership and Transferability: Data NFTs establish ownership rights, enabling data owners to transfer or sell their data assets to other participants in the network.

2. Metadata and Descriptions: Each Data NFT contains metadata that describes the associated dataset, providing essential information such as title, description, creator, and licensing terms.

3. Access Control and Permissions: Data NFTs can include access control mechanisms, allowing data owners to define who can access and utilize their datasets, as well as the conditions and terms of usage.

4. Interoperability: Data NFTs conform to the ERC721 token standard, ensuring interoperability across various platforms, wallets, and marketplaces within the Ethereum ecosystem.

Data NFTs Open Up New Possibilities

By tokenizing data assets into Data NFTs, data owners can establish clear ownership rights and enable seamless transferability of the associated datasets. Data NFTs serve as digital certificates of authenticity, enabling data consumers to trust the origin and integrity of the data they access.

With data NFTs, you are able to take advantage of the broader NFT ecosystem and all the tools and possibilities that come with it. As a first example, many leading crypto wallets have first-class support for NFTs, allowing you to manage data NFTs from those wallets. Or, you can post your data NFT for sale on a popular NFT marketplace like OpenSea or Rarible. As a final example, we’re excited to see data NFTs linked to physical items via WiseKey chips.

Implementation in Ocean Protocol

We have implemented data NFTs using the ERC721 standard. Ocean Protocol defines the ERC721Factory contract, allowing Base IP holders to create their ERC721 contract instances on any supported networks. The deployed contract stores Metadata, ownership, sub-license information, and permissions. The contract creator can also create and mint ERC20 token instances for sub-licensing the Base IP.

ERC721 tokens are non-fungible, and thus cannot be used for automatic price discovery like ERC20 tokens. ERC721 and ERC20 combined together can be used for sub-licensing. Ocean Protocol's ERC721Template solves this problem by using ERC721 for tokenizing the Base IP and tokenizing sub-licenses by using ERC20. To save gas fees, it uses ERC1167 proxy approach on the ERC721 template.

Our implementation has been built on top of the battle-tested OpenZeppelin contract library. However, there are a bunch of interesting parts of the implementation that go a bit beyond an out-of-the-box NFT. The data NFTs can be easily managed from any NFT marketplace like OpenSea.

Something else that we’re super excited about in the data NFTs is a cutting-edge standard called ERC725 being driven by our friends at Lukso. The ERC725y feature enables the NFT owner (or a user with the “store updater” role) to input and update information in a key-value store. These values can be viewed externally by anyone.

ERC725y is incredibly flexible and can be used to store any string; you could use it for anything from additional metadata to encrypted values. This helps future-proof the data NFTs and ensure that they are suitable for a wide range of projects that have not been launched yet. As you can imagine, the inclusion of ERC725y has huge potential and we look forward to seeing the different ways people end up using it. If you’re interested in using this, take a look at EIP725.

Embark on an exploration of the innovative realm of Ocean Protocol, where data flows seamlessly and AI achieves new heights. Dive into the intricately layered architecture that converges data and services, fostering a harmonious collaboration. Let us delve deep and uncover the profound design of Ocean Protocol.🐬

Layer 1: The Foundational Blockchain Layer

At the core of Ocean Protocol lies the robust Blockchain Layer. Powered by blockchain technology, this layer ensures secure and transparent transactions. It forms the bedrock of decentralized trust, where data providers and consumers come together to trade valuable assets.

The smart contracts are deployed on the Ethereum mainnet and other compatible networks. The libraries encapsulate the calls to these smart contracts and provide features like publishing new assets, facilitating consumption, managing pricing, and much more. To explore the contracts in more depth, go ahead to the contracts section.

Layer 2: The Empowering Middle Layer

Above the smart contracts, you'll find essential libraries employed by applications within the Ocean Protocol ecosystem, the middleware components, and Compute-to-Data.

Libraries

These libraries include Ocean.js, a JavaScript library, and Ocean.py, a Python library. They serve as powerful tools for developers, enabling integration and interaction with the protocol.

1. Ocean.js: Ocean.js is a JavaScript library that serves as a powerful tool for developers looking to integrate their applications with the Ocean Protocol ecosystem. Designed to facilitate interaction with the protocol, Ocean.js provides a comprehensive set of functionalities, including data tokenization, asset management, and smart contract interaction. Ocean.js simplifies the process of implementing data access controls, building dApps, and exploring data sets within a decentralized environment.

2. Ocean.py: Ocean.py is a Python library that empowers developers to integrate their applications with the Ocean Protocol ecosystem. With its rich set of functionalities, Ocean.py provides a comprehensive toolkit for interacting with the protocol. Developers and data scientists can leverage Ocean.py to perform a wide range of tasks, including data tokenization, asset management, and smart contract interactions. This library serves as a bridge between Python and the decentralized world of Ocean Protocol, enabling you to harness the power of decentralized data.

Ocean Nodes

Ocean Node is a single component which runs all core middleware services within the Ocean stack. It replaces the roles of Aquarius, Provider and the Subgraph. It integrates the Indexer for metadata management and the Provider for secure data access. It ensures efficient and reliable interactions within the Ocean Protocol network.

Ocean Nodes handles network communication through libp2p, supports secure data handling, and enables flexible compute-to-data operations.

The functions of Ocean nodes include:

• It is crucial in handling the asset downloads, it streams the purchased data directly to the buyer.

• It conducts the permission an access checks during the consume flow.

• The Node handles new DDO structure (Decentralized Data Object) encryption, but it offers support for existing DDO format.

• It establishes communication with the operator-service for initiating Compute-to-Data jobs.

• It provides a metadata cache, enhancing search efficiency by caching on-chain data into a Typesense database. This enables faster and more efficient data discovery.

• It supports multiple chains.

Old components

Previously Ocean used the following middleware components:

1. Aquarius

2. Provider

3. Subgraph

Compute-to-Data

Compute-to-Data (C2D) represents a groundbreaking paradigm within the Ocean Protocol ecosystem, revolutionizing the way data is processed and analyzed. With C2D, the traditional approach of moving data to the computation is inverted, ensuring privacy and security. Instead, algorithms are securely transported to the data sources, enabling computation to be performed locally, without the need to expose sensitive data. This innovative framework facilitates collaborative data analysis while preserving data privacy, making it ideal for scenarios where data owners want to retain control over their valuable assets. C2D provides a powerful tool for enabling secure and privacy-preserving data analysis and encourages collaboration among data providers, ensuring the utilization of valuable data resources while maintaining strict privacy protocols.

Layer 3: The Accessible Application Layer

Here, the ocean comes alive with a vibrant ecosystem of dApps, marketplaces, and more. This layer hosts a variety of user-friendly interfaces, applications, and tools, inviting data scientists and curious explorers alike to access, explore, and contribute to the ocean's treasures.

Prominently featured within this layer is Ocean Market, a hub where data enthusiasts and industry stakeholders converge to discover, trade, and unlock the inherent value of data assets. Beyond Ocean Market, the Application Layer hosts a diverse ecosystem of specialized applications and marketplaces, each catering to unique use cases and industries. Empowered by the capabilities of Ocean Protocol, these applications facilitate advanced data exploration, analytics, and collaborative ventures, revolutionizing the way data is accessed, shared, and monetized.

Layer 4: The Friendly Wallets

At the top of the Ocean Protocol ecosystem, we find the esteemed Web 3 Wallets, the gateway for users to immerse themselves in the world of decentralized data transactions. These wallets serve as trusted companions, enabling users to seamlessly transact within the ecosystem, purchase and sell data NFTs, and acquire valuable datatokens. For a more detailed exploration of Web 3 Wallets and their capabilities, you can refer to the wallet intro page.

With the layers of the architecture clearly delineated, the stage is set for a comprehensive exploration of their underlying logic and intricate design. By examining each individually, we can gain a deeper understanding of their unique characteristics and functionalities.

Ocean Nodes are the core infrastructure component within the Ocean Protocol ecosystem, designed to facilitate decentralized data exchange and management. It operates by leveraging a multi-layered architecture that includes network, components, and module layers.

Key features include secure peer-to-peer communication via libp2p, flexible and secure encryption solutions, and support for various Compute-to-Data (C2D) operations.

Ocean Node's modular design allows for customization and scalability, enabling seamless integration of its core services—such as the Indexer for metadata management and the Provider for secure data transactions—ensuring robust and efficient decentralized data operations.

Architecture Overview

The Node stack is divided into the following layers:

• Network layer (libp2p & HTTP API)

• Components layer (Indexer, Provider)

• Modules layer

Features

• libp2p supports ECDSA key pairs, and node identity should be defined as a public key.

• Multiple ways of storing URLs:

  • Choose one node and use that private key to encrypt URLs (enterprise approach).

  • Choose several nodes, so your files can be accessed even if one node goes down (given at least one node is still alive).

• Supports multiple C2D types:

  • Light Docker only (for edge nodes).

  • Ocean C2D (Kubernetes).

• Each component can be enabled/disabled on startup (e.g., start node without Indexer).

Nodes and Network Model

Nodes can receive user requests in two ways:

• HTTP API

• libp2p from another node

They are merged into a common object and passed to the appropriate component.

Nodes should be able to forward requests between them if the local database is missing objects. (Example: Alice wants to get DDO id #123 from Node A. Node A checks its local database. If the DDO is found, it is sent back to Alice. If not, Node A can query the network and retrieve the DDO from another node that has it.)

Nodes' libp2p implementation:

• Should support core protocols (ping, identify, kad-dht for peering, circuit relay for connections).

• For peer discovery, we should support both mDNS & Kademlia DHT.

• All Ocean Nodes should subscribe to the topic: OceanProtocol. If any interesting messages are received, each node is going to reply.

Components & Modules

Indexer

An off-chain, multi-chain metadata & chain events cache. It continually monitors the chains for well-known events and caches them (V4 equivalence: Aquarius).

Features:

• Monitors MetadataCreated, MetadataUpdated, MetadataState and stores DDOs in the database.

• Validates DDOs according to multiple SHACL schemas. When hosting a node, you can provide your own SHACL schema or use the ones provided.

• Provides proof for valid DDOs.

• Monitors all transactions and events from the data token contracts. This includes minting tokens, creating pricing schema (fixed & free pricing), and orders.

• Allows queries for all the above.

Provider

• Performs checks on-chain for buyer permissions and payments.

• The provider is crucial in checking that all the relevant fees have been paid before the consumer is able to download the asset. See the Fees page for details on all of the different types of fees.

• Encrypts the URL and metadata during publishing.

• Decrypts the URL when the dataset is downloaded or a compute job is started.

• Encrypts/decrypts files before storage/while accessing.

• Provides access to data assets by streaming data (and never the URL).

• Provides compute services.

• The node operator can charge provider fees, compensating the individuals or organizations operating their own node when users request assets.

• Currently, we are providing the legacy Ocean C2D compute services (which run in Kubernetes) via the node. In the future, we will soon be releasing C2D V2 which will also allow connections to multiple C2D engines: light, Ocean C2D, and third parties.

For more details on the C2D V2 architecture, refer to the documentation in the repository:

The suite of smart contracts serve as the backbone of the decentralized data economy. These contracts facilitate secure, transparent, and efficient interactions among data providers, consumers, and ecosystem participants.

However, Ocean V3 faced limitations in terms of flexibility. It lacked support for different licenses associated with the same base IP, such as 1-day versus 1-month access, and the transferability of the base IP was not possible. Additionally, the ERC20 datatoken template was hardcoded, restricting customization options.

Ocean brings forth enhanced opportunities for dApp owners, creating a conducive environment for the emergence of a thriving market of third-party Providers.

Key features of the smart contracts:

• Interoperability with the NFT ecosystem (and DeFi & DAO tools).

• Besides base data IP, you can use data NFTs to implement comments & ratings, verifiable claims, identity credentials, and social media posts. They can point to parent data NFTs, enabling the nesting of comments on comments, or replies to tweets. All on-chain, GDPR-compliant, easily searched, with js & py drivers 🤯

• When the NFT is transferred, it auto-updates all permissions, e.g. who receives payment, or who can mint derivative ERC20 datatokens.

• Key-value store in the NFT contract: NFT contract can be used to store custom key-value pairs (ERC725Y standard) enabling applications like soulbound tokens and Sybil protection approaches 🗃️

• Multiple NFT template support: the Factory can deploy different types of NFT templates 🖼️

Fractional ownership represents an exciting subset within the realm of Web3, combining the realms of NFTs and DeFi. It introduces the concept of co-owning data intellectual property (IP).

Ocean offers two approaches to facilitate fractional ownership:

1. Sharded Holding of ERC20 Datatokens: Under this approach, each holder of ERC20 tokens possesses the typical datatoken rights outlined earlier. For instance, owning 1.0 datatoken allows consumption of a particular asset. Ocean conveniently provides this feature out of the box.

2. Sharding ERC721 Data NFT: This method involves dividing the ownership of an ERC721 data NFT among multiple individuals, granting each co-owner the right to a portion of the earnings generated from the underlying IP. Moreover, these co-owners collectively control the data NFT. For instance, a dedicated DAO may be established to hold the data NFT, featuring its own ERC20 token. DAO members utilize their tokens to vote on updates to data NFT roles or the deployment of ERC20 datatokens associated with the ERC721.

It's worth noting that for the second approach, one might consider utilizing platforms like Niftex for sharding. However, important questions arise in this context:

• What specific rights do shard-holders possess?

• It's possible that they have limited rights, just as Amazon shareholders don't have the authority to roam the hallways of Amazon's offices simply because they own shares

• Additionally, how do shard-holders exercise control over the data NFT?

These concerns are effectively addressed by employing a tokenized DAO, as previously described.

Data DAOs present a fascinating use case whenever a group of individuals desires to collectively manage data or consolidate data for increased bargaining power. Such DAOs can take the form of unions, cooperatives, or trusts.

Consider the following example involving a mobile app: You install the app, which includes an integrated crypto wallet. After granting permission for the app to access your location data, it leverages the DAO to sell your anonymized location data on your behalf. The DAO bundles your data with that of thousands of other DAO members, and as a member, you receive a portion of the generated profits.

One transaction may have fees going to several entities, such as the market where the asset was published, or the Ocean Community. Here are all of them:

• Publish Market: the market where the asset was published.

• Consume Market: the market where the asset was consumed.

• Provider: the entity facilitating asset consumption. May serve up data, run compute, etc.

• Ocean Community: Ocean Community Wallet.

Publish fee

However, if you're building a custom marketplace, you have the flexibility to include a publishing fee by adding an extra transaction in the publish flow. Depending on your marketplace's unique use case, you, as the marketplace owner, can decide whether or not to implement this fee. We believe in giving you the freedom to tailor your marketplace to your specific needs and preferences.

Swap fee

The swap fee values are set at the smart contract level and can only be modified by the Ocean Protocol Foundation (OPF).

Consume(aka. Order) fee

1. Publisher Market Consumption Fee

   • Defined as Address, Token, Amount. The amount is an absolute value(not a percentage).

   • A marketplace can charge a specified amount per order.

   • Eg: A market can set a fixed fee of 10 USDT per order, no matter what pricing schemas are used (fixedrate with ETH, BTC, dispenser, etc).

2. Consume Market Consumption Fee

   • A market can specify what fee it wants on the order function.

3. Provider Consumption Fees

   • Expressed in: Address, Token, Amount (absolute), Timeout.

   • You can retrieve them when calling the initialize endpoint.

   • Eg: A provider can charge a fixed fee of 10 USDT per consume, irrespective of the pricing schema used (e.g., fixed rate with ETH, BTC, dispenser).

4. Ocean Community Fee

   • Ocean's smart contracts collect Ocean Community fees during order operations. These fees are reinvested in community projects and distributed to the veOCEAN holders through Data Farming.

Each of these fees plays a role in ensuring fair compensation and supporting the Ocean community.

Provider fee

• Expressed in: Address, Token, Amount (absolute), Timeout.

• You can retrieve them when calling the initialize endpoint.

• These fees can be set as a fixed amount rather than a percentage.

• Providers have the flexibility to specify the token in which the fees must be paid, which can differ from the token used in the consuming market.

• Eg: A provider can charge a fixed fee of 10 USDT per consume, irrespective of the pricing schema used (e.g., fixed rate with ETH, BTC, dispenser).

• Eg: A provider may impose a fixed fee of 15 DAI to reserve compute resources for 1 hour, enabling the initiation of compute jobs.

These fees play a crucial role in incentivizing individuals and organizations to operate provider instances and charge consumers based on their resource usage. By doing so, they contribute to the growth and sustainability of the Ocean Protocol ecosystem.

Ocean Protocol offers you flexible and customizable pricing options to monetize your valuable data assets. You have two main pricing models to choose from:

These models are designed to cater to your specific needs and ensure a smooth experience for data consumers.

To provide you with even greater flexibility in monetizing your data assets, Ocean Protocol allows you to customize the pricing schema by configuring your own ERC20 token when publishing the asset. This means that instead of using OCEAN as the pricing currency, you can utilize your own token, aligning the pricing structure with your specific requirements and preferences.

You can customised your token this way:

Furthermore, Ocean Protocol recognizes that different data assets may have distinct pricing needs. That's why the platform supports multiple pricing schemas, allowing you to implement various pricing models for different datasets or use cases. This flexibility ensures that you can tailor the pricing strategy to each specific asset, maximizing its value and potential for monetization.

Fixed pricing

With the fixed pricing model, you have the power to set a specific price for your data assets. This means that buyers interested in accessing your data will need to pay the designated amount of configured tokens. To make things even easier, Ocean automatically creates a special token called a "datatoken" behind the scenes.

This datatoken represents the access right to your data, so buyers don't have to worry about the technical details. If you ever want to adjust the price of your dataset, you have the flexibility to do so whenever you need.

Free pricing

On the other hand, the free pricing model gives data consumers access to your asset without requiring them to make a direct payment. Users can freely access your data, with the only cost being the transaction fees associated with the blockchain network.

In this model, datatokens are allocated to a dispenser smart contract, which dispenses data tokens to users at no charge when they access your asset. This is perfect if you want to make your data widely available and encourage collaboration. It's particularly suitable for individuals and organizations working in the public domain or for assets that need to comply with open-access licenses.

Ocean does not handle the actual storage of files directly. The files are stored via other services which are then specified within the DDO.

During the publish process, file URLs must be encrypted with a respective Provider API call before storing the DDO on-chain. For this, you need to send the following object to Provider (where "files" contains one or more storage objects):

{
  "datatokenAddress":"0x1",
  "nftAddress": "0x2",
  "files": [
    ...
  ]
}

The remainder of this document specifies the different types of storage objects that are supported:

Static URLs.

Parameters:

• url - File URL, required

• method - The HTTP method, required

• headers - Additional HTTP headers, optional

{
    "type": "url",
    "url": "https://url.com/file1.csv",
    "method": "GET",
    "headers":
    {
        "Authorization": "Bearer 123",
        "APIKEY": "124",
    }
}

Interplanetary File System

IPFS

The Interplanetary File System (IPFS) is a distributed file storage protocol that allows computers all over the globe to store and serve files as part of a giant peer-to-peer network. Any computer, anywhere in the world, can download the IPFS software and start hosting and serving files.

Parameters:

• hash - The file hash, required

{
    "type": "ipfs",
    "hash": "XXX"
}

GraphQL

GraphQL

GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data.

Parameters:

• url - Server endpoint URL, required

• query - The query to be executed, required

• headers - Additional HTTP headers, optional

{
     "type": "graphql",
     "url": "http://172.15.0.15:8000/subgraphs/name/oceanprotocol/ocean-subgraph",
     "headers":{
        	"Authorization": "Bearer 123",
        	"APIKEY": "124",
     },
     "query": """query{
            nfts(orderBy: createdTimestamp,orderDirection:desc){
                 id
                 symbol
                 createdTimestamp
            }
          }"""
}

Smart Contract Data

Use a smart contract as data source.

Parameters:

• chainId - The chainId used to query the contract, required

• address - The smartcontract address, required

• abi - The function abi (NOT the entire contract abi), required

{
"type": "smartcontract",
"chainId": 1,
"address": "0x8149276f275EEFAc110D74AFE8AFECEaeC7d1593",
"abi": {
	"inputs": [],
	"name": "swapOceanFee",
	"outputs": [{"internalType": "uint256", "name": "", "type": "uint256"}],
	"stateMutability": "view",
	"type": "function"
	}
}

Arweave

Arweave is a decentralized data storage that allows permanently storing files over a distributed network of computers.

Parameters:

• transactionId - The transaction identifier, required

{
    "type": "arweave",
    "transactionId": "a4qJoQZa1poIv5guEzkfgZYSAD0uYm7Vw4zm_tCswVQ",
}

First-class integrations supported in the future : Filecoin Storj SQL

A service can contain multiple files, using multiple storage types.

Example:

{
  "datatokenAddress": "0x1",
  "nftAddress": "0x2",
  "files": [
    {
      "type": "url",
      "url": "https://url.com/file1.csv",
      "method": "GET"
    },
    {
      "type": "ipfs",
      "hash": "XXXX"
    }
  ]
}

To get information about the files after encryption, the /fileinfo endpoint of the Provider returns based on a passed DID an array of file metadata (based on the file type):

[
  {
    "type": "url",
    "contentLength": 100,
    "contentType": "application/json"
  },
  {
    "type": "ipfs",
    "contentLength": 130,
    "contentType": "application/text"
  }
]

This only concerns metadata about a file, but never the file URLs. The only way to decrypt them is to exchange at least 1 datatoken based on the respective service pricing scheme.

A large part of Ocean is about access control, which is primarily handled by datatokens. Users can access a resource (e.g. a file) by redeeming datatokens for that resource. We recognize that enterprises and other users often need more precise ways to specify and manage access, and we have introduced fine-grained permissions for these use cases. Fine-grained permissions mean that access can be controlled precisely at two levels:

• Marketplace-level permissions for browsing, downloading or publishing within a marketplace frontend.

• Asset-level permissions on downloading a specific asset.

The fine-grained permissions features are designed to work in forks of Ocean Market. We have not enabled them in Ocean Market itself, to keep Ocean Market open for everyone to use. On the front end, the permissions features are easily enabled by setting environment variables.

Introduction

Some datasets need to be restricted to appropriately credentialed users. In this situation there is tension:

1. Datatokens on their own aren’t enough - the datatokens can be exchanged without any restrictions, which means anyone can acquire them and access the data.

2. We want to retain datatokens approach, since they enable Ocean users to leverage existing crypto infrastructure e.g. wallets, exchange etc.

We can resolve this tension by drawing on the following analogy:

Imagine going to an age 18+ rock concert. You can only get in if you show both (a) your concert ticket and (b) an id showing that you’re old enough.

We can port this model into Ocean, where (a) is a datatoken, and (b) is a credential. The datatoken is the baseline access control. It’s fungible, and something that you’ve paid for or had shared to you. It’s independent of your identity. The credential is something that’s a function of your identity.

The credential based restrictions are implemented in two ways, at the market level and at the asset level. Access to the market is restricted on a role basis, the user's identity is attached to a role via the role based access control (RBAC) server. Access to individual assets is restricted via allow and deny lists which list the ethereum addresses of the users who can and cannot access the asset within the DDO.

Asset-Level Restrictions

For asset-level restrictions Ocean supports allow and deny lists. Allow and deny lists are advanced features that allow publishers to control access to individual data assets. Publishers can restrict assets so that they can only be accessed by approved users (allow lists) or they can restrict assets so that they can be accessed by anyone except certain users (deny lists).

When an allow-list is in place, a consumer can only access the resource if they have a datatoken and one of the credentials in the "allow" list of the DDO. Ocean also has complementary deny functionality: if a consumer is on the "deny" list, they will not be allowed to access the resource.

Initially, the only credential supported is Ethereum public addresses. To be fair, it’s more a pointer to an individual not a credential; but it has a low-complexity implementation so makes a good starting point. For extensibility, the Ocean metadata schema enables specification of other types of credentials like W3C Verifiable Credentials and more. When this gets implemented, asset-level permissions will be properly RBAC too. Since asset-level permissions are in the DDO, and the DDO is controlled by the publisher, asset-level restrictions are controlled by the publisher.

Market-Level Permissions

For market-level permissions, Ocean implements a role-based access control server (RBAC server). It implements restrictions at the user level, based on the user’s role (credentials). The RBAC server is run & controlled by the marketplace owner. Therefore permissions at this level are at the discretion of the marketplace owner.

The RBAC server is the primary mechanism for restricting your users ability to publish, buy, or browse assets in the market.

Roles

The RBAC server defines four different roles:

• Admin

• Publisher

• Consumer

• User

Admin/ Publisher

Currently users with either the admin or publisher roles will be able to use the Market without any restrictions. They can publish, buy and browse datasets.

Consumer

A user with the consumer is able to browse datasets, purchase them, trade datatokens and also contribute to datapools. However, they are not able to publish datasets.

Users

Users are able to browse and search datasets but they are not able to purchase datasets, trade datatokens, or contribute to data pools. They are also not able to publish datasets.

Address without a role

If a user attempts to view the data market without a role, or without a wallet connected, they will not be able to view or search any of the datasets.

No wallet connected

When the RBAC server is enabled on the market, users are required to have a wallet connected to browse the datasets.

Mapping roles to addresses

Currently the are two ways that the RBAC server can be configured to map user roles to Ethereum addresses. The RBAC server is also built in such a way that it is easy for you to add your own authorization service. They two existing methods are:

1. Keycloak

If you already have a Keycloak identity and access management server running you can configure the RBAC server to use it by adding the URL of your Keycloak server to the KEYCLOAK_URL environmental variable in the RBAC .enb file.

1. JSON

Alternatively, if you are not already using Keycloak, the easiest way to map user roles to ethereum addresses is in a JSON object that is saved as the JSON_DATA environmental variable in the RBAC .env file. There is an example of the format required for this JSON object in .example.env

It is possible that you can configure both of these methods of mapping user roles to Ethereum Addresses. In this case the requests to your RBAC server should specify which auth service they are using e.g. "authService": "json" or "authService": "keycloak"

Default Auth service

Additionally, you can also set an environmental variable within the RBAC server that specifies the default authorization method that will be used e.g. DEFAULT_AUTH_SERVICE = "json". When this variable is specified, requests sent to your RBAC server don't need to include an authService and they will automatically use the default authorization method.

Running the RBAC server locally

You can start running the RBAC server by following these steps:

1. Clone this repository:

git clone https://github.com/oceanprotocol/RBAC-Server.git
cd RBAC-Server

1. Install the dependencies:

npm install

1. Build the service

npm run build

1. Start the server

npm run start

Running the RBAC in Docker

When you are ready to deploy the RBAC server to

1. Replace the KEYCLOAK_URL in the Dockerfile with the correct URL for your hosting of Keycloak.

2. Run the following command to build the RBAC service in a Docker container:

npm run build:docker

1. Next, run the following command to start running the RBAC service in the Docker container:

npm run start:docker

1. Now you are ready to send requests to the RBAC server via postman. Make sure to replace the URL to http://localhost:49160 in your requests.

Identifiers

In Ocean, we use decentralized identifiers (DIDs) to identify your asset within the network. Decentralized identifiers (DIDs) are a type of identifier that enables verifiable, decentralized digital identity. In contrast to typical, centralized identifiers, DIDs have been designed so that they may be decoupled from centralized registries, identity providers, and certificate authorities. Specifically, while other parties might be used to help enable the discovery of information related to a DID, the design enables the controller of a DID to prove control over it without requiring permission from any other party. DIDs are URIs that associate a DID subject with a DID document allowing trustable interactions associated with that subject.

Examples

DIDs in Ocean follow the generic DID scheme, they look like this:

did:op:0ebed8226ada17fde24b6bf2b95d27f8f05fcce09139ff5cec31f6d81a7cd2ea

The part after did:op: is the ERC721 contract address(in checksum format) and the chainId (expressed to 10 decimal places). The following javascript example shows how to calculate the DID for the asset:

Before creating a DID you should first publish a data NFT, we suggest reading the following sections so you are familiar with the process:

• Creating a data NFT with ocean.js

• Publish flow with ocean.py

The intentions with all of the updates are to ensure that your project is able to become self-sufficient and profitable in the long run (if that’s your aim). We love projects that are built on top of Ocean and we want to ensure that you are able to generate enough income to keep your project running well into the future.

1. Publishing & Selling Data

The datasets can take one of many shapes. For AI use cases, they may be raw datasets, cleaned-up datasets, feature-engineered data, AI models, AI model predictions, or otherwise. (They can even be other forms of copyright-style IP such as photos, videos, or music!) Algorithms themselves may be sold as part of Ocean’s Compute-to-Data feature.

The first opportunity of data NFTs is the potential to sell the base intellectual property (IP) as an exclusive license to others. This is akin to EMI selling the Beatles’ master tapes to Universal Music: whoever owns the masters has the right to create records, CDs, and digital sub-licenses. It’s the same for data: as the data NFT owner you have the exclusive right to create ERC20 datatoken sub-licenses. With Ocean, this right is now transferable as a data NFT. You can sell these data NFTs in OpenSea and other NFT marketplaces.

If you’re part of an established organization or a growing startup, you’ll also love the new role structure that comes with data NFTs. For example, you can specify a different address to collect revenue compared to the address that owns the NFT. It’s now possible to fully administer your project through these roles.

In short, if you have data to sell, then Ocean gives you superpowers to scale up and manage your data project. We hope this enables you to bring your data to new audiences and increase your profits.

2. Running Your Own Data dApp

We have always been super encouraging of anyone who wishes to build a dApp on top of Ocean or to fork Ocean Market and make their own data marketplace. And now, we have taken this to the next level and introduced more opportunities and even more fee customization options.

Ocean empowers dApp owners like yourself to have greater flexibility and control over the fees you can charge. This means you can tailor the fee structure to suit your specific needs and ensure the sustainability of your project. The smart contracts enable you to collect a fee not only in consume, but also in fixed-rate exchange, also you can set the fee value. For more detailed information regarding the fees, we invite you to visit the fees page.

Another new opportunity is using your own ERC20 token in your dApp, where it’s used as the unit of exchange. This is fully supported and can be a great way to ensure the sustainability of your project.

3. Running Your Own Provider

Now this is a completely brand new opportunity to start generating revenue — running your own provider. We have been aware for a while now that many of you haven’t taken up the opportunity to run your own provider, and the reason seems obvious — there aren’t strong enough incentives to do so.

For those that aren’t aware, Ocean Provider is the proxy service that’s responsible for encrypting/ decrypting the data and streaming it to the consumer. It also validates if the user is allowed to access a particular data asset or service. It’s a crucial component in Ocean’s architecture.

Now, as mentioned above, fees are now paid to the individual or organization running the provider whenever a user downloads a data asset. The fees for downloading an asset are set as a cost per MB. In addition, there is also a provider fee that is paid whenever a compute job is run, which is set as a price per minute.

The download and compute fees can both be set to any absolute amount and you can also decide which token you want to receive the fees in — they don’t have to be in the same currency used in the consuming market. So for example, the provider fee could be a fixed rate of 5 USDT per 1000 MB of data downloaded, and this fee remains fixed in USDT even if the marketplace is using a completely different currency.

Additionally, provider fees are not limited to data consumption — they can also be used to charge for compute resources. So, for example, this means a provider can charge a fixed fee of 15 DAI to reserve compute resources for 1 hour. This has a huge upside for both the user and the provider host. From the user’s perspective, this means that they can now reserve a suitable amount of compute resources according to what they require. For the host of the provider, this presents another great opportunity to create an income.

Benefits to the Ocean Community We’re always looking to give back to the Ocean community and collecting fees is an important part of that. As mentioned above, the Ocean Protocol Foundation retains the ability to implement community fees on data consumption. The tokens that we receive will either be burned or invested in the community via projects that they are building. These investments will take place either through Data Farming, Ocean Shipyard, or Ocean Ventures.

Projects that utilize OCEAN or H2O are subject to a 0.1% fee. In the case of projects that opt to use different tokens, an additional 0.1% fee will be applied. We want to support marketplaces that use other tokens but we also recognize that they don’t bring the same wider benefit to the Ocean community, so we feel this small additional fee is proportionate.

Each data NFT or datatoken within Ocean Protocol is generated from pre-defined template contracts. The templateId parameter specifies the template used for creating a data NFT or datatoken, which can be set during the creation process. The templateId is stored within the smart contract code and can be accessed using the getId() function.

it("#getId - should return templateId", async () => {
    const templateId = 1;
    assert((await erc20Token.getId()) == templateId);
  });

Currently, Ocean Protocol supports 1 template type for data NFTs and 2 template variants for datatokens: the regular template and the enterprise template. While these templates share the same interfaces, they differ in their underlying implementation and may offer additional features.

The details regarding currently supported datatoken templates are as follows:

Regular template

The regular template allows users to buy/sell/hold datatokens. The datatokens can be minted by the address having a MINTER role, making the supply of datatoken variable. This template is assigned templateId =1 and the source code is available here.

Enterprise template

The enterprise template has additional functions apart from methods in the ERC20 interface. This additional feature allows access to the service by paying in the basetoken instead of the datatoken. Internally, the smart contract handles the conversion of basetoken to datatoken, initiating an order to access the service, and minting/burning the datatoken. The total supply of the datatoken effectively remains 0 in the case of the enterprise template. This template is assigned templateId =2 and the source code is available here.

Set the template

When you're creating an ERC20 datatoken, you can specify the desired template by passing on the template index.

export interface DatatokenCreateParams {
  templateIndex: number
  minter: string
  paymentCollector: string
  mpFeeAddress: string
  feeToken: string
  feeAmount: string
  cap: string
  name?: string
  symbol?: string
}

class DatatokenArguments:
    def __init__(
        self,
        name: Optional[str] = "Datatoken 1",
        symbol: Optional[str] = "DT1",
        template_index: Optional[int] = 1,
        minter: Optional[str] = None,
        fee_manager: Optional[str] = None,
        publish_market_order_fees: Optional = None,
        bytess: Optional[List[bytes]] = None,
        services: Optional[list] = None,
        files: Optional[List[FilesType]] = None,
        consumer_parameters: Optional[List[Dict[str, Any]]] = None,
        cap: Optional[int] = None,
    ):

Retrieve the template

To identify the template used for a specific asset, you can easily retrieve this information using the network explorer. Here are the steps to follow:

1. Visit the network explorer where the asset was published.

3. Once you have located the datatoken address, click on the contract tab to access more details.

4. Within the contract details, we can identify and determine the template used for the asset.

The permissions governing access to the smart contract functions are stored within the data NFT (ERC721) smart contract. Both the data NFT (ERC721) and datatoken (ERC20) smart contracts utilize this information to enforce restrictions on certain actions, limiting access to authorized users. The tables below outline the specific actions that are restricted and can only be accessed by allowed users.

The data NFT serves as the foundational intellectual property (IP) for the asset, and all datatokens are inherently linked to the data NFT smart contract. This linkage has enabled the introduction of various exciting capabilities related to role administration.

NFT Owner

The NFT owner is the owner of the base-IP and is therefore at the highest level. The NFT owner can perform any action or assign any role but crucially, the NFT owner is the only one who can assign the manager role. Upon deployment or transfer of the data NFT, the NFT owner is automatically added as a manager. The NFT owner is also the only role that can’t be assigned to multiple users — the only way to share this role is via multi-sig or a DAO.

Roles-NFT level

There are several methods available to assign roles and permissions. One option is to utilize the ocean.py and ocean.js libraries that we provide. These libraries offer a streamlined approach for assigning roles and permissions programmatically.

Alternatively, for a more straightforward solution that doesn't require coding, you can utilize the network explorer of your asset's network. By accessing the network explorer, you can directly interact with the contracts associated with your asset. Below, we provide a few examples to help guide you through the process.

Manager

The ability to add or remove Managers is exclusive to the NFT Owner. If you are the NFT Owner and wish to add/remove a new manager, simply call the addManager/removeManager function within the ERC721Template contract. This function enables you to grant managerial permissions to the designated individual.

/**
* @dev addManager
*      Only NFT Owner can add a new manager (Roles admin)
*      There can be multiple minters
* @param _managerAddress new manager address
*/

function addManager(address _managerAddress) external onlyNFTOwner {
       _addManager(_managerAddress);
}

/**
* @dev removeManager
*      Only NFT Owner can remove a manager (Roles admin)
*      There can be multiple minters
* @param _managerAddress new manager address
*/
function removeManager(address _managerAddress) external onlyNFTOwner {
        _removeManager(_managerAddress);
}

The manager can assign or revoke three main roles (deployer, metadata updater, and store updater). The manager is also able to call any other contract (ERC725X implementation).

Metadata Updater

There is also a specific role for updating the metadata. The Metadata updater has the ability to update the information about the data asset (title, description, sample data etc) that is displayed to the user on the asset detail page within the market.

To add/remove a metadata updater, the manager can use the addToMetadataList/removeFromMetadataList functions from the ERC721RolesAddress.

/**
* @dev addToMetadataList
*      Adds metadata role to an user.
*      It can be called only by a manager
* @param _allowedAddress user address
*/
function addToMetadataList(address _allowedAddress) public onlyManager {
    _addToMetadataList(_allowedAddress);
}


/**
* @dev removeFromMetadataList
*      Removes metadata role from an user.
*      It can be called by a manager or by the same user, if he already has metadata role
* @param _allowedAddress user address
*/
function removeFromMetadataList(address _allowedAddress) public {
        if(permissions[msg.sender].manager == true ||
        (msg.sender == _allowedAddress && permissions[msg.sender].updateMetadata == true)
        ){
        Roles storage user = permissions[_allowedAddress];
        user.updateMetadata = false;    
        emit RemovedFromMetadataList(_allowedAddress,msg.sender,block.timestamp,block.number);
        _SafeRemoveFromAuth(_allowedAddress);
    }
    else{
        revert("ERC721RolesAddress: Not enough permissions to remove from metadata list");
    }
}

Store Updater

The store updater can store, remove or update any arbitrary key value using the ERC725Y implementation (at the ERC721 level). The use case for this role depends a lot on what data is being stored in the ERC725Y key-value pair — as mentioned above, this is highly flexible.

To add/remove a store updater, the manager can use the addTo725StoreList/removeFrom725StoreList functions from the ERC721RolesAddress.

/**
* @dev addTo725StoreList
*      Adds store role to an user.
*      It can be called only by a manager
* @param _allowedAddress user address
*/
function addTo725StoreList(address _allowedAddress) public onlyManager {
        if(_allowedAddress != address(0)){
            Roles storage user = permissions[_allowedAddress];
            user.store = true;
            _pushToAuth(_allowedAddress);
            emit AddedTo725StoreList(_allowedAddress,msg.sender,block.timestamp,block.number);
        }
}

/**
* @dev removeFrom725StoreList
*      Removes store role from an user.
*      It can be called by a manager or by the same user, if he already has store role
* @param _allowedAddress user address
*/
function removeFrom725StoreList(address _allowedAddress) public {
        if(permissions[msg.sender].manager == true ||
        (msg.sender == _allowedAddress && permissions[msg.sender].store == true)
        ){
            Roles storage user = permissions[_allowedAddress];
            user.store = false;
            emit RemovedFrom725StoreList(_allowedAddress,msg.sender,block.timestamp,block.number);
            _SafeRemoveFromAuth(_allowedAddress);
        }
        else{
            revert("ERC721RolesAddress: Not enough permissions to remove from 725StoreList");
        }
}

ERC20 Deployer

The Deployer has a bunch of privileges at the ERC20 datatoken level. They can deploy new datatokens with fixed price exchange, or free pricing. They can also update the ERC725Y key-value store and assign roles at the ERC20 level(datatoken level).

To add/remove an ERC20 deployer, the manager can use the addToCreateERC20List/removeFromCreateERC20List functions from the ERC721RolesAddress.

/**
* @dev addToCreateERC20List
*      Adds deployERC20 role to an user.
*      It can be called only by a manager
* @param _allowedAddress user address
*/
function addToCreateERC20List(address _allowedAddress) public onlyManager {
    _addToCreateERC20List(_allowedAddress);
}

/**
* @dev removeFromCreateERC20List
*      Removes deployERC20 role from an user.
*      It can be called by a manager or by the same user, if he already has deployERC20 role
* @param _allowedAddress user address
*/
function removeFromCreateERC20List(address _allowedAddress) public {
        if(permissions[msg.sender].manager == true ||
        (msg.sender == _allowedAddress && permissions[msg.sender].deployERC20 == true)
        ){
            Roles storage user = permissions[_allowedAddress];
            user.deployERC20 = false;
            emit RemovedFromCreateERC20List(_allowedAddress,msg.sender,block.timestamp,block.number);
            _SafeRemoveFromAuth(_allowedAddress);
        }
        else{
            revert("ERC721RolesAddress: Not enough permissions to remove from ERC20List");
        }
}

/**
* @dev addMultipleUsersToRoles
*      Add multiple users to multiple roles
* @param addresses Array of addresses
* @param roles Array of coresponding roles
*/
function addMultipleUsersToRoles(address[] memory addresses, RolesType[] memory roles) external onlyManager {
		require(addresses.length == roles.length && roles.length>0 && roles.length<50, "Invalid array size");
         uint256 i;
         for(i=0; i<roles.length; i++){
             if(addresses[i] != address(0)){
		Roles storage user = permissions[addresses[i]];
		if(roles[i] == RolesType.Manager) {
		     user.manager = true;
		     emit AddedManager(addresses[i],msg.sender,block.timestamp,block.number);
		}
		if(roles[i] == RolesType.DeployERC20) {
		     user.deployERC20 = true;
		     emit AddedToCreateERC20List(addresses[i],msg.sender,block.timestamp,block.number);
		}
		if(roles[i] == RolesType.UpdateMetadata) {
		      user.updateMetadata = true;
		      emit AddedToMetadataList(addresses[i],msg.sender,block.timestamp,block.number);
		}
		if(roles[i] == RolesType.Store) {
		      user.store = true;
		      emit AddedTo725StoreList(addresses[i],msg.sender,block.timestamp,block.number);
		}
		_pushToAuth(addresses[i]);
              }
         }
}

Roles & permissions in data NFT (ERC721) smart contract

Roles-datatokens level

Minter

The Minter has the ability to mint new datatokens, provided the limit has not been exceeded.

To add/remove a minter, the ERC20 deployer can use the addMinter/removeMinter functions from the ERC20Template.

/**
* @dev addMinter
*      Only ERC20Deployer (at 721 level) can update.
*      There can be multiple minters
* @param _minter new minter address
*/

function addMinter(address _minter) external onlyERC20Deployer {
        _addMinter(_minter);
}

/**
* @dev removeMinter
*      Only ERC20Deployer (at 721 level) can update.
*      There can be multiple minters
* @param _minter minter address to remove
*/

function removeMinter(address _minter) external onlyERC20Deployer {
        _removeMinter(_minter);
}

Fee Manager

Finally, we also have a fee manager which has the ability to set a new fee collector — this is the account that will receive the datatokens when a data asset is consumed. If no fee collector account has been set, the datatokens will be sent by default to the NFT Owner.

To add/remove a fee manager, the ERC20 deployer can use the addPaymentManager/removePaymentManager functions from the ERC20Template.

/**
* @dev addPaymentManager (can set who's going to collect fee when consuming orders)
*      Only ERC20Deployer (at 721 level) can update.
*      There can be multiple paymentCollectors
* @param _paymentManager new minter address
*/
function addPaymentManager(address _paymentManager) external onlyERC20Deployer
{
        _addPaymentManager(_paymentManager);
}

/**
* @dev removePaymentManager
*      Only ERC20Deployer (at 721 level) can update.
*      There can be multiple paymentManagers
* @param _paymentManager _paymentManager address to remove
*/

function removePaymentManager(address _paymentManager) external onlyERC20Deployer
{
        _removePaymentManager(_paymentManager);
}

function cleanPermissions() external onlyNFTOwner {
    _cleanPermissions();
    //Make sure that owner still has permissions
    _addManager(ownerOf(1));
}   

Roles & permission in datatoken (ERC20) smart contract

Metadata plays a crucial role in asset discovery, providing essential information such as asset type, name, creation date, and licensing details. Each data asset can have a decentralized identifier (DID) that resolves to a DID document (DDO) containing associated metadata. The DDO is essentially a collection of fields in a JSON object. To understand working with OCEAN DIDs, you can refer to the DID documentation. For a more comprehensive understanding of metadata structure, the DDO Specification documentation provides in-depth information.

In general, any dApp within the Ocean ecosystem is required to store metadata for every listed dataset. The metadata is useful to determine which datasets are the most relevant.

• name, e.g. “Largueta Almond Production: 1995 to 2005”

• dateCreated, e.g. “2007–01–20”

• datePublished, e.g. “2022–11–10T12:32:15Z”

• author, e.g. “Spanish Almond Board”

• license, e.g. “SAB Data License”

• technical information about the files, such as the content type.

Other metadata might also be available. For example:

• categories, e.g. [“agriculture”, “economics”]

• tags, e.g. [“Europe”, “Italy”, “nuts”, “almonds”]

• description, e.g. “2002 Italian almond production statistics for 14 varieties and 20 regions.”

• additionalInformation can be used to store any other facts about the asset.