# Overall Scheme DDXF facilitates data resource exchange while ensuring data privacy protection and traceability. Its characteristics are as follows: * Data interoperability * Across off chain systems * On-chain features and techniques ## Resource Exchange Process The process that takes place on the marketplace through which resources are exchanged between the provider and the consumer as follows: #### 1. Resource Preparation * Resource digitization (secure storage) * Data resource attribute extraction #### 2. Resource Issue (Marketplace) * Resource verification * Resource exchange metadata assignment * Transaction contract confirmation * Contract safety bond payment #### 3. Transaction * Requirements confirmation, resource processing workflow * Resource integration, transaction generation * User delegation and data characteristic mapping * Contract order generation * Transaction execution * Smart contract driven data processing and resource exchange * Instant dispute settlement and arbitration ## Resource Preparation The provider generates an ONT ID and a DDO on the blockchain for the resource that is to be published. This serves as an on-chain mapping entity for the resource. The **RP** can invite a **RA** with certain credentials to authenticate the resources before release, so as to improve the credibility of the resources on the market. Generally speaking, highly trusted resources will have more potential buyers and may command higher fees, and will be more easily retrieved in the marketplace. Resource authentication can be done by the **RA** by issuing verifiable credentials to related resources, or by uploading the physical certificate of the resources onto the chain via **ONT Sourcing**. The **MP** will provide some corresponding meta-information templates for specific resources, so that the **RP** can easily extract meta-information when publishing data. For example, a medical data marketplace will provide medical data metadata templates. When the **RP** prepares to conduct data transactions in an **MP**, it generates the corresponding meta-information for the resources to be released according to the **MP**'s meta-information template for the retrieval and selection of the **RC**. When making the format of the meta-information template, the **MP** should meet certain specifications and provide necessary information accordingly. The **MP** determines the pricing system based on the characteristics of the resources. The **RP** determines and submits its pricing method in a way approved by the **MP**. Common pricing methods include fixed pricing, dynamic pricing, and auctions. Once again, it should be emphasized that resource transactions are essentially the transfer of resource-related rights. ### 1. Data Value Confirmation After the **RP** provides the resources, the resource authentication API provided by the marketplace or the platform-defined data is stored in the **RA**. The **RA** can use trust anchor to perform resource authentication for the relevant data, or directly store the entity certificate through ONT Sourcing certification. After the resource authentication is successful, the **RP** can proceed with data tokenization. Please refer to the link below for details on resource auditing. {% content-ref url="solutions/resource-auditor" %} [resource-auditor](https://docs.ont.io/decentralized-identity-and-data/ddxf/solutions/resource-auditor) {% endcontent-ref %} ### 2. Data Tokenization After the **RP** applies for the value confirmation or verification of the resource, the marketplace can be used to tokenize the resource (the tokenization). The data transfer carried out by the marketplace denotes the circulation of the tokens. Please refer to the Resource Publication section below for more details on how the tokens are generated. ### 3. Data Privileges Based on the **DToken** contract, when tokenizing data, you need to pass the **RPs** account, the `dataid` of the resource, the ONTID of the controller, etc., to bind people, property, events, and things. The incoming controller has control of the data privileges, the essence of resource transactions is the conversion of Token permissions. After **RC** purchases a Token, you can use it to view the specific details of the data. {% content-ref url="../../developer-tools/api/dtoken-contract-api" %} [dtoken-contract-api](https://docs.ont.io/developer-tools/api/dtoken-contract-api) {% endcontent-ref %} ### 4. Data Evaluation After the resource passes the **RA** certification, the resource is tokenized. After ensuring that the resource meets the standards of the third-party certification authority, the frequency of the data circulation can be judged to further evaluate its value. You can refer to the openbase credibility system to formulate a series of value systems for tokens by offering incentives for upholding contracts. ## Resource Publishing The **RP** publishes resources to an **MP** and waits for the **RC** to purchase. The published content includes the resource's ONT ID, associated ONT ID Document information, meta-information, rights to be transferred, pricing strategy, and authentication information (if the resource has any) of the resource from one or more third-party authentication centers. The **MP** stores the resource metadata and other information into a local database and optimizes information retrieval. The **MP** will also display related historical transaction information, authentication information, and other information from the chain. The reviews of users and resources in previous transactions will be converted into equivalent scores under a certain distributed reputation system. The scores will affect the rankings of users or resources on the marketplace and the success rate of transactions. There could be several different **MP**s, such as the medical data marketplace and antique auction marketplace. Each marketplace accepts and exhibits different types of resources based on its own market characteristics, and the same resource can also be published on different marketplaces. ### Data Token Transactions #### **E-Shop Mode** The initial holder of the DToken is the **RP**, and the DToken can then be transferred (via transactions) to others. The **RP** can set a limit on the number of transfers allowed for the DToken. The number of transfers decreases with each transfer. If the number of transfers is 0, it means that the DToken can no longer be transferred. Certain basic data fields and information needs to be provided in order to carry out token generation before publishing a resource, such as the token volume, resource ownership period time limit, marketplace SDK methods available to invoke the DToken contract and the marketplace purchasing contract. #### Data Mode When uploading resources, the **RP** needs to upload the token generation parameters together, and then when the **RC** performs the purchase operation, the DToken contract and **MP** purchase contract are invoked through the SDK methods provided by the marketplace. The marketplace provides an SDK for querying the on-chain data chain. The platform needs to be integrated into its own project so as to allow users to view the description of the data. The platform can customize the exchange method, such as online or offline transaction tokens. {% hint style="info" %} #### Off-chain Conflict Resolution and Arbitration After the **RC** executes the purchase operation, it can have all the rights of the token. When the **RC** applies for arbitration, the **MP** arbitration contract will pledge the token. When the **OJ** determines that the **RP** has not provided the resources and sends this result to the transaction smart contract, it handles the resolution process accordingly. {% endhint %} ## Resource Transaction After the resource retrieval phase, that is, after the **RC** quickly retrieves the required resources based on the resource meta-information at the **MP**, the **RC** will conduct transactions with the **RP**, the owner of the required resources. The resource transaction process roughly includes the following steps: 1. **Place an order:** The **RC** quickly retrieves the required resources according to the resource meta-information at the **MP**. The two transacting parties sign an electronic contract for resource transaction via ONT Sign, set the subject matter of the transaction (such as the right to use the resources), transaction details, and staking information of both parties (optional), transaction lock-in period (optional), dispute resolution logic, profit distribution logic, etc., and then create the smart contract. In order to prevent malicious behaviours, the **RP** and the **RC** each need to stake a certain amount (it may be 0) of tokens according to the electronic contract; 2. **On-chain transactions:** The **RP** generates the DToken on the blockchain for the transaction of resource rights, and transfer the DToken to the **RC**. The **RP** can also authorise the **MP** to generate the DToken. The **RC** can trade the DToken per the contract: 3. When the transaction of DToken does not involve the delivery of off-chain resources, it can be in the form of atomic transactions without setting a transaction lock-in period; 4. When the transaction is in the form of resource exchange, the **RC** will also generate DToken for the resource that is to be traded. Of course, the DToken can also be generated by an authorised **MP**. DTokens can also be traded in the form of atomic transactions, and can set a transaction lock-in period based on whether off-chain delivery is required; 5. When the transaction is in the form of exchanging resources for tokens (such as ONG), the token holder stakes a required amount of tokens into the transaction contract and sets a transaction lock-in period based on whether off-chain delivery is required; 6. **Off-chain resource delivery:** After the on-chain transaction is completed, the transaction lock-in period is triggered. During the lock-in period, the **RC** uses the DToken to receive the resources from the **RP**, that is, the rights to use the resources change hand. When a dispute arises, proofs need to be submitted to resolve the dispute. There are on-chain and off-chain proofs. The proofs can come from the Ontology blockchain, Ontology Oracle, and the **OJ** specified in the contract. ![Resource Transaction Process](https://1077617372-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LvPXC4l2V4Z8gRDNIoZ%2F-MA_ohmxPEVNZoyCm-1v%2F-MAtkg3YOVEv4WHLzL7j%2Fres-pub-stage.png?alt=media\&token=a73c0884-c187-4338-91fe-0a81ca3dd31d) ### Electronic Contract After going through the resource discovery stage, the **RC** quickly retrieves the required resources based on the resource metadata at the **MP**, and both parties can sign the relevant resource transaction electronic contract via ONT Sign. If the resource transaction process does not involve **OJ**, i.e. **OJ** is not required for off-chain judgment, it is not necessary to sign an electronic contract. According to the characteristics of its tradable resources, MP can set up electronic contract templates to guide its users to quickly sign electronic contracts. Generally speaking, electronic contracts mainly include the following: * **Transaction subject matter.** The subject matter of the transaction is a certain right of a certain resource. * **Trading party.** Mainly specifies the **RP** and **RC** of the transaction. * **Trading rules.** Mainly stipulates the delivery period, delivery stage, delivery method, etc. * **Transaction lockout period and dispute handling logic.** When it comes to delivery and disposal of off-chain resources, it is recommended to set a transaction locking period and set dispute handling logic. During the transaction lock period, both parties to the transaction can deliver off-chain resource rights. When a dispute occurs in an off-chain transaction, the dispute is resolved in accordance with the dispute handling logic, and the result of the dispute is recorded on the chain. Generally, the chain of dispute resolution results is carried out by OJ. In addition, [**Ontology Oracle**](https://docs.ont.io/ontology-elements/oracle) system can also be used for off-chain dispute resolution. * **Both parties pledge information.** It is agreed whether the two parties of the transaction need to pledge a certain amount of tokens. In general, **RC** will be required to pledge tokens that are at least equivalent to the price required to obtain the subject of the transaction to make the transaction smooth. Sometimes, **RP** may also be required to put in a certain amount of tokens as security deposit to prevent them from doing malice. * **Profit distribution:** It mainly stipulates how to divide the profit after the transaction is completed. The suspension or cancellation of the transaction is also considered a way of completion. Split run is mainly carried out between the parties to the transaction, **MP** and **OJ**. ### Transaction Contract During the transaction lock-in period, the **RC** uses the DToken to receive the resources from the **RP**, that is, the rights to use the resources change hand. During the lock-in period, disputes may arise due to problems occurred during the transfer of resources-related rights. Under normal circumstances, since the automatic profit distribution logic usually transfers the transaction fees of the **RC** to the **RP** after the transaction lock-in period ends, the settlement of transaction disputes is generally initiated by the **RC**. The initiator of the transaction dispute arbitration needs to stake a transaction dispute application fee, which can be paid in the form of a deposit when the transaction is established. The losing side of the dispute arbitration will pay the costs incurred and possible fines. When the transaction dispute arbitration rules that the initiator loses, the transaction dispute application fee will be used to pay the arbitration fees; if the other party loses, then its stake is usually used to pay the arbitration fees. For one transaction, due to the existence of the contract and the **OJ** jointly designated by the two parties, the result of the first dispute arbitration shall prevail. When a dispute arises, proofs need to be submitted to resolve the dispute. The tamper-proof, open and transparent blockchain, as well as the automatically executed contracts, help improve the transparency of the data transaction process, can record the process of disagreement, and facilitate the transacting parties (the **RP** and the **RC**) to submit the necessary proofs. In order to increase the transaction processing speed and the degree of automation, the conditions for the success or failure of the transaction need to be defined. For example: * Whether the **RP**'s resources are accessible during the transaction lock-in period. If the **RP** cannot provide this proof, the transaction will fail; * If the **RP** submitted the **RC**'s record of resource delivery, the transaction will be successful. Each condition corresponds to a validation logic. When a dispute arises, proofs need to be submitted to resolve the dispute. There are on-chain proof and off-chain proof. * The verification of on-chain proofs is done directly by the blockchain nodes. Common on-chain proofs include digital signatures, preimages on Hash functions, zero-knowledge proof, Merkle Proof, and so on. The off-chain information imported into the chain through Ontology Oracle can also be considered as on-chain proof and is processed by relevant processing logic; * When there is a dispute that cannot be settled on the chain, then an **OJ** is required to complete the verification of the off-chain proof. The **OJ** completes the confirmation and arbitration of the off-chain transaction according to the electronic contract signed by the two parties via ONT Sign and sends the arbitration result to the smart contract of the transaction. The arbitration result is part of the dispute settlement. The proof of dispute liability determination, whether it is on-chain or off-chain proof, will affect the outcome of dispute liability determination, which in turn will affect the profit distribution of transactions. The determination of the liability for the dispute may trigger profit distribution in advance. ## Resource Incentive Sharing After the transaction lock-in period, that is, after the off-chain resource transfer period ends, the transaction will enter the profit distribution phase. Profit distribution is mainly between the two transacting parties, the **MP**, and the **OJ**. Profit distribution is a relatively broad concept, including returning the staked token to both parties and distributing transaction fees to the **MP**. Either party of the data transaction can trigger profit distribution, which will automatically distribute the profit based on the preset logic. * If there is no dispute, profit distribution will be triggered automatically when the lock-in period ends. * If an arbitration occurs, then the profit distribution operation will be triggered automatically according to the arbitration result when the lock-in period ends. Transaction success, termination, or penalty for malicious behaviour are all a form of profit distribution. The conditions for the success or failure of a transaction formally define the possible status of the transaction and the corresponding judgments to execute the appropriate profit distribution strategy accordingly. For example, the profit distribution strategy defines that when the **RP** cheats, the staked token of the **RP** will be confiscated when a dispute occurs. Then if the **OJ** rules that the **RP** did not provide resources and puts the result into the transaction smart contract, the contract will be executed accordingly. ### Profit Distribution Policy **In case of no disputes**, the incentive is shared as per policy. * The marketplace platform uses the contract to set transaction fee rate, deposit rate, and the arbitration fee rate. * **RP** receives the resource deposit amount * **RC** receives the resource tokens * The marketplace platform receives the transaction fee **In case of a dispute**, the incentive is distributed based on the dispute resolution result. * The marketplace platform can use the contract to set transaction fee rate, deposit rate, and the arbitration fee rate. Before publishing a resource, the RP needs to pay a resource deposit, and the RC needs to pay transaction fees to the marketplace platform. * If a party initiates arbitration, the arbitration fee shall be paid by the concerned party, and the fee shall be pledged into the **MP** arbitration contract through the API. * If the initiator is judged to be unsuccessful by **OJ**, the final arbitration fee will be owned by **OJ**. The commodity fees paid by **RC** in advance will be distributed to both parties by **OJ** through the **MP** arbitration contract interface. The **MP** platform will finally get the transaction fee when **RC** carries out the purchase. {% hint style="info" %} The various fees with respect to the marketplace are calculated as follows: *Resource Deposit* **=** *Resource Price* **\*** *Deposit Rate* *Platform Transaction Fees* **=** *Resource Price* **\*** *Platform transaction fee rate* *Arbitration Fees* **=** *Resource Price* **\*** *Arbitration fee rate* The **OJ** needs to be hired and provided by the **RC.** Generally speaking, an arbitration is triggered by the **RC** in most cases. {% endhint %} {% content-ref url="solutions/offline-judge" %} [offline-judge](https://docs.ont.io/decentralized-identity-and-data/ddxf/solutions/offline-judge) {% endcontent-ref %} ## Post-Transaction Review After the transaction is completed, the **RP** and the **RC** review each other. The review can be about the resources or users. The **MP** can provide a review system and the post-transaction reviews are stored in the **MP**'s local database. When the on-chain review system is well-established, the **MP** can use a combination of the on-chain review system and local review system to present a more accurate rating. Please proceed to the next section for more details regarding the currently available solutions.