A Community for Royalty Sharing

The Shared Royalty Non-Fungible Token (SRNFT) is an open source project started by the ConsenSys Web3Studio team.

The purpose of the SRNFT is to make any royalty business model — from the oil and gas industry to entertainment — easy to manage with the Ethereum blockchain.

Now the project is ready for you to get involved. Go to GitHub to use our assets, create issues and contribute code…even step up to become a maintainer.

Hero Image

Introducing the SRNFT

The SRNFT, an extension of the ERC721, does three things:

  1. Manages and distributes future cash flows to multiple parties, called Franchisors, within a single token
  2. Helps make off-chain digital assets unique and traceable
  3. Creates an economic incentive for holders of those assets not to leak them inappropriately to the public

The SRNFT “bootleg” token can be applied to business models across the spectrum — certainly music and live performance but also gaming and sports. For example, think how an SRNFT token could present opportunities for games like Fortnite, by allowing dance creators and fans to build franchises around special exclusive moves and other unique assets.

Bootleg: SRNFT in the Music Industry

In this developer kit, we illustrate the use of the SRNFT with a unique application for the music industry, addressing the practice of making and distributing bootleg videos of live concerts. It’s aimed at helping musicians build new recurring revenue streams, secure digital rights and turn fans into partners around exclusive offerings like rare concert footage.

Read the original Bootleg story on Medium.

The Bootleg SRNFT also helps secure exclusive content with a watermark that can trace a video file to a single owner. And it turns fans that buy that content into partners that share in the royalties from future sales. This gives fans an incentive not to copy the video and leak the exclusive asset to something like BitTorrent.

Music Industry Image

“This project isn’t just about trading performance videos like CryptoKitties. It’s about seeing fans differently — as micro-communities that curate and share a rare digital asset, maintain its integrity together, and have a stake in the revenue that comes from adding new members to that tribe. And it’s about fans being able to see the band differently, to have rare and sometimes unique access that may rival the intimacy of being at a live show.”

Joe Lubin

ConsenSys Founder

Since publishing the Bootleg story, we’ve received an unusual amount of interest from entrepreneurs that want to build a real “Bootleg” business. We say, “Go for it!” We’ve made some application designs and done some early user research on this to help.

If you decide to build your own royalty-sharing business with the SRNFT, reach out on Twitter to tell us about it and get help. ConsenSys is always looking for exciting projects to back.

Bootleg fan mobile app

One Example Bootleg dApp Design

A complete Bootleg business would involve integrated user experiences for fans, bands, managers and bootleggers. It would allow a bootlegger to get permission to shoot the concert. It would allow the band or its management to review bootleg videos and either request changes, reject, or mint a submission into one or more tokens, which the bootlegger could then sell as unique “prints.” And it would allow everyone to keep track of their royalties.

That’s just scratching the surface.

To really test the idea, we chose one specific user experience: the fan finding, browsing, buying and selling bootleg videos of their favorite acts.

We created a prototype and observed a variety of people, who had never heard of the bootleg concept before, navigating through it.

Almost all of our work on this project is freely available, but our user research recordings are private, to protect the privacy of the individuals who were kind enough to spend their time with us.

“Buidl” your Own Bootleg dApp

We created a bare-bones shared royalty token contract to do some testing and very simple trades. We encourage you to build on what we have and create fully featured contracts to make Bootleg real!

To make an application like Bootleg, there needs to be a working “Bootleg dApp,” a selling contract, and a token that implements the ERC721 and the SRNFT extensions. All of these are described below.


As the actual dApp and selling contracts will vary by use case, we’ve left those for you.

Bootleg fan mobile app

Find it on GitHub

The code for the SRNFT and the Bootleg Application example resides in the Bootleg GitHub repo. The purpose of the following sections is to help set context for what’s happening in the code, labeled “YOUDO”, and suggest places where you will want to complete or modify it for your project.

Shared Royalty Non-Fungible Token

A Shared Royalty Non-Fungible Token (SRNFT) is a set of interfaces and implementations extending the ERC721. The SRNFT stores a list of Ethereum accounts called “Franchisors” in the form of an array, so that a single token can manage cash flows to multiple parties according to a royalty distribution formula.

An ERC721 implements only one account as the token Owner, and the SRNFT maintains this restriction (though it would be interesting to modify this). So while there can be many Franchisors, only the most recently added one has the ability to sell Ownership to someone new.

The mechanism of the payment is what makes these tokens unique. It is a distributed, shared royalty. Different royalty distribution formulas can be implemented. Each would create different incentives for the participants, depending on the desired outcomes. For example, payment could be done as equal splits, on an increasing curve, or even randomly.

Royalty Distribution Formula

Every SRNFT contains a unique Royalty Distribution Formula (RDF). An RDF describes and implements a model for how royalties are distributed across Franchisors over time as new parties pay to become the new Owner and be added as a Franchisor. The RDF is responsible for creating proper incentives for unique use cases. For example, in a Bootleg application, the RDF should be designed to maximize:

  1. Revenue to the Performer over time
  2. Revenue to the creator of the Video, called the Bootlegger
  3. Incentives for Owners to keep transferring the token (adding more Franchisors)
  4. Incentives for Franchisors not to leak the video.

In this case, Franchisors leaking a bootleg would presumably hurt the prospect of future cash flows to themselves and other Franchisors — though legal agreements signed via OpenLaw or another system when becoming a new Franchisor/Owner can stipulate real-world penalties for leaking as well.

Access and ownership model

How Royalties are Calculated and Distributed

Conceptually, the way to think about what’s happening in a Bootleg token is that it is an ever-increasing bank account of money, composed of smaller bank accounts for each Franchisor, where each time new money comes into the token, it is split-up between these Franchisor accounts.

When the existing Owner transfers the token to a new Owner, a payment from the new Owner is stored in escrow, where each Franchisor can withdraw their portion according to the token’s RDF. This provides an ongoing revenue stream to all Franchisors, as long as the Owners continue to add new Owners to the group.

Shared royalty token contracts store a simple data structure for every token:

struct Token {
  // The list of franchisors
  address[] franchisors;

  // A list of payments (in wei). Payment indices line up to
  // what payment was made for the matching franchisor
  uint256[] payments;

  // For any franchisor, what is the next payment index that a
  // withdrawal should next consider.
  // (More details on this part later.)
  mapping(address => uint256) franchisorNextWithdrawIndex;

Source: AbstractSharedRoyaltyToken.sol

Whenever a new Franchisor is added, usually during minting or transferring a token from one Owner to another, a few things happen:

function _addFranchisor (
  address franchisor, uint256 payment, uint256 tokenId)
  // A new franchisor is added to the list

  // Payments sent will be associated with that franchisor

  // We set where this franchisor can withdraw from
  token.franchisorNextWithdrawIndex[franchisor] = token.payments.length;

Source: AbstractSharedRoyaltyToken.sol

How Withdrawals Work

Shared royalty tokens follow a withdraw pattern to avoid re-entrancy. In addition, because the EVM poses a limit on the maximum number of loops performed in a single transaction, the payment distributions are calculated during a withdraw, which can be broken up. This process is what franchisorNextWithdrawIndex uses to prevent double-withdrawals.

The Shared Royalty Token Interface creates a place for implementing token models to define their RDF, in paymentBalanceOf.

* @notice Gets remaining payment balance accumulated from the transfer
*   of a given token up to a `count` of proceeding payments
* @dev Used by `withdrawPayment` to calculate what a franchisor is owed.
* @param franchisor address to get the payment balance of
* @param start The payment index to start from
* @param count The number of payments to traverse
* @param tokenId The identifier for an NFT
* @return uint256 representing the balance in wei accumulated for a token
function paymentBalanceOf(address franchisor, uint256 start,
  uint256 count, uint256 tokenId) public view returns (uint256);

Bookend: An RDF Model Example

For our example Bootleg app, we wrote the code for one particular model RDF called the bookend model. This model is a version of a SRNFT which implements a simple scheme for distributing royalties where the most immediate seller and the performer split payments from adding a new franchiser.

We have a sample, reference implementation to demonstrate this particular SRNFT, called the BookendSharedRoyaltyToken.

Decentralized Off-chain Non-transferability

In Bootleg, the non-fungible shared royalty token represents the ownership of a video. In order for this token to maintain its value we need to prevent token holders from sharing the video with people outside of the system.

To help prevent people from copying the video, we decided to use a digital watermarking, called the dONT protocol that:

  1. Disincentivizes token holders from sharing the video with non-token holders (a form of DRM).
  2. Prevents video distributors from maliciously framing innocent token holders for leaking their copy.
  3. Is more efficient than other watermarking protocols, because it only necessitates a one time encryption of the video. This is accomplished by having the watermark embedded in the decryption key, instead of in the video. When a person uses their individual decryption key to obtain the plain text of the video, a watermark containing their identity is implicitly embedded into the video.

To demonstrate the concept, we are in the process of creating a starter implementation. The code lives in it’s own web3studio-dONT repository.


Join the Open Source Effort! As of March, 7th, 2019, the work is just getting started. It will be built according to series of progressive hierarchical tasks. Check out our open issues.

Architecture of a dONT Compliant System

decentralized off-chain non-transferability protocol

Research and Sources

dONT is an implementation of TTP-Free Asymmetric Fingerprinting Based on Client Side Embedding.

That’s it!

Please consider forking our repo on GitHub and getting involved.

Glossary of Terms

The following words occur throughout this devKit and the code in the GitHub repo. Here are the terms and their definitions.

Names for SRNFTs

Creator - the generalized persona of what, in the reference implementation we call the “Performer” (because we built this one to suit bootlegging music concerts). The Creator (or Performer) is typically in position [0] of the Franchisor Array and would usually get a larger and often fixed % of all subsequent Payments. The Creator (or a counterparty working for the Creator) typically will authorize and mint a number of Prints of their asset (or the asset of a derivative work that the Creator permits to be made based on their original work).

Print - An instance of a tokenized asset that defines a specific array of Franchisors and Payments.

Franchisor - Any party represented by an Ethereum account ID appended to the Franchisor Array. The nth Franchisor is the Owner. The 0th (first) Franchisor is typically the Creator/Performer.

Owner - Bootleg Owner is based on Owner concept in ERC721. The Franchisor in this SRNFT reference implementation is set automatically as the nth (last) Franchisor in the array and has, in this implementation, the sole ability to sell the Print, which will append the buyer’s Eth account ID to the Franchisor Array, automatically transferring Ownership from current Owner to the new Owner.

Payment - A Fan pays some amount to become a new Owner of a Print. The Print maintains an array of these Payments in the paymentsBalanceOf() function.

Royalty Distribution Formula (RDF) - Each Franchisor is entitled to a percentage of future cash flows paid by new Owners. This is calculated when a Franchisor withdraws their percentage of the Royalties. This is activated by withdrawPayment() function.

dONT - An encryption and watermarking scheme based on TTP-Free Asymmetric Fingerprinting Based on Client Side Embedding. It is devised specifically for Bootleg tokens to ensure that each Franchisor has a unique copy of a Print (instance of a Bootleg video, in this case). It sets a digital watermark tied to the Ethereum Account of a single Franchisor, so that if the video is accidentally or intentionally leaked to the public, the Franchisors will know whose copy was leaked.

Names specific to the Bootleg application example

Performer - an instance of Creator. The Performer controls the minting of Prints.

Bootlegger - the party that shoots a video of the concert, submits it to the Performer for approval and typically will be placed into position [1] in the Franchisor Array of each Print minted by the Performer.

Bootleg - In this reference implementation, the Bootleg is the original video file that is submitted to the Performer to mint into Prints. It is the base off-chain digital asset that is encrypted and used to create the Print asset, which in turn is run through the dONT process to watermark each Franchisor’s copy, making it unique to them alone (which also allows leaks to be tracked to the source of the leak).

Fan - In the reference implementation, a Fan is a user that buys a bootleg video Print and becomes a Franchisor (or is a user of a Bootleg application and might buy a Print).