AudiusA Decentralized Protocol for Audio Content

Roneil Rumburg Sid Sethi Hareesh Nagaraj

Last Update: August 12, 2019∗

Abstract

The music industry generates $43 billion in revenue but only 12% goes to content creators. Further-more, creators have minimal control over how their music is distributed and little visibility into whois listening to it. To address these and other problems faced by creators, we introduce Audius, a fullydecentralized music streaming protocol built with public blockchain infrastructure and other decentral-ized technologies. Audius allows creators to distribute to and get paid directly from their fans, and iscomprised of the following components:

1. An efficient dual-token economy, with one native staking/work token and one payment token backedby 3rd-party stablecoin(s)

2. A decentralized storage solution for sharing audio and metadata

3. A unique track encryption scheme paired with a payment mechanism to unlock user-specific proxyre-encryption keys for content

4. A discovery protocol for users to efficiently query metadata

5. A community arbitration protocol to fairly and efficiently resolve disputes filed by protocol partici-pants

6. A decentralized governance protocol, whereby artists, service providers, and listeners are individuallyand collectively enfranchised in decision making about protocol changes and upgrades

We also discuss a path to building this protocol over time, starting with a functional subset of thesecomponents and working with the community towards a complete implementation.

∗Audius is a work in progress and the contents of this paper are subject to change. The most current version can be found athttps://whitepaper.audius.co. For feedback and comments, please contact whitepaper@audius.co.

1

Contents

1 Introduction 41.1 Current problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 The Audius project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Audius and Loud tokens 52.1 Loud (ticker LOUD): Token for price stable value transfer . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Audius (ticker AUDS): Token for protocol governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Why create new tokens? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 AudSP: A decentralized storage protocol 73.1 Content services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4 Track upload and management 84.1 Proxy re-encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84.2 Revenue escrow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5 Payments and revenue sharing 95.1 Pay-per-stream, ad-supported, and subscription models . . . . . . . . . . . . . . . . . . . . . . . . . . . 95.2 Revenue sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

6 Discovery 106.1 Discovery API interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106.2 Discovery services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116.3 Enforcing accurate results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

7 Arbitration 117.1 Case types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117.2 Arbitrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117.3 Arbitration process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

7.3.1 Case initiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117.3.2 Arbitration committee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117.3.3 Vote tallying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137.3.4 Case outcomes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137.3.5 Appeal process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

7.4 Future improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

8 Governance 148.1 Direct voting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158.2 Tallying the results of a vote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158.3 Vote delegation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158.4 Bootstrapping protocol governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

9 Roadmap 169.1 Alpha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169.2 Beta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179.3 Main-network launch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179.4 Full decentralization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

10 Future work 17

2

11 Supplemental specifications 1711.1 Audius creator node specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

11.1.1 Proxy re-encryption keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1711.1.2 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1711.1.3 Creator node uptime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1811.1.4 Delegation of creator node responsibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

11.2 Governance vote tallying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1811.2.1 Proof of vote calculation consistency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1811.2.2 Example decision result calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

11.3 Social features and listener feed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

12 Glossary 21

References 22

List of Figures

1 Audius protocol overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Listener and creator Loud payments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Earnings for stakers of Audius tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Listener track unlock process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Discovery API interface registration and usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Arbitration protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Creator node interactions with protocol participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

List of Tables

1 Token types in Audius . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Arbitration case types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Governance decision-making classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Governance decision types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Distribution of voters and voting power for example decision . . . . . . . . . . . . . . . . . . . . . . . . 20

3

1 Introduction

Music creation and distribution have been dramaticallychanged by technology in the last two decades. Creatingmusic no longer requires a team of producers and audioengineers; anyone in their bedroom can start with inex-pensive software. Similarly, distributing music no longerrequires factories that produce physical records and re-tail relationships for getting those records into stores;music platforms have enabled creators to distribute theirown music.

Despite these changes in how artists create and dis-seminate music, the mechanics of value transfer and ac-crual are still largely obfuscated [1]. In 2017, the musicindustry generated $43 billion in revenue but only 12%of that made its way to artists [2]. As points of compar-ison, NFL players capture at least 47% of the revenuegenerated by the entire NFL [3], and NBA players cap-ture between 49 and 51% [4]. Centralized user-generatedmusic distribution platforms have succumbed to the in-fluence of legacy institutions, struggling to find sustain-able business models [5, 6] as existing institutions reapthe rewards of their (and artists’) labor.

1.1 Current problems

We see a number of specific challenges faced by creatorsand listeners today:

1. There is little to no transparency around the originsof creator payouts (e.g. number of plays, location,original gross payment before fees)

2. Incomplete rights ownership data often preventscontent creators from getting paid; instead, earn-ings accumulate in digital service providers (DSPs)and rights societies

3. There are layers of middlemen and significant timedelay involved in payments to creators

4. Publishing rights are complicated and opaque, withno incentives for the industry to make rights datapublic and accurate

5. Remixes, covers, and other derivative content arelargely censored due to rights management issues

6. Licensing issues prevent DSPs and content from be-ing accessible worldwide

1.2 The Audius project

We propose the Audius project as a solution to theseproblems. The mission of the Audius project is to cre-ate a fully decentralized community of artists, serviceproviders, and listeners collaborating to share and de-fend the world’s music. The Audius project will build a

decentralized audio protocol guided by the foundationalbeliefs that:

1. Protocol participants should be compensated in pro-portion to how much value they create

2. Governance power should be earned by creatingvalue in Audius, and shared consistently betweenuser groups contributing to the protocol

3. Prices and earnings for participants should be con-sistent, predictable, and transparent

4. Access should be democratized; anyone can con-tribute to Audius if they follow the protocol rules,and all information is publicly accessible

5. Intermediaries should be removed when possible;when necessary, they should be algorithmic, trans-parent, and verifiably accurate

The Audius protocol allows creators, listeners, and ser-vice providers to collectively provide a high-quality end-user music streaming experience without centralized in-frastructure. The protocol is comprised of the following5 components working in conjunction:

1. Audius and Loud tokens: common systems foraccruing value, transfering value between stakehold-ers, and securing the protocol (Section 2)

2. AudSP: A decentralized storage protocol built atopexisting decentralized storage projects, for creatorsto share content through the protocol, listeners toshare content they have cached, and content servicesto monetize bandwidth by serving files through theprotocol (Section 3)

3. Track upload and management: A protocol forcreators to share and manage their content (Sec-tion 4)

4. Payments and revenue sharing: A protocolfor listeners to stream content, dividing paymentamong rightsholders, service providers, and contentcurators (who can earn a share of revenue generatedby their reposts and playlists) (Section 5)

5. Discovery: A protocol for a network of discoveryservices that index the Audius blockchain and arepaid by other network participants to query thisdataset (Section 6)

In addition to the above components, there are twometa-protocols that govern Audius:

1. Arbitration: A protocol for a decentralized com-munity of arbitrators who are paid to resolve dis-putes arising in other areas (Section 7)

2. Governance: A protocol for modifications andimprovements to Audius, which shares governancepower among those who have created and are cre-ating value in the Audius protocol (Section 8)

4

Audiusblockchain-based

systems

Listeners

Makepayments

Contentservices

Discoveryservices

Arbitrators Creators

Streamencrypted

music

Rec

eive

paym

ents

Index

data

&

Receiv

e paym

ents

Publishnew

music

Receive payments

Arbitrate

oncases

Discovercontent Requestproxy

re-encry

ption key

Figure 1: Audius protocol overview

The protocol will also require end-user facingclients—in the context of this paper, clients are softwarethrough which users interact with the Audius protocol.Audius will produce open-source reference client imple-mentations, including an end-user listener client, creatorclient, and service provider implementations, but any de-veloper may produce and distribute their own clients too.

The Audius blockchain, referred to as such through-out the paper, is the collection of smart contracts andblockchain-based code that is used for decentralized co-ordination within the Audius protocol. We do not cur-rently intend to build our own blockchain, but insteadplan to build atop existing blockchain-based platforms.Different parts of the Audius protocol could run on differ-ent blockchain-based platforms, or utilize off-chain scal-ability solutions, where scalability trilemma tradeoffs [7]can be made on a module and subprotocol-specific basis.

2 Audius and Loud tokens

The Audius protocol will be used by a number of differ-ent stakeholders with different goals. In order for thesediffuse stakeholders to effectively work together toward

common network goals, there needs to be a unified incen-tive structure that aligns the interests of the individualwith the interests of the protocol.

The Audius protocol includes two different tokens:the protocol token (Loud), a price-stable medium of ex-change used by creators and listeners to interact withthe protocol, and the governance token (Audius), usedby service providers to participate in staking protocolsand earn proceeds from the network fee pool. Thisseparates the mechanism for price-stable value transfer(Loud) from the mechanism for value capture and ac-crual (Audius), better serving the needs of users of eachtoken.

Based on the mission and philosophies of Audius, to-ken transfers should be:

• Trustless

• Transparent

• Uncensorable

• Fast

• Inexpensive

• Direct between users, when possible

We also plan to launch a few classes of non-

5

Table 1: Token types in Audius

Token type Description Used by Used for

Loud Price-stable medium ofexchange, backed by 3rd-partystablecoin(s)

Creators, listeners, serviceproviders

Track and service payments

Audius Value capture and accrual Service providers Participate in staking toprovide services and earnproceeds from the network feepool

fungible tokens in future, representing creators, album/compilation ownership, and limited-edition creator ex-periences. These are explained further in Section 10.

2.1 Loud (ticker LOUD): Token for pricestable value transfer

Loud tokens are used by listeners and creators to pay forservices and content, and earned by content creators andservice providers. Loud tokens should be price-stable,providing a stable unit of account and ensuring that cre-ators, listeners and service providers can participate inthe Audius economy without concern for price volatility.

Loud tokens will be divisible and freely transferable.Loud tokens will be 1-1 backed by and exchangeable forone or more 3rd-party stablecoins; some potential op-tions include Dai [8], USDC [9], or TrueUSD [10].

There will be a trustless, decentralized minting sys-tem for Loud tokens wherein anyone can deposit some3rd-party stablecoins to mint new Loud tokens. Simi-larly, anyone can deposit Loud tokens into this systemto withdraw the underlying stablecoin(s), with the sys-tem burning the deposited Loud tokens after conversion.

A percentage fee, denoted PF , will be captured fromsome types of transactions in Loud tokens, including lis-tener payments to artists and service providers. Thesefees will be aggregated into the network fee pool, whichcollects fees in Loud and periodically distributes themto stakers of Audius tokens as described in Section 2.2below.

2.2 Audius (ticker AUDS): Token forprotocol governance

Audius tokens are used by service providers to help runthe Audius protocol, and should allow transparent anddirect value capture and accrual.

Audius tokens are divisible and transferable. The sup-ply of Audius tokens will have an initial allocation andwill inflate at a globally defined yearly inflation rate.

Trackregistry

Creators

Pay bondto uploadPlaylist

registry

Repostregistry

Network fee to create

Creator revenuesharing system

Curators

Listeners

Pay for proxyre-encryption

key

Contentservices

Discoveryservices

Pay persegment

Pay perrequest

Legend:

Transfer with no network fee

Transfer with network fee

Figure 2: Listener and creator Loud payments

6

Network feepool

Market

AudiusAggregated

fees

Contentservices

Discoveryservices

Arbitrators

Governancestakers

Earni

ngs

inA

udiu

s

Figure 3: Earnings for stakers of Audius tokens

More details about this initial supply and inflation sched-ule will be provided in a separate specification document.

Service providers must stake these tokens in order tooperate a discovery service (with a larger stake correlat-ing to a higher probability of being chosen by listenerclients), create a new discovery service API version, bean arbitrator (with a larger stake correlating to a higherprobability of being chosen for cases), file certain arbi-tration claims, and vote with their tokens on governanceproposals. Fees for certain arbitration types and rewardsfor reporting invalid discovery service results are alsopaid in Audius tokens.

Proceeds of the Audius token supply inflation will bedeposited into the network fee pool. Additionally, net-work fees collected in Loud tokens will be used to pur-chase Audius tokens at market price, and these Audiustokens will be deposited into the network fee pool.

Audius token holders who have staked Audius tokensto be a service provider, with the exception of those stak-ing exclusively for governance voting, will earn a shareof the network fee pool proceeds proportional to theirnetwork-relative stake size. Service providers must stakeAudius tokens to register their services; this requires oneto have a stake in the protocol’s long-term success in or-der to operate on the network, aligning their incentiveswith long-term network value creation.

These network fees and inflationary rewards compen-sate Audius stakers for the services they provide to theprotocol, and give them a financial incentive to increaseusage of Audius (more usage should lead to more net-work fees).

2.3 Why create new tokens?

This structure poses an interesting question: why createthe new tokens for Audius and Loud? Other cryptoassetsalready exist that can serve some of the functions of ourtokens.

There are many projects building price-stable curren-cies that meet the necessary requirements of Loud, whichis why Loud is 1-1 backed by and exchangeable for thesetokens. However, having an independent token trackingbalances within the context of Audius comes with someunique benefits, including maintaining a common unitof account, portability between potential future scalingsolutions, and allowing for earners of Loud token to earnvoting power in the protocol over time.

Audius tokens exist to align governance and serviceprovider incentives with financial incentives to increaseprotocol usage and create long-term protocol value. Par-ticipation in governance, as well as operating a serviceprovider, allows an Audius token staker to earn a shareof the revenue aggregated by the network fee pool, incen-tivizing Audius token stakers to increase protocol usage.

The Audius token also exists to secure the protocol;as has been articulated by others [11], using a nativetoken to secure a staking protocol makes certain typesof attacks much more difficult to execute. To carry outa 51% attack against Audius staking protocols (gover-nance, arbitration, or future functionality dependent onstaking), one would need to acquire control of 51% ofthe supply of outstanding Audius tokens. It would bedifficult to acquire such a substantial share without dra-matically affecting the public market price or creatingan opportunity for the Audius community to intervene.However, if staking in Audius were done with a token likeEthereum (ETH), only a small percentage of the over-all ETH supply would be staked in Audius. This wouldmake it easier to attack the protocol by either acquiringand staking enough ETH to overwhelm the total stakedin Audius or staking an existing large ETH position inAudius.

3 AudSP: A decentralized stor-age protocol

Files shared through the Audius protocol must be highlyavailable, independently verifiable, and decentralized.These principles are key to ensuring democratic partici-pation and accessibility for all users of the Audius proto-col. Artists sharing their tracks and metadata, listenersretrieving content, and service providers will all sharelonger-form information via this protocol, while refer-ences to files in this protocol will reside in the Audiusblockchain. Additionally, the storage protocol must pro-

7

vide an equivalent user experience to existing central-ized solutions and scale effectively as network demandincreases.

To that end, we propose AudSP: a decentralized stor-age solution for the Audius network built on IPFS (In-terPlanetary File System. IPFS enables modular object-level encryption, global distribution capability, securecontent addressing, and object immutability [12, § 3.5.4].In order to encourage high availability for files storedthrough the Audius protocol, AudSP will provide an in-centive structure for users to host network content.

File references and associated metadata stored in theAudius blockchain will be IPLD links [13]. As the de-centralized storage market matures, the Audius protocolmay be extended to include other storage solutions suchas FileCoin [14], Sia [15], or Swarm [16].

3.1 Content services

Content services are nodes in the Audius network whichserve files in response to listener requests. The price offetching a segment of a given quality will be defined atthe protocol level, and can be modified via the gover-nance protocol.

In order to be paid via the Audius network, a contentservice’s IPFS Node ID multihash and wallet addressmust be registered on the Audius blockchain. To re-quest a given segment, a listener client must first identifyan appropriate content service by querying which IPFSnodes have pinned the segment and cross-referencing thisset of nodes with the list of known content services. Theclient would then submit a request to the IPFS node forthe segment along with the required payment.

3.2 Availability

The creator’s node, detailed further in Section 11.1, willensure that one copy of the creator’s content and meta-data is always available by permanently pinning [12,§ 3.5.3] it. Content services have an incentive to pinfiles that are being listened to frequently, as they earnrevenue for streaming that content. Once a listener hasstreamed a given track segment, their client can also pinand stream that content to others to earn Loud tokens,acting as a content service itself. These mechanismsshould mean that as a track becomes popular, its replica-tion factor will increase, commensurately increasing itsavailability.

4 Track upload and management

The track upload and management protocol for Audiuscomprises:

• A consistent audio content and metadata formatspecification to ensure accessibility (similar to theOMI metadata spec [17, § 3.7.1-3.7.2])

• A decentralized process for creators to control:

– Track content

– Revenue splits

– Content ownership structure

To share a track on Audius, creators must (1) agreeto the Audius open license (this license will be publishedin a separate brief), and (2) bond a fixed Loud tokenamount, denoted BU . This bond is used to incentivizeverifiers to analyze and arbitrate on the track, and re-mains bonded unless a track is delisted (either by a suc-cessful arbitration claim or at the creator’s election). Ifthe creator delists their content, their upload bond isaggregated into the network fee pool.

The creator’s client will then (1) slice the track intofixed-length segments, (2) encrypt them locally, and (3)upload these encrypted segments, the encryption key,and required metadata to their creator node, an always-on service operated by the creator (see Section 11.1 formore details). The creator node will then share the con-tent and metadata on AudSP, producing an IPLD linkfor the metadata which the creator client will add to theAudius blockchain via a new transaction.

Track {

owner_address

map(creatorId => ownership)

metadataIPLD

... other metadata ...

}

Where the linked metadata could be a JSON file struc-tured along these lines:

{

"trackTitle": "...",

"segmentIpldLinks": ["...", "...", ...],

... other metadata ...

}

The creator can then modify track content/metadataby sharing the modified content to IPFS and updatingthe metadata IPLD link in the Audius blockchain.

4.1 Proxy re-encryption

The cryptosystem used to encrypt tracks will allow theissuance of listener-specific proxy re-encryption keys de-rived from the track encryption key and the listener’spublic key. The creator’s node will handle key requestsand issue new keys when valid payment for a track is

8

Contentservice

Listener

Encryptedcontent

Creatornode

Proxyre-encryption

key

Figure 4: Listener track unlock process

made, issuing a new key by mixing the track encryptionkey with the listener’s wallet’s public key.

After fetching encrypted content and a re-encryptionkey, the listener client would locally decrypt the contentusing their wallet private key as follows:

proxied = reencrypt(encrypted_content,

reencryption_key)

plaintext = decrypt(proxied,

wallet_privkey)

This decrypts a given piece of content by locally re-encrypting it using the aforementioned key and subse-quently decrypting it with the user’s own private key.There is no 3rd-party proxy, but proxy re-encryptionapplied in this way allows everyone to share the sameencrypted content while users can only decrypt the con-tent on a case-by-case basis. Potential cryptosystems,including AFGH [18], are still being evaluated at thistime. More details on the specific cryptosystem chosenwill be published at a later date.

4.2 Revenue escrow

Track earnings will be escrowed for a grace period of TUE

days after upload, after which they will be disbursed tocreators in real-time as payments are made by listeners.TUE will be set at a later date, and will be modifiableusing the Audius governance protocol.

This grace period gives potential claimants time tofile arbitration claims to challenge ownership or estab-lish a revenue sharing structure in the case of deriva-tive content, with escrowed earnings being split or redi-rected according to the outcomes of these cases. Thisdisincentivizes fraudulent upload behavior. If no arbi-tration case has been filed, after TUE days have elapsedthe escrowed earnings will be disbursed to the originaluploader and their designated rightsholders. If a claimhas been filed, earnings will remain escrowed until the

dispute is resolved. At any point after the first TUE

days have elapsed, if an arbitration case is opened todispute rights associated with a track, earnings for thattrack will stop being paid to existing rightsholders andbe escrowed until the resolution of the case.

5 Payments and revenue sharing

In accordance with the Audius project philosophies, thesystem for listener payments and revenue sharing shouldbe:

1. Transparent for all parties involved

2. Cost- and time- efficient for all transactions

3. Flexible, accounting for multiple listening modelsand different listener behavior

4. Granular, with users paying each other directly andimmediately for services rendered when possible

Listener clients accessing Audius can pay creators viatwo methods: pay-per-stream and subscription. A per-centage of each payment, denoted PF , is captured by thenetwork fee pool, as detailed in Section 2.1. In addition,listener clients are responsible for paying content servicesand discovery services directly for services they consumeon a per-request basis; these fees are not included in asubscription.

5.1 Pay-per-stream, ad-supported, andsubscription models

The initial pay-per-stream model will have a fixed costper track listen. Pay-per-stream listening could be paidfor by the listener or be ad-supported, with the clientmaking payments on behalf of the listener as the listenerviews ads. This would make usage free for the listener ifthey choose.

The subscription model will have a fixed cost permonth, and listens would be logged in a similar fashionto the pay per stream model, but the listener would notmake a payment for each listen. On a recurring basis,subscription listens would be tallied and payouts wouldbe made to artists by a transparent, auditable subscrip-tion system running on the Audius blockchain.

Payment is enforced by the encryption scheme usedon shared content. A listener can retrieve an encryptedsegment from decentralized storage, but must make arequest and payment to the creator’s node to generate aproxy re-encryption key to unlock the content. Furtherdetail on creator nodes is available in Section 11.1.

This model will likely be modified over time as moreprotocol usage data is gathered.

9

5.2 Revenue sharing

All creator revenue is earned in Loud tokens and paidvia the creator revenue sharing system on the Audiusblockchain. This system executes any required revenueescrowing and splits revenue between the content cre-ators and content curators. Curators earn revenue on atrack listen if the track was discovered through the cura-tor’s repost or playlist. This attribution process wouldwork similarly to online referral codes—a listener clientwould self-report the curators that facilitated a track lis-ten.

6 Discovery

In order for a listener to discover content on the network,Audius needs a mechanism for indexing metadata that isefficiently queryable by users. Based on the philosophiesof the Audius project, this index must be:

• Decentralized

• Efficient and straightforward for user clients to con-sume (promoting accessibility)

• Provably correct and transparent, eliminating profitincentives to manipulate the results returned tousers

• Extensible, so that the Audius community can ex-plore different ranking and searching methodologies.

These requirements rule out the most decentralizedoptions due to usability and efficiency issues, e.g. usersreplicating the Audius blockchain locally and queryingtheir local dataset. This section outlines a protocol for aclass of discovery services to form, serving this functionin a way that meets the above requirements.

Discovery service providers earn revenue by:

• Designing new discovery API interfaces that othersuse

• Providing a discovery service for clients to consume,indexing the Audius blockchain in compliance witha specific discovery API interface

Discovery services are read-only. Clients can use themto fetch a listener’s feed, a playlist, song and creatormetadata, search the corpus of Audius entities, and ex-ecute other queries about the network. Anyone can reg-ister a discovery service if they meet the requirementsoutlined in this section.

Clients pay discovery services a flat rate of Loud to-kens per request, denoted FD, and a percentage of thispayment is consumed by the network (PF ) by the mech-anism described in Section 2.

Clients

Chooseinterface

Interfaces

Registercompliance

with interface

Discoveryservices

Figure 5: Discovery API interface registration and usage

6.1 Discovery API interfaces

Audius will produce a first-party discovery API interface,but other community members are encouraged to authortheir own interfaces that extend or modify the core API.The protocol allows listeners to select any discovery APIinterface.

A service provider can register a new interface by pro-viding the required metadata and bonding a set numberof tokens, denoted BDV . They then earn a flat percent-age of all revenue earned by discovery services using theirinterface (denoted PDV ), creating an incentive for APIinterface authors to lobby clients and users to use theirinterface. Providers can delist their interface at any timeto withdraw their initially bonded tokens.

An API interface must index new blocks from the Au-dius blockchain atomically (i.e. all-or-nothing), and allAPI methods must be deterministic. Because of theserequirements, for a given block hash, all discovery ser-vices running a given API interface will produce identicalresults for the same query. This consistency guaranteeis essential for the penalty mechanism described in Sec-tion 7.3.

10

6.2 Discovery services

To operate a discovery service, a service provider muststake at least a set number of Audius tokens, denotedBDP . In addition, they must register which discov-ery API interface they are operating, geographic coor-dinates, and one or more endpoints for reaching theirdiscovery service. A service provider can request to delisttheir discovery service to unlock the initially staked to-kens. If a service provider’s staked token balance de-clines below BDP , they are automatically delisted andtheir remaining balance of tokens is refunded.

Listener clients are expected to prefer discovery ser-vices with the fastest response times for their queries,incentivizing discovery service providers to provision in-frastructure in high population density areas. Clientscould automatically discover which discovery service pro-vides them the lowest latency, using physical proximityand size of stake as hints. There is little incentive forservice providers to misreport their service’s location aslistener clients will de-prioritize services with poor re-sponse latencies.

6.3 Enforcing accurate results

Every response a discovery service returns is signed withthe private key that was used to stake the original tokens,the block hash of the block they have incorporated upto that point, the wallet address of the querier, and theAPI interface they are using to generate results. Blocksare indexed atomically and API methods are determinis-tic, meaning that every discovery service should produceidentical results for the same query, block hash, API in-terface, and wallet address. If a discovery service pro-duces invalid or inaccurate results, the signed result doc-ument returned by the service is a self-contained proofthat the given service produced the given set of results.

Anyone can open an arbitration case with a discoveryservice’s invalid signed result document by filing a claimand bonding a set number of Audius tokens for the du-ration of the case (denoted BAD). A valid claim con-firming invalid discovery results earns the claimant BAD

tokens in addition to a refund of their initial bond. Ar-bitrators in the case earn and split BAD tokens, and theservice provider loses 2BAD tokens from their bondedbalance to fund these rewards. If the claim is invalid,the claimant loses their original bond which is used tocompensate arbitrators. Over time, we foresee a classof users emerging who use automated tools to query andfind discovery API services who are producing inaccurateresults, earning revenue.

7 Arbitration

Disputes may arise in Audius around who owns whatcontent, whether a revenue split should be modified (forderivative content or other reasons), and enforcing hon-est behavior of service providers and track uploaders.Audius will have a network of neutral third party arbitra-tors voting on the outcomes of these cases to efficientlyresolve disputes within the community. This protocolis designed to find consensus around disputes, resolvingthem in an efficient and decentralized manner.

We’re considering a few 3rd party options for imple-menting the Audius arbitration system, but here we de-scribe the mechanics for claims to be lodged and resolvedin Audius irrespective of implementation.

7.1 Case types

For each case type (Table 2), a very clear and objectiveset of decision making guidelines will be published forall arbitrators to follow as a guide. A copy of theseguidelines will be included in a contract on the network,and updates to these guidelines flow through the Audiusgovernance protocol. A full fee and bond schedule forarbitration will be published closer to the time of theAudius main network launch, and these fees and bondscan be modified in the Audius governance protocol.

7.2 Arbitrators

Anyone can register themselves as an arbitrator by stak-ing at least BA Audius tokens in the arbitration system.If their balance ever falls below this minimum amount,they are automatically delisted and their remaining bal-ance of tokens is refunded.

7.3 Arbitration process

7.3.1 Case initiation

An arbitration case would be started by filling a claimwith the arbitration system, including which type of caseit is, all required supporting information (different typesof cases require different data), and a fee or bond ofAudius or Loud tokens depending on the type of case.

7.3.2 Arbitration committee

The system will randomly choose NAi initial arbitratorsfor each case; the odds of a given arbitrator being chosenare directly proportional to the number of Audius tokensthey staked in the arbitration system. The current num-ber of arbitrators evaluating a case is denoted NA. Thechosen arbitrators would then have 48 hours to submita cryptographic hash of their response to the case. If

11

Arbitrator pool

Arbitrationcommittee#(NA − n)

> 0.6NA

2/3Majority

affir-mative

Resultspublished

Affectedparticipants

Appeal

24hours

Claim

4B

48hours

Claim

B Bond

Claimant

Claimresolution

Arbitrationresolution

Arbitrationresolution

Discard

NA = NAi

NA = 4N

n =∑

responses

Yes, claimupheld

Yes

No

No

No

n = 0

Figure 6: Arbitration protocol

12

Table 2: Arbitration case types

Case type Claimant Outcometype

Supporting data Arbitration fee

Requesting outright own-ership of percentage (upto 100%) of revenue gen-erated by track due toreal-world ownership ofrights

Creator /rightsholder

Binary Link to copyright or otherproof of ownership insome jurisdiction, sybil-resistant proof of identity(i.e. claimant is person incopyright filing)

FAO Loud tokens (fee)

Requesting addition of arevenue split for a trackthat is derived froma track owned by theclaimant

Creator % claim torevenue ofderivativetrack

ID of original song inAudius (which claimantmust own rights to), ID ofderivative song

FAR Loud tokens (fee)

Accuracy of discoveryservice results

Serviceprovider

Binary Inaccurate response (in-cluding signature of serviceprovider)

BAD Audius tokens(bonded for case du-ration, returned if claimsuccessful)

Track content is invalidor does not comply withprotocol

Serviceprovider

Binary Track ID BU Loud tokens (bondedfor case duration, re-turned if claim success-ful)

they do not respond, a penalty is deducted from theirstaked balance and added to the arbitration fee for thecase. The responses are hashed to prevent other arbitra-tors from changing their response based on preexistingresponses.

Creator nodes are required to supply proxy re-encryption keys to arbitrators chosen to participate inarbitration of a case that includes their tracks for free.If they do not provide these keys in a timely fashion, thearbitration case is automatically resolved in favor of theclaimant.

Each arbitration case will have its own decentral-ized environment to facilitate conversation and enableconsensus-driven decision-making. We envision thiscomprising a chat thread, timestamped comments, andownership attribution or sample annotation for relevantcase types. There is already a global community of mu-sic enthusiasts annotating tracks for their own enjoy-ment [19], and we hope to empower them to earn revenueand notoriety for doing this on Audius. This unpermis-sioned forum will help arbitrators make better decisionsand also provide an onramp for all others to register asformal arbitrators.

7.3.3 Vote tallying

After the 48 hours has elapsed, if fewer than 60% ofarbitrators respond, a second round of arbitration for

another 48 hours begins with an additional NA − n ran-domly selected arbitrators, where n is the number whoreplied in the first round. Subsequent rounds of arbi-tration will continue until at least 0.6NA replies are ag-gregated. A penalty is levied against the staked balanceof chosen arbitrators who fail to respond in the 48-hourwindow.

After the 1 or more rounds of arbitration are com-pleted, there is a 12 hour “reveal” phase where each ar-bitrator reveals the preimage response data used to gen-erate their earlier published hash. If they do not reveala valid preimage, a penalty is levied against the arbitra-tor’s staked tokens to be added to the arbitration fee forthe case, and the arbitrator is removed from the results.

The arbitration system then tallies the validated re-sponses. There is a 24-hour grace period following thecomputation of results during which any network partic-ipant affected by the decision can appeal it; this processis described further below. After this grace period ex-pires, any necessary actions are automatically carried out(ex. changing ownership amounts in accordance with theoutcome).

7.3.4 Case outcomes

For binary outcome case types, a supermajority (2/3)voting affirmatively wins the case for the claimant. Ifan affirmative supermajority is not reached, the case is

13

dismissed and the claimant’s bond is lost.If any supermajority (affirmative or negative) is found,

arbitrators in the minority have a small fee levied againsttheir staked balance which is added to the arbitration fee.Those in the majority split the arbitration fee equally, i.e.if there are n arbitrators in the majority each gets 1/nof the arbitration fee as compensation for their services.

For the % claim to revenue case type, the mean andstandard deviation of the arbitrator responses are com-puted. If the mean is below a minimum threshold per-centage, the assigned revenue share split is 0 (no change).Otherwise, the mean is the final percentage split of rev-enue, and that split is added for the claimant, dilutingdown the revenue share of all existing participants. Moreconcretely:

Let M be the number of rightsholders. Let Pm be thepercentage revenue share assigned to rightsholder m. Ifa new rightsholder is assigned percentage PM+1, eachPm is updated as follows:

Pm′ = (1− PM+1)Pm

with PM+1 being added to the distribution. The re-sulting distributions of percentages will be consistent,because:

Proof. Assuming the initial distribution is consistent(the percentages add to 100%),

∑m(Pm) = 1. We must

prove that∑

m(Pm′) +PM+1 = 1 to prove that the newdistribution is consistent. Expanding the summationwith the above definition of Pm′ , we arrive at:∑

m

((1− PM+1)Pm) + PM+1 = 1

We can simplify the summation as follows:

(1− PM+1)∑m

(Pm) + PM+1 = 1

And substitute the value of∑

m(Pm) given our assump-tion above:

(1− PM+1) + PM+1 = 1

Simplifying:1 = 1

If an arbitrator is more than a certain number (NSD)of standard deviations away from the mean, a small feeis levied against their staked balance which is added tothe arbitration fee. Those within one standard deviationof the mean split the arbitration fee equally: if there aren arbitrators near the mean each gets 1/n of arbitrationfee as compensation for their services.

7.3.5 Appeal process

During the aforementioned 24-hour grace period after adecision has been made on a given case, any networkparticipant affected by the outcome of that decision canfile an appeal. The filer of this appeal must pay a feethat is quadruple the fee paid for the decision they areappealing, and the number of arbitrators elected to par-ticipate in that decision (NA) is commensurately quadru-pled, making their expected earnings equal. The samecase can be appealed multiple times, by the same or dif-fering parties, but the cost of an appeal will eventuallybecome too great to continue.

7.4 Future improvements

As arbitration of certain tasks is automated over time,such as automated determination of revenue splits forderivative content, this same mechanism can work witharbitrators running software to make decisions on theirbehalf instead of submitting decisions manually. The ar-bitration fees would decrease, time provided for an arbi-trator to respond to a given case would decrease, and thetolerances for deviation from the network mean would belower, but the same consensus mechanism will be used toensure service providers are actually doing the necessarycomputations.

8 Governance

As stated in the introduction, the mission of Audius is tocreate a fully decentralized community of artists, serviceproviders, and listeners collaborating to share and de-fend the world’s music. Integral to achieving this missionis a decentralized governance protocol, whereby artists,service providers, and listeners are individually and col-lectively enfranchised in decision making about protocolchanges and upgrades. The Audius governance proto-col, in accordance with this mission, is guided by a fewhigh-level philosophies:

• Stakeholders should be enfranchised in decisionsthat affect them

• Voting power should be earned by creating value inAudius, not bought

• Participation in governance creates value in Audius,and should be rewarded

• High-stakes decisions should require more consen-sus, while lower-stakes decisions should be more ef-ficient to make

• Power should be shared equitably among Audiusstakeholder groups

Protocol upgrades are submitted as structured pro-posals, including deployed code when necessary, to an

14

overarching governance system that has custody over allother systems that make up the Audius blockchain. Pro-posals also include a block count at which point they gointo effect; this effectiveness date must be at least 1 weekin the future at time of proposal submission to give usersample time to review and vote on the proposal.

To submit a proposal, a user must bond a set num-ber of Audius tokens (denoted BGP ) in the governancesystem, which remain bonded for the duration of theirproposal. Before a proposal’s effective date, the origi-nal submitter can also choose to withdraw the proposalif they so choose, returning their bonded tokens. Thisbond is required as an anti-spam measure and to ensurethat proposers to have a sufficient stake in the Audiusprotocol to make changes to it. At the proposal’s res-olution (successful, failed, or withdrawn), the bond isreturned to proposal submitter.

We’re considering a few 3rd party options for imple-menting the Audius governance system, but here we de-scribe the mechanics for how it would work irrespectiveof the choice of implementation.

8.1 Direct voting

Before the effectiveness date of a proposal, Audius userscan submit a binary yes or no vote on it. The magnitudeof a vote on any given proposal is determined based onthe magnitude of the voter’s membership in governancedecision-making classes and the voting power assignedto those classes, in line with the philosophy that votingpower should be earned (Table 3).

These user classes are not mutually exclusive. There-fore, if a user has earnings and/or holdings that fall intomultiple classes, their vote can be counted in multipleclasses.

At the moment the proposal is scheduled to go into ef-fect, votes are tallied in each decision maker class, scaledbased on the respective governance power and voter par-ticipation for a given class, and summed to produce ag-gregated vote counts for the affirmative or negative op-tions.

8.2 Tallying the results of a vote

The distribution of governance power, defined G, is di-vided into percentages GL, GC , and GP for listeners,creators, and service providers respectively, and mustadd to 100%. Votes in each class are tallied per Table 3for affirmative (yes), negative (no), or abstain (no vote),with every vote being assigned to one of these categories.Consistent with the philosophy of equal power divisionbetween user groups, GL, GC , and GP will all be 1/3.

Given affirmative vote counts YL, YC , and YP , nega-tive vote counts NL, NC , and NP , and abstaining vote

counts AL, AC , and AP for listeners, creators, and ser-vice providers respectively, we calculate the final voteoutcome as follows:

Let VQ be the percentage affirmative vote in a givenclass Q, such that:

VQ =YQ

YQ + NQ

Let RQ be the percentage participation of a given classQ; this is defined as total votes placed divided by totalpotential votes, or in mathematical terms:

RQ =YQ + NQ

YQ + NQ + AQ

The percentage affirmative vote for an entire proposal,denoted V , is defined as follows:

V =GLRLVL + GPRPVP + GCRCVC

GLRL + GPRP + GCRC

A mathematical proof of the consistency of this for-mula, as well as some example voting scenarios, is pro-vided in Section 11.2.

The proposal is automatically carried out in the casethe affirmative vote wins or withdrawn in the negativecase. V must exceed either a simple majority thresholdor a supermajority threshold depending on the decisiontype for a decision to pass (see Table 4). There is no wayto reverse a proposal; a new proposal must be submittedand approved undoing the results of the original.

At the time of the Audius main network launch, therewill be no quorum requirement for a governance proposalto be accepted. However, soon after network launch (andsuccessful acceptance of some number of governance pro-posals), a proposal will be submitted to add quorum re-quirements to each decision type, with higher percent-ages for higher-stakes decisions.

8.3 Vote delegation

To make governance more accessible to users, voting canbe delegated by anyone to other users or groups of users,such that if a user places no vote on a specific proposal,their designated delegate’s vote will be used in place oftheir own. There will be two groups created at the timeof main network launch: Audius DAO (DecentralizedAutonomous Organization) and Artist Advisory DAO.

Audius DAO will be controlled by a small group ofgeographically distributed users chosen by Audius Inc.,and decisions will be made by supermajority consensusof DAO members. This DAO will be delegated votingpower by default on service provider signup for stakedAudius tokens. However, a service provider could stilldelegate voting power to another user or group of theirchoosing.

15

Table 3: Governance decision-making classes

Decision maker class How voting power is assigned

Content creators and cura-tors

Sum of Loud tokens bonded to upload tracks, spent to curate content (create repostsor playlists), and earned via listens of listeda ownedb content or curated content

Listeners Loud tokens spent on listening activity (per-stream payments, subscriptions, etc.)

Service providers Number of Audius tokens staked for governancec or to be a service provider

aIf a piece of content is delisted by the creator, they are no longer conferred voting power for earnings of that piece of content.bIf ownership of a piece of content is transferred voluntarily or via the arbitration system, voting power for its historical revenue stream

is transferred with it.cAn Audius token holder can stake their tokens in the governance system to count them towards votes on proposals.

Table 4: Governance decision types

Decision type Consensus type

Modify fee (denoted F∗) and bond (denoted B∗) amounts Simple majority (> 1/2)

Change content upload format and metadata structure Simple majority (> 1/2)

Modify revenue sharing structure between creators and curators Supermajority (> 2/3)

Adjust Loud minting mechanics or fee percentage (PF ) Supermajority (> 2/3)

Add new governance decision type Supermajority (> 3/4)

Modify required minimum vote for quorum in governance structure Supermajority (> 3/4)

The Artist Advisory DAO would be made up of artistswho support the protocol. Members would be requiredto bond at least a given number of Audius tokens in anArtist Advisory DAO contract, which early in the net-work would be funded by artist advisory grants. Theinitial members of the DAO would be chosen by Au-dius, Inc. Current members of the DAO would voteon the admission of new members, and members of theDAO would vote on each proposal with voting poweruniformly distributed across members. On listener orcreator signup, by default their voting power will be del-egated to the Artist Advisory DAO, but this delegationcan be changed or removed at the user’s election.

Any other group of users could federate to form theirown voting DAO as well. We expect other groups toemerge to represent the interests of various stakeholderswithin the ecosystem.

8.4 Bootstrapping protocol governance

Early in the life of the Audius network, the AudiusDAO will control governance. During this bootstrap-ping phase, the Audius DAO will also have the abilityto intervene in catastrophic circumstances to fix criticalissues in the Audius blockchain code, such as issues en-abling fraud or resulting in unintended loss of Audiusor Loud tokens. Governance will be decentralized in

phases, eventually reaching the fully decentralized modeldescribed above.

At some point, the Audius DAO will be disintegrated,with users who have delegated voting power to AudiusDAO having the option to choose a new delegate or stopdelegating voting power.

9 Roadmap

Audius development will be broken into four milestones:alpha, beta, main-network launch, and decentralization.

9.1 Alpha

The first testing release of Audius will allow creatorsto share content and listeners to discover and consumecontent, using IPFS for storage and a set of smart con-tracts on a test network implementing track and creatorregistration. This will include open-source alpha imple-mentations of the following:

• discovery service

• creator client

• creator node

• listener client

16

The alpha will not include payments, Audius/Loud to-kens, AudSP, arbitration, or governance.

9.2 Beta

The Audius beta will remain on a testnet blockchainnetwork, and add initial open-source implementations ofthe following features:

• AudSP (using test tokens and a beta content ser-vice)

• Arbitration and arbitrator client (using test tokensfor staking)

• Social features

Releases after this milestone will be on a rolling basis un-til main-network launch, releasing new features as theyare built.

9.3 Main-network launch

The Audius main-network will be the first non-testingrelease of Audius. This milestone will be met when theAudius blockchain moves from a testnet implementationto operating on a live main network of the blockchainplatform it operates on. This milestone will add thefollowing to the Alpha and Beta features above:

• Audius and Loud token functionality, includingstaking of Audius in service provider protocols

• Payments for service providers, creators, and cura-tors

9.4 Full decentralization

Audius will reach its final milestone of full decentraliza-tion when the complete governance protocol has beenreleased.

10 Future work

In addition to the above, we envision potentially addingthe following features to the Audius protocol in fu-ture. All are in accordance with Audius’ philosophiesof stakeholder empowerment and transparent, democra-tized, and unmediated access.

1. A decentralized bounty economy protocol, enablingparticipants to request and complete specific tasksfor a reward

2. A decentralized and transparent ad network

3. A class of non-fungible tokens (NFTs) to enableunique, personalized, and customizable experiencesto maximize community engagement:

(a) Creator token: creators could create their owntokens with unique token economics, exclu-sive merchandising and events, crowdfundingof content creation and tokenization of contentlistens

(b) Track token: a tokenized representation of au-dio content, allowing transfer of ownership andexclusive or early access, among other cus-tomizations

(c) Event token: a tokenized representation of anevent like a tour or festival, consisting of mer-chandising and collectibles, community access,or event tickets

11 Supplemental specifications

11.1 Audius creator node specification

To share content on Audius, creators are required to runan always-online service, referred to as the creator node,to 1) service requests for proxy re-encryption keys and 2)ensure availability of their content and metadata (guar-anteeing at least 1 copy is available through AudSP). Inline with the project’s mission to create a decentralizedautonomous community, this structure gives creators au-tonomy over the dissemination of their content withoutexternal dependencies or points of failure.

11.1.1 Proxy re-encryption keys

At registration, a creator must log one or more IPaddresses and/or fully-qualified domain names wheretheir creator node can be reached to provide proxy re-encryption keys. When beginning to listen to a track, alistener’s client will make a request to the creator’s node,including a payment, for a proxy re-encryption key spe-cific to the segment. If the creator node fails to replywith a valid key, the payment is revoked.

To service this request, the creator node derives aproxy re-encryption key using the listener’s public walletkey and the private key used to encrypt the requestedtrack and returns it to the listener. Because the re-encryption key is specific to the creator, listener, andsegment, it can be transmitted insecurely or publishedwithout revealing the track contents to the greater net-work. More detail on the cryptosystem enabling this canbe found in Section 4.1.

11.1.2 Availability

The creator node is responsible for ensuring availabilityof the creator’s own content and metadata, but not for

17

Creatornode

AudSP

Listenerclients

Creatorclient

Audiusblock-chain

Shareencrypted

content andmetadataSubmit

payment &request

key

Controlsnode

Regist-ered forcreator

Registernew content

Figure 7: Creator node interactions with protocol par-ticipants

providing significant bandwidth to service requests. Op-tionally, the node can be configured to provide greaterbandwidth and earn content request fees as a content ser-vice (see Section 3.1). Metadata must be shared perma-nently by the creator node, but should only be fetched bydiscovery services when indexing the Audius blockchain.If the replication factor (number of copies on AudSP) ofa creator’s given encrypted content file is above a thresh-old, the creator node could stop sharing the file withoutdeleting the locally saved copy. The creator node wouldcontinue to monitor the Audius storage network, and ifthe replication factor drops below the required thresholdit would re-share the file.

11.1.3 Creator node uptime

Failure to keep a creator node online can result in lossof track ownership, tracks being marked as “unverified”(making them undiscoverable), and loss of revenue dur-ing downtime.

11.1.4 Delegation of creator node responsibility

The creator node service will be straightforward for acreator to set up and operate themselves (for example,Mediachain created a simple tool to help users set up

their Mediachain nodes [20]), but requires high avail-ability. We foresee a class of service providers emergingto run nodes on behalf of creators for a small recurringfee. Many creators will likely use these services to avoidhaving to run their own creator node, which may becumbersome to operate for a non-technical user.

11.2 Governance vote tallying

11.2.1 Proof of vote calculation consistency

Here we provide more rigor on the consistency of thegovernance vote tallying system.

From 8.2, we defined VQ to be the percentage af-firmative vote in a given class Q, such that: VQ =YQ/(YQ + NQ).

The negative vote count is calculated as NQ/(YQ +NQ). We can prove the affirmative and negative votein a category will always add to 100%, maintaining aconsistent distribution:

Proof.

YQ

YQ + NQ+

NQ

YQ + NQ= 1

YQ + NQ

YQ + NQ= 1

1 = 1.

Given this, it logically follows that the negative votein a category is equal to 1− VQ.

As defined in Section 8.2, RQ is the percentage par-ticipation of a given class Q:

RQ =YQ + NQ

YQ + NQ + AQ

The percentage affirmative vote for an entire proposal,denoted V , was defined as follows in Section 8.2:

V =GLRLVL + GPRPVP + GCRCVC

GLRL + GPRP + GCRC

Where the vote for each class is scaled by the par-ticipation rate and governance power of the class. Thenormalization factor (1/(GLRL + GPRP + GCRC)) en-sures the resulting distribution of votes remains consis-tent (the sum of yes and no voting percentages on a givenproposal must equal 100%).

The percentage negative vote substitutes (1− VQ) foreach vote variable above:

18

[GLRL(1− VL) + GPRP (1− VP )+

GCRC(1− VC)]×

1

GLRL + GPRP + GCRC

We can prove that the normalization factor(1/(GLRL + GPRP + GCRC)) leads to a consis-tent vote distribution in the final tally (i.e. the votestally to 100%) by adding the yes and no votes andshowing they add to 100%:

Proof.

GLRLVL + GPRPVP + GCRCVC

GLRL + GPRP + GCRC+

GLRL(1− VL) + GPRP (1− VP )

GLRL + GPRP + GCRC+

GCRC(1− VC)

GLRL + GPRP + GCRC= 1

Factoring out the common term:[(GLRLVL + GPRPVP + GCRCVC)+

(GLRL(1− VL) + GPRP (1− VP )+

GCRC(1− VC)]×1

GLRL + GPRP + GCRC= 1

Factoring out the common terms again:[GLRL(VL + (1− VL))+

GPRP (VP + (1− VP ))+

GCRC(VC + (1− VC))]×

1

GLRL + GPRP + GCRC

And simplifying further, we get:

GLRL + GPRP + GCRC

GLRL + GPRP + GCRC= 1

1 = 1.

Based on this, it logically follows that the percentagenegative vote on an entire proposal is (1− V ).

11.2.2 Example decision result calculation

To illustrate the way votes will be tallied, consider adecision with the example votes and magnitude of usermembership in given decision making classes in Table 5.

With an example power distribution of G being:

GL = GC = GP =1

3

The affirmative vote can be calculated using the for-mula above:

V =GLRLVL + GPRPVP + GCRCVC

GLRL + GPRP + GCRC

RL =YL + NL

YL + NL + AL=

(600 + 100) + 300

(600 + 100) + 300 + 50= 0.95238

RC =YC + NC

YC + NC + AC=

(10, 000 + 50, 000) + 0

(10, 000 + 50, 000) + 0 + 500= 0.99178

RP =YP + NP

YP + NP + AP=

0 + 1000

0 + 1000 + 0= 1

VL =YL

YL + NL=

600 + 100

600 + 100 + 300= 0.7

VC =YC

YC + NC=

10, 000 + 50, 000

10, 000 + 50, 000 + 0= 1

VP =YP

YP + NP=

0

1000= 0

V =(1

3× 0.95238× 0.7+

1

3× 1× 0 +

1

3× 0.99178× 1

)×(1

3× 0.95238 +

1

3× 1 +

1

3× 0.99178

)−1

V ≈ 56%

Depending on the consensus mechanism employed,this proposal may or may not pass (56% yes is a ma-jority but may not be a supermajority). Because user 5placed no vote in Table 5, their vote reduced the partic-ipation rate of creators and listeners slightly.

11.3 Social features and listener feed

Listeners can take the following actions within Audius:

• Listen to a track

• Like a track, adding it to the listeners’ own library

• Follow other listeners and creators, and receivenotifications when new original content, reposts,playlists, or comments are created by them

19

Table 5: Distribution of voters and voting power for example decision

User Vote Creation/curationearnings

Listening spend Audius tokensstaked

1 Yes 10 000 600 02 Yes 50 000 100 03 No 0 0 10004 No 0 300 05 None 500 50 0

• Create a private playlist

In addition to the above, listeners and creators willspend Loud tokens on network fees in order to take thefollowing actions that consume network resources:

• Create a publicly indexed and discoverable playlist(FSP Loud tokens)

• Repost tracks to followers (FSR Loud tokens)

• Comment on tracks, albums, reposts, playlists (FSC

Loud tokens)

All social actions within Audius are represented on theAudius blockchain, meaning users can use any client toconnect to Audius and see the same social graph. Lis-teners can also view what other listeners have been lis-tening to, as can service providers building third-partyclients. This opens up many possibilities around contentrecommendation systems and alternative client experi-ences built by members of the Audius developer commu-nity.

20

12 Glossary

Arbitrator: someone registered to vote on arbitration of disputes within Audius.

Audius blockchain: the collection of smart contracts and blockchain-based code that is used for decentralized coor-dination within the Audius protocol.

Audius protocol: the amalgamation of clients interacting with each other and with the Audius blockchain.

Audius token: the token used for value accrual in Audius. Staked by some types of service providers to operate withinthe network, and earned by arbitrators in some cases. Staking this token to provide services allows one to earn ashare of proceeds generated by the network fee pool.

AudSP: a protocol for serving and fetching data in the Audius protocol. Built on IPFS.

Content service: a service that serves encrypted audio segments to users of AudSP.

Creator: someone who creates content and shares it on Audius.

Creator client: the UI used by creators to control their creator node, view and manage earnings, and interface withthe track upload and management protocol.

Creator node: an always-on API service operated by creators to issue proxy re-encryption keys for their content.

Creator revenue sharing system: a system that executes any required escrowing of earnings and splits track revenueamong creators, rightsholders, and curators.

Curator: someone who creates reposts or playlists on Audius. They capture a share of the revenue generated by listensof content facilitated by their playlists and reposts.

Discovery interface: a version or type of the discovery service that indexes and responds to queries in a specifiedway.

Discovery service: an API service that indexes the Audius blockchain and responds to queries of that index, earninga fee for each request. Must be compliant with its specified discovery interface.

Listener client: the UI used by listeners to consume content in Audius.

Listener: someone who consumes content in Audius.

Loud token: the token used for value transfer within Audius. Used by listeners to pay for content. Earned by creators,content services, discovery services, and arbitrators in some cases. Backed by 3rd-party stablecoin(s).

Network fee pool: a system that aggregates network fees and distributes them ratably to stakers of Audius tokenson a periodic basis.

Oracle: an external service that provides real-world data (in our case price data) to a blockchain-based system.

Proxy re-encryption: An encryption scheme by which a derivative key can be used to transform data encrypted byone key into a version that can be decrypted by another key.

Rightsholder: someone who earns a share of revenue generated by a given piece of content.

Service provider: Someone or something that does work on behalf of users and the network. Operators of discoveryservices, operators of content services, arbitrators, arbitrageurs, operators of outsourced creator node services,stakers in governance, and those querying discovery services and filing claims for invalid results are all serviceproviders.

21

References

[1] Micah Singleton. This was Sony Music’s contract with Spotify. May 9, 2015. url: https://bit.ly/audius-sony-spotify (visited on 08/28/2018).

[2] Jason B Bazinet, Mark May, Kota Ezawa, Thomas A Singlehurst, Jim Suva, and Alicia Yap. Putting the BandBack Together. Remastering the World of Music. White paper. Citi GPS: Global Perspectives & Solutions, Aug.2018. url: https://bit.ly/audius-remastering-music (visited on 08/28/2018).

[3] Sam Mamudi. NFL lockout ends as players OK deal with owners. July 25, 2011. url: https : / / bit . ly /audius-nfl-lockout (visited on 08/28/2018).

[4] David Aldridge. NBA, NBPA reach tentative seven-year CBA agreement. Dec. 14, 2018. url: https://bit.ly/audius-nba (visited on 08/28/2018).

[5] Dani Deahl and Casey Newton. How SoundCloud’s broken business model drove artists away. July 21, 2017.url: https://bit.ly/audius-soundcloud-model (visited on 08/28/2018).

[6] Josh Constine. SoundCloud sinks as leaks say layoffs buy little time. July 12, 2017. url: https://bit.ly/audius-soundcloud-layoffs (visited on 08/28/2018).

[7] Sharding FAQs. Ethereum. 2018. url: https://bit.ly/audius-ethereum-sharding (visited on 09/14/2018).

[8] Dai Token. MakerDAO. 2019. url: https://makerdao.com/en/dai/ (visited on 03/31/2019).

[9] Introducing USD Coin—A stablecoin brought to you by Circle and Coinbase. Centre. 2019. url: https://www.centre.io/usdc (visited on 03/31/2019).

[10] TrueUSD—The only regulated, exchange-independent stablecoin backed 1-for-1 with US Dollars. Trust Token.2019. url: https://www.trusttoken.com/trueusd/ (visited on 03/31/2019).

[11] Why do staking protocols need their own tokens? 2019. url: https://twitter.com/richardchen39/status/1087419994344894464 (visited on 03/31/2019).

[12] Juan Benet. IPFS—Content Addressed, Versioned, P2P File System (Draft 3). 2014. url: https://bit.ly/audius-ipfs (visited on 08/28/2018).

[13] IPLD Specifications. Protocol Labs. 2017. url: https://bit.ly/audius-ipld (visited on 08/28/2018).

[14] Filecoin: A Decentralized Storage Network. Protocol Labs. 2017. url: https://bit.ly/audius- filecoin(visited on 08/28/2018).

[15] David Vorick. How to Put Data on the Sia Network. Nebulous, Inc. 2017. url: https://bit.ly/audius-sia(visited on 08/28/2018).

[16] What is swarm? Ethersphere. 2017. url: https://bit.ly/audius-swarm (visited on 08/28/2018).

[17] OMI Requirements Documentation Minimum Viable Interoperability 1.0. Specifications documentation. July 26,2017. url: https://bit.ly/audius-open-music-initiative (visited on 08/28/2018).

[18] Giuseppe Ateniese, Kevin Fu, Matthew Green, and Susan Hohenberger. “Improved Proxy Re-EncryptionSchemes with Applications to Secure Distributed Storage”. In: Proceedings of the 12th Annual Network andDistributed System Security Symposium (NDSS). 2005. url: https://bit.ly/audius-proxy-re-encryption(visited on 08/28/2018).

[19] The WhoSampled App. WhoSampled.com Limited. 2018. url: https://bit.ly/audius-whosampled (visitedon 09/02/2018).

[20] Using Mediachain Deploy. Mediachain. 2018. url: https : / / bit . ly / audius - mediachain (visited on09/02/2018).

22