Revenue and Royalty splits for collaborations V0

Author Bård Ionson
Status Temp Check
Type Contract & interface changes
Implementor I do not know
Sponsor(s) @VanArman
Temperature Check Poll Discord
Created Date 01/23/2022
RARE tokens held at date of creation 248,682.9213
  • Title - Revenue and Royalty splits for collaborations
  • Preamble - Author: Bård Ionson, Status: Draft, Type: Contract Interface Improvement, Sponsor: Bård Ionson, Created Date: 01/23/2022, Link to poll:
  • Summary - SuperRare has been known for epic collaborations but we would like a way to split revenue and royalties between artists
  • Abstract - As an artist I would like to be able to have a smart contract that will spit revenue for sales and royalties so that I do not have to manage spreadsheets of information and watch for sales of NFTs on other artists accounts. Also so I do not have to calculate splits based on quick moving market conditions. I assume a new contract would have to be created to do this work. Perhaps it can be implemented as other platforms have with a collaborator contract that the artist pays gas fees for.
  • Motivation - Artists who collaborate are now doing collaborations on other platforms. SuperRare has had some very good collaborations the elevated the platform and the artists involved. It would save artists time and keep them on SuperRare.
  • Specification - I hate to dictate a technical solution. Perhaps the artists could create a collaboration split entry on a contract for splits. They would add the splits to the rules of that contract. Then they would mint under that contract which would tie into the main SR contract somehow. The interface would get a new option to create a collaboration and an option when minting to add that collaboration to the NFT. It might cause you to have to change all of your contracts. Or perhaps you could make it a feature of the new individual series contracts. The new series contracts seem to have more flexibility and OpenSea recognizes the royalties on those. The database would have to change to support an NFT having multiple artists. Search engine would have to change so art shows up under both artists. Leaderboard changes to calculate dollar amounts of sales.
  • Benefits - Keeping collaborations on SuperRare, making it easier for artists to coordinate, minimizing disagreements and likelihood of lawsuits due to disagreements between artists
  • Drawbacks - Cost of generating a new contract, might not work with existing SR contracts, it might cost too much in gas every time a royalty needs to be paid out
  • Outcomes - Do a survey of the current art pieces to determine how many are collaborations. If collaboration splitting is added track if the number of collaborations goes up. Survey other platforms that have collaboration spits and see if the artists who are on both SR and other platforms start using SR for collaborations. Put up a webpage that tracks these things. Make a dune analytics dashboard that captures the monitoring of this data.

I think the linear increase in gas based on the number of recipients would be tough. A pull payment based solution would solve that though.


I do not know enough about how the contracts work and the relationship to transactions. Other platforms have the option. I assume they pass the transaction gas fee on to the collector. What if royalties were put on to an L2 network like Matic?

Correct, gas fees would be on the collector (still not great IMO). An L2 solution would work as long as it allows L1 calls to contracts on L2. The downside is needing to bridge it back which costs a bridge and L1 claim transactions, and the potential wait time depending on what L2 is picked. Overall though I think it’s doable.

I think a pull based system seems reasonable. I think theoretically there would be no limit to the number of collaborators in that case. Might be worth exploring both implementations and analyzing the trade offs.


Agreed, there’s def some trade off that should be compared. Setting each party to receive a piece of the royalty still comes with some cost.

What if everything that would be claimed by a user was part of the same claim? Thinking of collector royalties here but also anticipate in the future that there will be more things we want to do that fall into this category of tx.

Claims from splits, royalties, rewards, airdrops, etc… would then stack up until it’s sufficient to justify the cost– combining the source of claims would in theory help it stack up quicker, and not have to pay for multiple transactions to claim from many different services.

If we use L1 then something with off-chain computation would be the most efficient (similar to collector royalties). Maybe this works more with a hybrid L2 solution. Making it solely L1 and on chain it gets tough to accumulate all of them, it would require telling the single claim user A gets X, user B gets Y which at that point might as well send out the funds rather than updating the contract to increase each individual user’s pending balance.

Check these guys out. They are trying to solve this issue

I support and sponsor this proposal. @VanArman

1 Like

supporting this proposal too

1 Like

What happens next?
Post must be at least 20 characters have you tried the :heart: button?


As a business consultant who specializes in strategic partnerships, collaboration is the key element of my business strategy. I’ve been investing in this space for first hand experience, aka educational purposes. I was quite unpleasantly surprised to learn how difficult it really is to split payments, which is why I have been keeping my eye on the pulse. I am NOT a developer, not even close. My technical expertise is little to none, but I do understand business and workflow. I feel like the best solution to this would be to funnel all payments to 1 central wallet, like a crypto escrow. From there the contract can be split accordingly to every entity/stakeholder. The most interesting thing I have read lately, which seems like it would streamline this is the ZORA protocol. Enter ZORA V3 – ZORA ZINE This article may help, but pay close attention to the MODULE part as well. Because SuperRare is a DAO (which I am not a member, but trying to get into Spaces #Plywood Protest #superrare-2-0 ) this could very possibly make a whole lot of sense to incorporate.

I’m going some research into potential smart contract solutions. Once we have something that makes sense we can update the proposal with the technical solution and get some eyes on the code.


Agreed that having an escrow makes sense. I think it allows for more collaborators.

1 Like

A true collab option for artists is long overdue. Having trustless distribution of royalties and initial payment are huge for the artists who collab together. Also having both names listed in a more official manner is a much better look for collabs done on SR. I currently always mint collabs on other platforms since SR does not do this within the contract.


Thank you @Curator for sharing this link. It is the 2nd time in 2 days Tree Trunk was mentioned. A close colleague in the music industry told me to get familiar with what they are doing and I had almost forgotten. It’s very interesting but I have lots of questions. I joined their Discord and will absolutely be digging in. Have you looked into Zora Protocol? If not, start here Zora V3 I feel like if these 2 entities joined forces, they would get to where they are trying to go much faster. I can’t help it, my brain just goes to collab every time :slight_smile:

@DubG Thanks, I will check out Zora V3 and tell their team. I am of the same mind, always down to collab

Just chiming in here to state that this proposal cannot really be deemed complete until it has a more robust specification. Eventually the community should have the literal code that could achieve this functionality before it could go up for a vote - this should be a standard for all proposals that require executable code. I am loving the collaboration occurring in the thread though. The proposing Artist and the sponsoring council member seem to be in the best position to continue the conversation, solicit potential technical support from the community, etc…

1 Like

Thanks, I guess I do not understand what the DAO is responsible for. I have no idea how to implement something on the SuperRare code base. Is the community now responsible for the features in the SuperRare marketplace? What is the business model of SR?

What is the role of SuperRare Labs? I assume SR Labs has developers who can work on new features.

I thought we would vote on a proposal and then someone at SuperRare would add the feature. Perhaps this should just be a strong suggestion that SR should add this feature to remain competitive. A vote would signal that the community would like to have this feature.