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 https://treetrunk.io/
I support and sponsor this proposal. @VanArman
supporting this proposal too
What happens next?
Post must be at least 20 characters have you tried the 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.
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
@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…
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.