At the heart of the OWN protocol is the OWN Royalty Token (RT). This smart contract manages the flow of music IP cash on the blockchain and is tied to real-world media income, like digital streams, physical music sales, or merchandise. Thanks to validation from a Payment Oracle (PO), the RT bridges off-chain payment streams with on-chain ones.
Key features of a RT include:
Additional metadata can be attached to the RT by a network of data providers.
Artists have control over the financial data they share on-chain, such as limiting the revenue history displayed on the asset fact sheet. However, less transparency may reduce their RT market. Future zero-knowledge proofs will offer artists more privacy flexibility.
A Wrapped Royalty Token (WRT) is a type of Royalty Token (RT) that has been wrapped in a protocol wrapper contract, allowing full interaction with third-party participants or DeFi protocols. This adds several additional features to the RT, including:
The additional features that a WRT adds to a RT make it a more versatile and valuable asset. WRTs can be used for a variety of purposes, including:
WRTs are a new and innovative way for artists, rights holders, and fans to interact with the music industry. They offer a number of benefits for all parties involved, and they have the potential to revolutionize the way music is created, consumed, and monetized.
Bridging off chain assets to web3 adds risk into on chain protocols: how can artists, investors or developers rely on a reliable transfer of payments? How can they rely on honest, competent behavior? How can the protocol protect against fraudulent behavior? In the OWN Protocol this important role is fulfilled by Payment Oracles (PO).
POs are in charge of validating RTs and distributing payments to artists’ blockchain assets. They bridge the off-chain and on-chain payments worlds. Ensuring they do this in a trustworthy fashion is the key part to the OWN protocol. The only participants who can ensure this as POs are the participants in the music industry with the access to the information and revenue flow needed to be the bridge between worlds: distributors, labels, music rights owners, and publishers.
To ensure this trusted bridge, becoming an oracle has several requirements:
POs have several jobs as part of the protocol:
While anyone can create a RT, only verified POs have an authentication signature recognized by the protocol. RTs that are not validated and signed by recognized protocol oracles cannot use the wrapped RT contract. They should not be trusted by the community as no music industry player, that has been vetted by the OWN Foundation, has committed to transferring royalty payments on-chain or staked $OWN as collateral.
Ensuring proper payment flow are a few simple, yet powerful, real world structures on the relationship between a RT, artist and PO:
The protocol ecosystem will have different types of data providers who bring off chain data, on chain and provide other helpful data services regarding RTs. For example DSPs will be able to increase transparency in the music royalties payment ecosystem, by providing ZK proofs of royalty amounts they have paid out. This will enable artists to validate the payout amount they receive at the end of the music supply chain.
Other data providers could include advanced analytics and financial analysis on RTs, real world fraud audits, music indexing and other use cases that require third party data. For privacy reasons, not all data will be publicly available. Thus third party data providers are needed to offer these services.
Data providers are ecosystem players in the OWN protocol who have the ability to provide these services and make their data available on chain for any third party to use. Example Data providers could be, but are not limited to, DSPs, Public Rights Organizations, record labels, distributors and financial analysts for music assets.
Fraud governance enables aggrieved players to submit a claim of wrongdoing by a network participant, such as an oracle. Fraud claims regard the flow of payments on-chain or lack thereof as well as whether RT follow the protocol rules in terms of data availability. Once evidence of a network fault has been accumulated, a claim can be submitted to protocol fraud governance for adjudication. Adjudication is a distributed process that anyone can take part in and applies decentralization and game theory to enable as fair a process as possible.
Should the fraud proof prove successful, the oracle is penalized, and its stake is slashed (in accordance with the kind of wrongdoing). The slashed stake is split between the fraud agent and the injured party.
In addition, the protocol will maintain a status leaderboard showcasing each Oracle and Data Provider stats, such as how many current disputes are ongoing, past disputes and their result, as well as how much of the data is transparent and accurate (see: Data Channels below). This will allow anyone to monitor these disputes and offer a scoring mechanism to protocol participants, further driving participants to adhere to a higher standard.
The music industry has many types of fraud and disputes, mainly regarding IP rights. Over the years, a robust system has been developed in the existing legal and global framework to deal with these cases. The OWN Protocol lets the existing legal framework deal with these issues and only focuses on fraud and faults that relate explicitly to bridging traditional royalties to web3 rails.
Examples of fraud the protocol does not deal with currently:
The above are examples of fraud in the existing legal system and will be dealt with accordingly - by the existing 'real world' legal framework, not the OWN Protocol.
Examples of protocol fraud can be:
OWN protocol governance aims to include all stakeholders in the network with a fair share of voting power in proportion to the value they bring to the network and not just the monetary value of their staked $OWN. While aiming for a protocol with ‘minimum viable governance’, governance controls some of the most important aspects of the OWN protocol due to the necessity of bridging between the traditional music world and the on-chain ecosystem:
These decisions must be done while giving proper and fair voting rights to all stakeholders in the protocol:
To maintain fairness we do away with the “one token, one vote” model prevalent in many protocols and instead implement a weighted voting mechanism based on Protocol Derived Value (PDV). PDV is judged by how much different actors contribute to the network as described below. This avoids stakeholders with a large amount of capital from capturing protocol value at the expense of creatives and other less capital rich, but equally valuable, protocol participants.
As governance votes influence critical aspects of the protocol, such as the protocol fee take rate, we aim to minimize attack vectors on capturing protocol value and maximize a distributed voting mechanism among all stakeholders. We do this through three mechanisms:
Each 25% allocation is then subdivided based on individual wallet PDV. Allocations can stack, thus an oracle who also offers liquidity and stakes $OWN tokens would receive $dOWN to represent the value add they contribute to the network. $dOWN can be delegated or traded leading up to the vote but can only be used in that one-time vote.
