Cleaned many duplicated images. Moved core-concept images into .gitbook/assets
Before Width: | Height: | Size: 57 KiB After Width: | Height: | Size: 57 KiB |
Before Width: | Height: | Size: 63 KiB After Width: | Height: | Size: 63 KiB |
Before Width: | Height: | Size: 236 KiB |
Before Width: | Height: | Size: 31 KiB After Width: | Height: | Size: 31 KiB |
Before Width: | Height: | Size: 44 KiB After Width: | Height: | Size: 44 KiB |
Before Width: | Height: | Size: 39 KiB After Width: | Height: | Size: 39 KiB |
Before Width: | Height: | Size: 221 KiB After Width: | Height: | Size: 221 KiB |
Before Width: | Height: | Size: 152 KiB After Width: | Height: | Size: 152 KiB |
Before Width: | Height: | Size: 65 KiB After Width: | Height: | Size: 65 KiB |
Before Width: | Height: | Size: 76 KiB After Width: | Height: | Size: 76 KiB |
Before Width: | Height: | Size: 97 KiB After Width: | Height: | Size: 97 KiB |
Before Width: | Height: | Size: 86 KiB After Width: | Height: | Size: 86 KiB |
Before Width: | Height: | Size: 331 KiB After Width: | Height: | Size: 331 KiB |
@ -9,16 +9,16 @@ description: Data NFTs and datatokens architecture
|
||||
|
||||
Here is the Ocean architecture.
|
||||
|
||||
![Ocean Protocol tools architecture](<images/architecture (2).png>)
|
||||
![Ocean Protocol tools architecture](../.gitbook/assets/architecture.png)
|
||||
|
||||
Here’s an overview of the figure.
|
||||
|
||||
* The top layer is **applications** like Ocean Market. With these apps, users can onboard services like data, algorithms, compute-to-data into crypto (publish and mint data NFTs and datatokens), hold datatokens as assets (data wallets), discover assets, and buy/sell datatokens for a fixed or auto-determined price (data marketplaces), and use data services (spend datatokens).
|
||||
* Below are **libraries** used by the applications: Ocean.js (JavaScript library) and Ocean.py (Python library). This also includes middleware to assist discovery:
|
||||
* **Aquarius**: Provides metadata cache for faster search by caching on-chain data into elasticsearch
|
||||
* **Provider**: Facilitates downloading assets, DDO encryption, and communicating with `operator-service` for Compute-to-Data jobs.
|
||||
* **The Graph**: It is a 3rd party tool that developers can utilize the libraries to build their custom applications and marketplaces.
|
||||
* The lowest level has the **smart contracts**. The smart contracts are deployed on the Ethereum mainnet and other compatible networks. Libraries encapsulate the calls to these smart contracts and provide features like publishing new assets, facilitating consumption, managing pricing, and much more. To see the supported networks click [here](networks.md).
|
||||
- The top layer is **applications** like Ocean Market. With these apps, users can onboard services like data, algorithms, compute-to-data into crypto (publish and mint data NFTs and datatokens), hold datatokens as assets (data wallets), discover assets, and buy/sell datatokens for a fixed or auto-determined price (data marketplaces), and use data services (spend datatokens).
|
||||
- Below are **libraries** used by the applications: Ocean.js (JavaScript library) and Ocean.py (Python library). This also includes middleware to assist discovery:
|
||||
- **Aquarius**: Provides metadata cache for faster search by caching on-chain data into elasticsearch
|
||||
- **Provider**: Facilitates downloading assets, DDO encryption, and communicating with `operator-service` for Compute-to-Data jobs.
|
||||
- **The Graph**: It is a 3rd party tool that developers can utilize the libraries to build their custom applications and marketplaces.
|
||||
- The lowest level has the **smart contracts**. The smart contracts are deployed on the Ethereum mainnet and other compatible networks. Libraries encapsulate the calls to these smart contracts and provide features like publishing new assets, facilitating consumption, managing pricing, and much more. To see the supported networks click [here](networks.md).
|
||||
|
||||
### Data NFTs, Datatokens and Access Control Tools
|
||||
|
||||
|
@ -17,7 +17,7 @@ A [FixedRateExchange](https://github.com/oceanprotocol/contracts/blob/v4main/con
|
||||
|
||||
The image below shows how to set the fixed pricing of an asset in the Ocean's Marketplace. Here, the price of the asset is set to 10 Ocean tokens.
|
||||
|
||||
![fixed-asset-pricing](<images/fixed-asset-pricing (3).png>)
|
||||
![Fixed asset pricing](../.gitbook/assets/market/fixed-asset-pricing.png)
|
||||
|
||||
### Free pricing
|
||||
|
||||
@ -29,4 +29,4 @@ Free pricing is suitable for individuals and organizations working in the public
|
||||
|
||||
The image below shows how to set free access to an asset in the Ocean's Marketplace.
|
||||
|
||||
![free-asset-pricing](<images/free-asset-pricing (3).png>)
|
||||
![Free asset pricing](../.gitbook/assets/market/free-asset-pricing.png)
|
||||
|
@ -29,16 +29,16 @@ With data NFTs, you are able to take advantage of the wider NFT ecosystem and al
|
||||
|
||||
The image above describes how ERC721 data NFTs and ERC20 datatokens relate.
|
||||
|
||||
* Bottom: The publisher deploys an ERC721 data NFT contract representing the base IP for the data asset. They are now the manager of the data NFT.
|
||||
* Top: The manager then deploys an ERC20 datatoken contract against the data NFT. The ERC20 represents a license with specific terms like "can download for the next 3 days". They could even publish further ERC20 datatoken contracts, to represent different license terms or for compute-to-data.
|
||||
- Bottom: The publisher deploys an ERC721 data NFT contract representing the base IP for the data asset. They are now the manager of the data NFT.
|
||||
- Top: The manager then deploys an ERC20 datatoken contract against the data NFT. The ERC20 represents a license with specific terms like "can download for the next 3 days". They could even publish further ERC20 datatoken contracts, to represent different license terms or for compute-to-data.
|
||||
|
||||
### Terminology
|
||||
|
||||
* **Base IP** means the artifact being copyrighted. Represented by the {ERC721 address, tokenId} from the publish transactions.
|
||||
* **Base IP holder** means the holder of the Base IP. Represented as the actor that did the initial "publish" action.
|
||||
* **Sub-licensee** is the holder of the sub-license. Represented as the entity that controls address ERC721.\_owners\[tokenId=x].
|
||||
* **To Publish**: Claim copyright or exclusive base license.
|
||||
* **To Sub-license**: Transfer one (of many) sub-licenses to new licensee: ERC20.transfer(to=licensee, value=1.0).
|
||||
- **Base IP** means the artifact being copyrighted. Represented by the {ERC721 address, tokenId} from the publish transactions.
|
||||
- **Base IP holder** means the holder of the Base IP. Represented as the actor that did the initial "publish" action.
|
||||
- **Sub-licensee** is the holder of the sub-license. Represented as the entity that controls address ERC721.\_owners\[tokenId=x].
|
||||
- **To Publish**: Claim copyright or exclusive base license.
|
||||
- **To Sub-license**: Transfer one (of many) sub-licenses to new licensee: ERC20.transfer(to=licensee, value=1.0).
|
||||
|
||||
### Implementation in Ocean Protocol
|
||||
|
||||
@ -66,8 +66,8 @@ Ocean provides convenient methods to list ERC20 datatokens for sale, with fixed-
|
||||
|
||||
Here's an 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).
|
||||
* In step 2, she **mints** some ERC20 datatokens and **transfers** 1.0 of them to Bob's wallet; now he has a license to be able to download that dataset.
|
||||
- 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).
|
||||
- In step 2, she **mints** some ERC20 datatokens and **transfers** 1.0 of them to Bob's wallet; now he has a license to be able to download that dataset.
|
||||
|
||||
### Revenue
|
||||
|
||||
@ -77,7 +77,7 @@ In some situations, you may want the revenue to be sent to another account rathe
|
||||
|
||||
In order to set a new payment collector, you need to visit the asset detail page and then click on “Edit Asset” and then scroll down to the field call “Payment Collector Address”. Add the new Ethereum address in this field and then click “Submit“. Finally, you will then need to sign two transactions to finalize the update.
|
||||
|
||||
![Update Payment Collector](<images/change-payment-collector.png>)
|
||||
![Update Payment Collector](../.gitbook/assets/market/change-payment-collector.png)
|
||||
|
||||
### TemplateIds
|
||||
|
||||
@ -87,8 +87,8 @@ The only data NFT template currently available has templateId `1` and the source
|
||||
|
||||
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](https://github.com/oceanprotocol/contracts/blob/v4main/contracts/templates/ERC20Template.sol).
|
||||
* **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 datatoken. Internally, the smart contract handles 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](https://github.com/oceanprotocol/contracts/blob/v4main/contracts/templates/ERC20TemplateEnterprise.sol).
|
||||
- **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](https://github.com/oceanprotocol/contracts/blob/v4main/contracts/templates/ERC20Template.sol).
|
||||
- **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 datatoken. Internally, the smart contract handles 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](https://github.com/oceanprotocol/contracts/blob/v4main/contracts/templates/ERC20TemplateEnterprise.sol).
|
||||
|
||||
_NOTE: Ocean Protocol might support additional variations of data NFT/datatoken by adding new templates._
|
||||
|
||||
@ -98,8 +98,8 @@ Fractional ownership is an exciting sub-niche of Web3, at the intersection of NF
|
||||
|
||||
Ocean provides two approaches to fractional ownership:
|
||||
|
||||
* Sharded holding of ERC20 datatokens, where each ERC20 holder has the usual datatoken rights as described above, e.g. 1.0 datatokens to consume an asset. This comes out-of-the-box with Ocean.
|
||||
* Sharding ERC721 data NFT, where each co-holder has right to some earnings against base IP, and co-controls the data NFT. For example, there’s a DAO with the sole purpose to hold the data NFT; this DAO has its own ERC20 token; DAO members vote with tokens to update data NFT roles or deploy ERC20 datatokens against the ERC721.
|
||||
- Sharded holding of ERC20 datatokens, where each ERC20 holder has the usual datatoken rights as described above, e.g. 1.0 datatokens to consume an asset. This comes out-of-the-box with Ocean.
|
||||
- Sharding ERC721 data NFT, where each co-holder has right to some earnings against base IP, and co-controls the data NFT. For example, there’s a DAO with the sole purpose to hold the data NFT; this DAO has its own ERC20 token; DAO members vote with tokens to update data NFT roles or deploy ERC20 datatokens against the ERC721.
|
||||
|
||||
Note: For (2), one might consider doing sharding with something like Niftex. But then there are questions: what rights do the shard-holders get exactly? It could be zero; for example, Amazon shareholders don’t have the right to walk the hallways of the Amazon offices just because they hold shares. Secondly, how do the shard-holders control the data NFT? These questions get resolved by using a tokenized DAO, as described above.
|
||||
|
||||
@ -111,7 +111,7 @@ This has several variants. Each member’s data feed could be its own data NFT w
|
||||
|
||||
### Other References
|
||||
|
||||
* [Data & NFTs 1: Practical Connections of ERC721 with Intellectual Property](https://blog.oceanprotocol.com/nfts-ip-1-practical-connections-of-erc721-with-intellectual-property-dc216aaf005d)
|
||||
* [Data & NFTs 2: Leveraging ERC20 Fungibility](https://blog.oceanprotocol.com/nfts-ip-2-leveraging-erc20-fungibility-bcee162290e3)
|
||||
* [Data & NFTs 3: Combining ERC721 & ERC20](https://blog.oceanprotocol.com/nfts-ip-3-combining-erc721-erc20-b69ea659115e)
|
||||
* [Fungibility sightings in NFTs](https://blog.oceanprotocol.com/on-difficult-to-explain-fungibility-sightings-in-nfts-26bc18620f70)
|
||||
- [Data & NFTs 1: Practical Connections of ERC721 with Intellectual Property](https://blog.oceanprotocol.com/nfts-ip-1-practical-connections-of-erc721-with-intellectual-property-dc216aaf005d)
|
||||
- [Data & NFTs 2: Leveraging ERC20 Fungibility](https://blog.oceanprotocol.com/nfts-ip-2-leveraging-erc20-fungibility-bcee162290e3)
|
||||
- [Data & NFTs 3: Combining ERC721 & ERC20](https://blog.oceanprotocol.com/nfts-ip-3-combining-erc721-erc20-b69ea659115e)
|
||||
- [Fungibility sightings in NFTs](https://blog.oceanprotocol.com/on-difficult-to-explain-fungibility-sightings-in-nfts-26bc18620f70)
|
||||
|
@ -33,7 +33,7 @@ The DDO is stored on-chain as part of the NFT contract and stored in encrypted f
|
||||
|
||||
Here is the flow:
|
||||
|
||||
![DDO flow](images/ddo-flow.png)
|
||||
![DDO flow](../.gitbook/assets/architecture/ddo-flow.png)
|
||||
|
||||
<details>
|
||||
|
||||
@ -128,6 +128,7 @@ Example:
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### Algorithm Metadata
|
||||
|
||||
An asset of type `algorithm` has additional attributes under `metadata.algorithm`, describing the algorithm and the Docker environment it is supposed to be run under.
|
||||
@ -223,12 +224,13 @@ where "files" contains one or more storage objects.
|
||||
|
||||
**`URL`**
|
||||
|
||||
Static URLs.
|
||||
Static URLs.
|
||||
|
||||
Parameters:
|
||||
* `url` - File url, required
|
||||
* `method` - The HTTP method, required
|
||||
* `headers` - Additional HTTP headers, optional
|
||||
Parameters:
|
||||
|
||||
- `url` - File url, required
|
||||
- `method` - The HTTP method, required
|
||||
- `headers` - Additional HTTP headers, optional
|
||||
|
||||
```
|
||||
{
|
||||
@ -237,7 +239,7 @@ Parameters:
|
||||
"method": "GET",
|
||||
"headers":
|
||||
{
|
||||
"Authorization": "Bearer 123",
|
||||
"Authorization": "Bearer 123",
|
||||
"APIKEY": "124",
|
||||
}
|
||||
}
|
||||
@ -248,7 +250,8 @@ Parameters:
|
||||
The [Interplanetary File System](https://ipfs.tech/) (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
|
||||
|
||||
- `hash` - The file hash
|
||||
|
||||
```
|
||||
{
|
||||
@ -259,19 +262,20 @@ Parameters:
|
||||
|
||||
**`GraphQL`**
|
||||
|
||||
[GraphQL](https://graphql.org/) is a query language for APIs and a runtime for fulfilling those queries with your existing data.
|
||||
[GraphQL](https://graphql.org/) 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
|
||||
|
||||
- `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",
|
||||
"Authorization": "Bearer 123",
|
||||
"APIKEY": "124",
|
||||
},
|
||||
"query": """query{
|
||||
@ -288,11 +292,11 @@ Parameters:
|
||||
|
||||
Use a smart contract as data source.
|
||||
|
||||
Parameters:
|
||||
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
|
||||
- `chainId` - The chainId used to query the contract, required
|
||||
- `address` - The smartcontract address, required
|
||||
- `abi` - The function abi (NOT the entire contract abi), required
|
||||
|
||||
```
|
||||
{
|
||||
@ -309,12 +313,13 @@ Parameters:
|
||||
}
|
||||
```
|
||||
|
||||
**`Arweave`**
|
||||
**`Arweave`**
|
||||
|
||||
[Arweave](https://www.arweave.org/) is a decentralized data storage that allows to permanently store files over a distributed network of computers.
|
||||
|
||||
Parameters:
|
||||
* `transactionId` - The transaction identifier
|
||||
|
||||
- `transactionId` - The transaction identifier
|
||||
|
||||
```
|
||||
{
|
||||
@ -325,7 +330,6 @@ Parameters:
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
First class integrations supported in the future :
|
||||
**`Filecoin`**
|
||||
**`Storj`**
|
||||
@ -337,7 +341,7 @@ Example:
|
||||
|
||||
```json
|
||||
{
|
||||
"datatokenAddress":"0x1",
|
||||
"datatokenAddress": "0x1",
|
||||
"nftAddress": "0x2",
|
||||
"files": [
|
||||
{
|
||||
@ -376,29 +380,27 @@ This only concerns metadata about a file, but never the file URLs. The only way
|
||||
|
||||
An asset with a service of `type` `compute` has the following additional attributes under the `compute` object. This object is required if the asset is of `type` `compute`, but can be omitted for `type` of `access`.
|
||||
|
||||
|
||||
| Attribute | Type | Required | Description |
|
||||
| ------------------------------- | ----- | ----- | ----------------------------------------------------------- |
|
||||
| `allowRawAlgorithm` | `boolean` | **✓** | If `true`, any passed raw text will be allowed to run. Useful for an algorithm drag & drop use case, but increases risk of data escape through malicious user input. Should be `false` by default in all implementations. |
|
||||
| `allowNetworkAccess` | `boolean` | **✓** | If `true`, the algorithm job will have network access. |
|
||||
| `publisherTrustedAlgorithmPublishers` | Array of `string` | **✓** | If not defined, then any published algorithm is allowed. If empty array, then no algorithm is allowed. If not empty any algo published by the defined publishers is allowed. |
|
||||
| `publisherTrustedAlgorithms` | Array of `publisherTrustedAlgorithms` | **✓** | If not defined, then any published algorithm is allowed. If empty array, then no algorithm is allowed. Otherwise only the algorithms defined in the array are allowed. (see below). |
|
||||
|
||||
| Attribute | Type | Required | Description |
|
||||
| ------------------------------------- | ------------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `allowRawAlgorithm` | `boolean` | **✓** | If `true`, any passed raw text will be allowed to run. Useful for an algorithm drag & drop use case, but increases risk of data escape through malicious user input. Should be `false` by default in all implementations. |
|
||||
| `allowNetworkAccess` | `boolean` | **✓** | If `true`, the algorithm job will have network access. |
|
||||
| `publisherTrustedAlgorithmPublishers` | Array of `string` | **✓** | If not defined, then any published algorithm is allowed. If empty array, then no algorithm is allowed. If not empty any algo published by the defined publishers is allowed. |
|
||||
| `publisherTrustedAlgorithms` | Array of `publisherTrustedAlgorithms` | **✓** | If not defined, then any published algorithm is allowed. If empty array, then no algorithm is allowed. Otherwise only the algorithms defined in the array are allowed. (see below). |
|
||||
|
||||
The `publisherTrustedAlgorithms` is an array of objects with the following structure:
|
||||
|
||||
| Attribute | Type | Required | Description |
|
||||
| ------------------------------ | -------- | ---- | -------------------------------------------------------------- |
|
||||
| **`did`** | `string` | **✓** | The DID of the algorithm which is trusted by the publisher. |
|
||||
| **`filesChecksum`** | `string` | **✓** | Hash of algorithm's files (as `string`). |
|
||||
| **`containerSectionChecksum`** | `string` | **✓** | Hash of algorithm's image details (as `string`). |
|
||||
| ------------------------------ | -------- | -------- | ----------------------------------------------------------- |
|
||||
| **`did`** | `string` | **✓** | The DID of the algorithm which is trusted by the publisher. |
|
||||
| **`filesChecksum`** | `string` | **✓** | Hash of algorithm's files (as `string`). |
|
||||
| **`containerSectionChecksum`** | `string` | **✓** | Hash of algorithm's image details (as `string`). |
|
||||
|
||||
To produce `filesChecksum`, call the Provider FileInfoEndpoint with parameter withChecksum = True. If algorithm has multiple files, `filesChecksum` is a concatenated string of all files checksums (ie: checksumFile1+checksumFile2 , etc)
|
||||
|
||||
To produce `containerSectionChecksum`:
|
||||
|
||||
```js
|
||||
sha256(algorithm_ddo.metadata.algorithm.container.entrypoint + algorithm_ddo.metadata.algorithm.container.checksum)
|
||||
sha256(algorithm_ddo.metadata.algorithm.container.entrypoint + algorithm_ddo.metadata.algorithm.container.checksum);
|
||||
```
|
||||
|
||||
Example:
|
||||
@ -451,13 +453,13 @@ Example:
|
||||
|
||||
Sometimes, the asset needs additional input data before downloading or running a Compute-to-Data job. Examples:
|
||||
|
||||
* The publisher needs to know the sampling interval before the buyer downloads it. Suppose the dataset URL is `https://example.com/mydata`. The publisher defines a field called `sampling` and asks the buyer to enter a value. This parameter is then added to the URL of the published dataset as query parameters: `https://example.com/mydata?sampling=10`.
|
||||
* An algorithm that needs to know the number of iterations it should perform. In this case, the algorithm publisher defines a field called `iterations`. The buyer needs to enter a value for the `iterations` parameter. Later, this value is stored in a specific location in the Compute-to-Data pod for the algorithm to read and use it.
|
||||
- The publisher needs to know the sampling interval before the buyer downloads it. Suppose the dataset URL is `https://example.com/mydata`. The publisher defines a field called `sampling` and asks the buyer to enter a value. This parameter is then added to the URL of the published dataset as query parameters: `https://example.com/mydata?sampling=10`.
|
||||
- An algorithm that needs to know the number of iterations it should perform. In this case, the algorithm publisher defines a field called `iterations`. The buyer needs to enter a value for the `iterations` parameter. Later, this value is stored in a specific location in the Compute-to-Data pod for the algorithm to read and use it.
|
||||
|
||||
The `consumerParameters` is an array of objects. Each object defines a field and has the following structure:
|
||||
|
||||
| Attribute | Type | Required | Description |
|
||||
| ----------------- | -------------------------------- | ---- | -------------------------------------------------------------------------- |
|
||||
| ----------------- | -------------------------------- | -------- | -------------------------------------------------------------------------- |
|
||||
| **`name`** | `string` | **✓** | The parameter name (this is sent as HTTP param or key towards algo) |
|
||||
| **`type`** | `string` | **✓** | The field type (text, number, boolean, select) |
|
||||
| **`label`** | `string` | **✓** | The field label which is displayed |
|
||||
@ -481,23 +483,23 @@ Example:
|
||||
"default": "Nowhere"
|
||||
},
|
||||
{
|
||||
"name":"age",
|
||||
"name": "age",
|
||||
"type": "number",
|
||||
"label": "Age",
|
||||
"required": false,
|
||||
"description":"Please fill your age",
|
||||
"description": "Please fill your age",
|
||||
"default": 0
|
||||
},
|
||||
{
|
||||
"name":"developer",
|
||||
"name": "developer",
|
||||
"type": "boolean",
|
||||
"label": "Developer",
|
||||
"required": false,
|
||||
"description":"Are you a developer?",
|
||||
"description": "Are you a developer?",
|
||||
"default": false
|
||||
},
|
||||
{
|
||||
"name":"languagePreference",
|
||||
"name": "languagePreference",
|
||||
"type": "select",
|
||||
"label": "Language",
|
||||
"required": false,
|
||||
@ -505,10 +507,10 @@ Example:
|
||||
"default": "nodejs",
|
||||
"options": [
|
||||
{
|
||||
"nodejs" : "I love NodeJs"
|
||||
"nodejs": "I love NodeJs"
|
||||
},
|
||||
{
|
||||
"python" : "I love Python"
|
||||
"python": "I love Python"
|
||||
}
|
||||
]
|
||||
}
|
||||
@ -564,7 +566,7 @@ Here's an example object with both `"allow"` and `"deny"` entries:
|
||||
In order to ensure the integrity of the DDO, a checksum is computed for each DDO:
|
||||
|
||||
```js
|
||||
const checksum = sha256(JSON.stringify(ddo))
|
||||
const checksum = sha256(JSON.stringify(ddo));
|
||||
```
|
||||
|
||||
The checksum hash is used when publishing/updating metadata using the `setMetaData` function in the ERC721 contract, and is stored in the event generated by the ERC721 contract:
|
||||
@ -599,14 +601,14 @@ _Aquarius_ should always verify the checksum after data is decrypted via a _Prov
|
||||
|
||||
Each asset has a state, which is held by the NFT contract. The possible states are:
|
||||
|
||||
| State | Description | Discoverable in Ocean Market | Ordering allowed | Listed under profile |
|
||||
| ----- | ----------- | ------------------ | ---------------- | ---- |
|
||||
| **`0`** | Active | Yes | Yes | Yes |
|
||||
| **`1`** | End-of-life | No | No | No |
|
||||
| **`2`** | Deprecated (by another asset) | No | No | No |
|
||||
| **`3`** | Revoked by publisher | No | No | No |
|
||||
| **`4`** | Ordering is temporary disabled | Yes | No | Yes |
|
||||
| **`5`** | Asset unlisted.| No | Yes | Yes |
|
||||
| State | Description | Discoverable in Ocean Market | Ordering allowed | Listed under profile |
|
||||
| ------- | ------------------------------ | ---------------------------- | ---------------- | -------------------- |
|
||||
| **`0`** | Active | Yes | Yes | Yes |
|
||||
| **`1`** | End-of-life | No | No | No |
|
||||
| **`2`** | Deprecated (by another asset) | No | No | No |
|
||||
| **`3`** | Revoked by publisher | No | No | No |
|
||||
| **`4`** | Ordering is temporary disabled | Yes | No | Yes |
|
||||
| **`5`** | Asset unlisted. | No | Yes | Yes |
|
||||
|
||||
### Aquarius Enhanced DDO Response
|
||||
|
||||
|
Before Width: | Height: | Size: 62 KiB |
Before Width: | Height: | Size: 62 KiB |
Before Width: | Height: | Size: 62 KiB |
Before Width: | Height: | Size: 62 KiB |
Before Width: | Height: | Size: 83 KiB |
Before Width: | Height: | Size: 44 KiB |
Before Width: | Height: | Size: 44 KiB |
Before Width: | Height: | Size: 57 KiB |
Before Width: | Height: | Size: 57 KiB |
Before Width: | Height: | Size: 83 KiB |
Before Width: | Height: | Size: 83 KiB |
Before Width: | Height: | Size: 44 KiB |
Before Width: | Height: | Size: 44 KiB |
Before Width: | Height: | Size: 44 KiB |
Before Width: | Height: | Size: 44 KiB |
Before Width: | Height: | Size: 39 KiB |
Before Width: | Height: | Size: 39 KiB |
Before Width: | Height: | Size: 39 KiB |
Before Width: | Height: | Size: 39 KiB |
Before Width: | Height: | Size: 203 KiB |
Before Width: | Height: | Size: 63 KiB |
Before Width: | Height: | Size: 63 KiB |
Before Width: | Height: | Size: 63 KiB |
Before Width: | Height: | Size: 63 KiB |
Before Width: | Height: | Size: 221 KiB |
Before Width: | Height: | Size: 221 KiB |
Before Width: | Height: | Size: 152 KiB |
Before Width: | Height: | Size: 152 KiB |
Before Width: | Height: | Size: 65 KiB |
Before Width: | Height: | Size: 65 KiB |
Before Width: | Height: | Size: 76 KiB |
Before Width: | Height: | Size: 76 KiB |
Before Width: | Height: | Size: 97 KiB |
Before Width: | Height: | Size: 97 KiB |
Before Width: | Height: | Size: 86 KiB |
Before Width: | Height: | Size: 86 KiB |
Before Width: | Height: | Size: 331 KiB |
Before Width: | Height: | Size: 331 KiB |
@ -10,29 +10,29 @@ description: Tutorial about how to set up MetaMask for Chrome.
|
||||
|
||||
1. Go to the [Chrome Web Store for extensions](https://chrome.google.com/webstore/category/extensions) and search for MetaMask.
|
||||
|
||||
![metamask-chrome-store](<images/metamask-chrome-extension (1).png>)
|
||||
![metamask-chrome-store](../.gitbook/assets/wallet/metamask-chrome-extension.png)
|
||||
|
||||
* 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`:
|
||||
- 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`:
|
||||
|
||||
![Create a wallet](<images/create-new-metamask-wallet (1).png>)
|
||||
![Create a wallet](../.gitbook/assets/wallet/create-new-metamask-wallet.png)
|
||||
|
||||
* 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.
|
||||
- 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.
|
||||
|
||||
![Secret Backup Phrase](<images/secret-backup-phrase (1).png>)
|
||||
![Secret Backup Phrase](../.gitbook/assets/wallet/secret-backup-phrase.png)
|
||||
|
||||
* Continue forward. On the next page, MetaMask will ask you to confirm the backup phrase. Select the words in the correct sequence:
|
||||
- Continue forward. On the next page, MetaMask will ask you to confirm the backup phrase. Select the words in the correct sequence:
|
||||
|
||||
![Confirm secret backup phrase](<images/confirm-backup-phrase (1).png>)
|
||||
![Confirm secret backup phrase](../.gitbook/assets/wallet/confirm-backup-phrase.png)
|
||||
|
||||
* Voila! Your account is now created. You can access MetaMask via the browser extension in the top right corner of your browser.
|
||||
- Voila! Your account is now created. You can access MetaMask via the browser extension in the top right corner of your browser.
|
||||
|
||||
![MetaMask browser extension](<images/metamask-browser-extension (1).png>)
|
||||
![MetaMask browser extension](../.gitbook/assets/wallet/metamask-browser-extension.png)
|
||||
|
||||
* You can now manage Ether and Ocean Tokens with your wallet. You can copy your account address to the clipboard from the options. When you want someone to send Ether or Ocean Tokens to you, you will have to give them that address. It's not a secret.
|
||||
- You can now manage Ether and Ocean Tokens with your wallet. You can copy your account address to the clipboard from the options. When you want someone to send Ether or Ocean Tokens to you, you will have to give them that address. It's not a secret.
|
||||
|
||||
![Manage tokens](<images/manage-tokens (1).png>)
|
||||
![Manage tokens](../.gitbook/assets/wallet/manage-tokens.png)
|
||||
|
||||
You can also watch our [tutorial video snippets](https://www.youtube.com/playlist?list=PL\_dn0wVs9kWolBCbtHaFxsi408cumOeth) if you want more help setting up MetaMask.
|
||||
You can also watch our [tutorial video snippets](https://www.youtube.com/playlist?list=PL_dn0wVs9kWolBCbtHaFxsi408cumOeth) if you want more help setting up MetaMask.
|
||||
|
||||
### Set Up Custom Network
|
||||
|
||||
@ -40,14 +40,14 @@ Sometimes it is required to use custom or external networks in MetaMask. We can
|
||||
|
||||
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.
|
||||
|
||||
![Add custom/external network](<images/metamask-add-network (1).png>)
|
||||
![Add custom/external network](../.gitbook/assets/wallet/metamask-add-network.png)
|
||||
|
||||
There are a few empty inputs we need to fill:
|
||||
|
||||
* **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
|
||||
- **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.
|
||||
|
@ -10,7 +10,7 @@ In previous versions of Ocean liquidity pools and dynamic pricing were supported
|
||||
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_.
|
||||
|
||||
![](<../.gitbook/assets/liquidity/remove-liquidity-1 (1).png>)
|
||||
![](../.gitbook/assets/liquidity/remove-liquidity-1.png)
|
||||
|
||||
4\. Go to field `20. balanceOf` and insert your ETH address. This will retrieve your pool share token balance in wei.
|
||||
|
||||
|