Blockchain infrastructure for music IP royalties

Last updated: MAY 30, 2023

The Royalty Token

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:

  • PO Signature Validation: A PO assures the off-chain payments connected to a specific music IP will be sent to the on-chain RT smart contract.
  • Owner Wallet: This is the main recipient of the on-chain payment flow, usually the same wallet linked to the RT.
  • Revenue Splits: An RT can distribute payments among different wallets.
  • Asset Fact Sheet: This offers information on past revenue and artist details.
  • Preferred On-chain Payment Currency: This could be USDC, LUSD, ETH, OWN, etc.
  • Copyright Infringement Flags: These are used if a PO knows about any legal issues with the royalty stream.
  • Service Fee: This is a protocol fee divided between the protocol and oracle.
  • Burn Mechanism: This feature allows the artist to remove the RT from the blockchain.

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.

Wrapped Royalty Tokens

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:

  • Designated wallet addresses: The WRT can be set to send royalty payments to a designated wallet address, even if the RT is owned by someone else. This is useful for things like using WRTs as collateral or staking them to earn rewards.
  • Time period: The WRT can be set to exist for a specified period of time. During this time, the WRT is "locked" and royalty payments must be sent on-chain. This can be useful for things like creating a fixed-income investment product or funding a project with a specific deadline.
  • Risk factor and suggested discount rate: The WRT can be assigned a risk factor and suggested discount rate based on the analysis of a Data Provider. This information can be used by investors to make informed decisions about whether or not to invest in the WRT.
  • Percentage of payment flow: The WRT can be set to lock up a percentage of the RT's payment flow. This allows artists to partialize their royalty streams and investors to fractionalize their investments.
  • Termination details: The WRT can be set to terminate under certain conditions, such as when the specified royalty payment amount has been received or when the artist chooses to terminate the WRT early. This provides investors with some protection against risk.

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:

  • Collateral: WRTs can be used as collateral for loans or other financial products. This allows artists to access liquidity without having to sell their music rights.
  • Staking: WRTs can be staked to earn rewards. This provides artists with a way to generate passive income from their music rights.
  • Investing: WRTs can be bought and sold on decentralized exchanges. This allows investors to invest in music royalties and earn money from the success of their favorite artists.

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.

Payment Oracles

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:

  1. POs must be parties in the music industry with the visibility to the information and payment flow to provide the bridge between web2 and web3. They are the last link in the music value chain that makes payments to artists and rights holders. This makes them able to be responsible to facilitate payments and information regarding a RT.
  2. POs are required to stake $OWN in proportion to the payments volume they send on chain. The proportional amount of staked $OWN will cover fraudulent behavior. Should they act fraudulently, their stake can be slashed.
  3. Initially, a party must be verified by the OWN Foundation to be a PO. This will assist building trust in the protocol in early days. In the future a more open and decentralized approach will be taken to ensure the onboarding of non vetted POs, allowing more participants in the music industry to take part in the protocol as POs.

POs have several jobs as part of the protocol:

  1. POs primarily deal with the artists and rights holders they manage and distribute payments to. They provide a user interface for artists and rights holders to opt in to creating RTs for their assets and onboard them into the web3 ecosystem as needed.
  2. POs check that the RT has no legal red flags or copyright infringement claims that they are aware of. They make the RT asset fact sheet available for use by third party protocol participants, on and off chain.
  3. POs receive music streaming data and payments from DSPs and submit payments on-chain. They commit to sending payments on-chain within 30 days of receiving payments from DSPs to ensure fast and efficient payment bridging between the off chain and on chain world.

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:

  • RTs represent an artists’ payment preference to get paid on-chain, rather than via another payment (such as paypal or ACH). POs are legally obliged to send payments to artists, via the payment preference of choice according to the terms of their mutual agreement.
  • POs might send “faulty” payment (faulty in this case being either wrong amounts or late payments), however the artist has real world legal recourse, as they do regarding any other faulty payments between their distributor and themselves.
  • POs are incentivized to make payments on chain as they earn an additional $OWN fee.
  • Should a PO be fraudulent, they risk being slashed by the protocols fraud governance arbitration mechanism (see below).
  • POs are subject to on-chain reputation which incentivizes better behavior, much like staking operators are judged today in other proof of stake protocols. Over time better PO operators will receive better ratings and reputation from the ecosystem, giving the RTs they vouch for more value and providing more value for the artists they manage, incentivizing more artists to work with them.
  • As the protocol matures, and ZK proofs become more accessible, DSPs (Digital Streaming Providers), who are the source of truth regarding actual revenue for music IP, will be able to submit an encrypted proof of payment. that will allow the protocol to validate PO payment matches the PO reported revenue and thus increase trust in distributors who provide these cryptographic proofs against the DSP statements.

Data Oracles

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 Arbitration

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.

What constitutes fraud?

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:

  • Violation of IP rights by uploading someone else's music to a distributor and collecting royalties, for example someone who is not Taylor Swift distributing her music and earning rewards.
  • ‘Farming music streams’

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:

  • Not transmitting funds on chain to a relevant RT in a timely fashion, despite receiving the funds from DSPs or other third parties - this could harm the RT owner or a 3rd party investor or developer who is counting on the royalty.
  • Providing an incorrect asset fact sheet - this can harm RT owners and 3rd party investors or developers who rely on the accuracy of the asset fact sheet to properly value their RT.
  • Not maintaining a data channel or the liveness of data - data liveness can hurt integrations and 3rd parties who rely on the asset data.
  • Paying a RT directly without paying the protocol fees - this hurts the protocol by not playing by the designed rules and violating the trust and economics of the protocol.


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:

  1. Inflation rate of the $OWN token
  2. Protocol fee take rate
  3. Oracle approval
  4. Fraud adjudication
  5. Smart contract upgrades

These decisions must be done while giving proper and fair voting rights to all stakeholders in the protocol:

  1. Music industry institutions: record labels, distributors, DSPs, PROs.
  2. Artists, rights holders and creators
  3. Investors
  4. Developers

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.

Minimum viable governance

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:

  1. Time-interspersed voting: Main governance votes are conducted on a yearly basis, not on an ongoing basis. The interspersed voting calendar gives participants who are not involved in daily governance the time to make an informed voting decision. Ongoing protocol governance will occur on a shorter time frame by committees voted for in the main governance votes. This structure mimics current democratic structures of delegation.
  2. Protocol Derived Value (PDV) based voting: Voting power is represented by value to the network and not only staked $OWN. PDV includes metrics such as the number of RTs created per artist, RTs validated per oracle, RT-based transaction volume, $OWN staked, liquidity provided etc.
  3. Derivative voting token: Prior to the main governing vote a derivative OWN token, $dOWN, is distributed to all participants in the protocol. $dOWN is used to vote in the upcoming governance decision and is thereafter burned. Each governance vote uses a new $dOWN. This prevents voting power accruing over time to capital rich parts of the protocol. $dOWN is divided equally among the different participants:
  • 25% to POs
  • 25% to artists (as determined by RT owners)
  • 25% to $OWN token holders
  • 25% to liquidity pool providers and developers

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.