Collections Revenue Flow
This page gives a detailed overview of how revenue flows for collections (playlists and albums) on SHARE Protocol.
Last updated
This page gives a detailed overview of how revenue flows for collections (playlists and albums) on SHARE Protocol.
Last updated
Collections on SHARE are designed for multiple tracks to be grouped together and sold at a price you choose and with built in revenue sharing. One challenge with this goal is that collections often contain complex splits setups, for example different tracks inside of an album may have different split percentages apportioned to different stakeholders.
SHARE solves this challenge with the following system:
The creator of the collection can set whatever price they choose, and that price must be equal to or higher than the price of any track in the collection. This means if you have an album with 3 songs that each cost $2.00, the album price can be any amount greater than or equal to $2.00.
The difference between the collection price and the song price is kept by the collection creator. This means if a song costs $2.00 and is included in a $5.00 collection, the creator of the collection receives the $3.00 surplus. On every purchase, a track in the collection receives a payment corresponding to its full price. This means stakeholders within that song get paid based on the price of the song, not the total price of the collection.
Payments are distributed to all stakeholders over time and not all at once on a per transaction basis. This means as the stream of purchases happen, the protocol is selecting the next set of payees to receive their portion of payments. This process is essential for efficiency and the ability to pay out shareholders in as close to realtime as possible.
In the diagram above 3 songs with different prices and different splits setups are included in a single $5.00 collection. The maximum price of any song in the collection is $2.00, meaning the creator of the collection should expect to receive the ~$3.00 surplus on each purchase. This is a reward for curating and creating the collection. That said, you can opt out of this surplus by setting the collection price to the same value as the individual song prices.
The payer (e.g. the buyer of the collection), is charged $0.72 in processing fees bringing their total cost to $5.72. SHARE collects a %5 fee resulting in $0.25 being paid to the protocol. $5 then flows to the collection smart contract. The collection smart contract identifies which song is next in line to be paid out, in this case, SONG 1 which has a price of $1.98. The $3.02 surplus flows to the creator of the collection.
Next, the $1.98 flows to the song smart contract. The song contract for SONG 1has a setup with the following splits:
Payee 1
50%
Payee 2
15%
Payee 3 (also the collection creator)
35%
For the $1.98 payment, payee 1 should expect to receive $0.99. Payee 2 should expect to receive $0.29. Payee 3 should expect to receive $0.69. Since payee 3 is also the creator of the collection, this brings the total revenue earned by payee 3 on this transaction to $3.71. Note that the system is designed to distribute revenues to payees correctly over a sequence of transactions, and whether or not the full payment is delivered in a single transaction depends on the price of the asset and the number of splits. For example, splitting very small payments (less than a dollar) is less efficient than splitting larger ones (upwards of $5.00), among large groups of stakeholders. Therefore, not all collection splits will behave exactly as in this scenario, but the fundamentals are the same.
Below we can see the exact sequence of payments on the Base blockchain with USDC:
You now have a fundamental understanding of how revenue flow and splits work for collections on SHARE Protocol. Thank you!
The full transaction can be viewed here: A more detailed view of the revenue flow can be seen by tapping the All Transfers option, as opposed to Net Transfers:
