Shared Collection Contract implementation

Contract Audit Squad
1

Sorry for the lack of updates from my side, but just too much work and degen grinding recently. But I’ve been on it daily for some amounts of time.

I had to explore the royalties topic from scratch to understand the space and what can be delivered and in what form. In short, there seems to be no good way for implementing enforced royalties without breaking the current “transfer” functions in ERC-721/ERC-1155 standards and losing major marketplaces support - these standards just build like that.

As of EIP-2981 - as it turns out it’s only an informative standard. So it’s not enforcing any royalties, it just provides an interface for a trader (marketplace) to fetch all the data for calculating the intended royalties. And the bad news is that this standard is not widely adopted (yet?) - e.g. OpenSea not supporting it (don’t know if they have any plans) and just doing their own system for royalties on top of ERC-721.

FYI there’s also NFT pools now. Sudoswap just became the first (?) AMM for NFTs, so you don’t need to buy/sell those with order book anymore - you just throw them into the pool and then it moves on the curve. This might get a traction for wholesale traders and they are fine to move tokens around without paying any royalties. But I guess for our local art collection it’s not an issue to worry about.

In the end, it seems like just implementing ERC-1155 and EIP-2981 seems to be the way right now, but the royalties won’t be enforced outside of the major marketplaces. I also didn’t look into what royalties schemes OpenSea supports, so I’d also need to check it out to see how it will look.
Need your feedback and thoughts on this approach and if you support it :point_up_2:

And if anyone see any of my conclusions to be incorrect - please, let me know.

5 Likes
2

Some marketplaces like LooksRare do enforce 2981 but others like OS do not even acknowledge it.

The bigger issue with a shared contract is how royalties are split. If there is no easy way to track per-nft or per-subcollection royalties then it will be difficult to allocate funds correctly to creators. If a solution or design pattern exists to address this please disregard.

It’s possible that individual creators would be ok with a proportional payout based on entire collection volume but this does introduce the issue of certain NFT series subsidizing others.

Further research is needed to see if there is a solution that addresses these issues.

5 Likes
3

I did a bit of digging and think ERC2981 does solve the per token royalty issue to a degree. It is still not supported on all markets like OS but the logic is there:

    function royaltyInfo(uint256 _tokenId, uint256 _salePrice) public view virtual override returns (address, uint256) {
        RoyaltyInfo memory royalty = _tokenRoyaltyInfo[_tokenId];

        if (royalty.receiver == address(0)) {
            royalty = _defaultRoyaltyInfo;
        }

        uint256 royaltyAmount = (_salePrice * royalty.royaltyFraction) / _feeDenominator();

        return (royalty.receiver, royaltyAmount);
    }
5 Likes
4

Thank you! That’s great.
I’ve already communicated to the Artist Panel that we’re currently just trying to make all this work for sellers and markets that respect the royalties in general and the standard itself and that’s the best we can do, so the realistic expectations are set.
The only thing that’s left to check is what OpenSea offering with royalties schemes at the moment. After that the contract can be implemented and I was going to dedicate this weekend to wrap this up.

4 Likes
5

OpenSea to my knowledge just offers proportional royalty at the collection level.

We can say 70% goes to the creator vault and 30% goes to the conclave.

We can NOT say royalties for token IDs 1-100 goes to address A and 101 - 200 goes to address B.

6 Likes
6

I was going to suggest this… have an artist vault, use the open ledger to follow the receipts and calculate what goes to each artist. It’s annoying that we can’t automate/streamline this but it will always be there on ledger and each artist can be accountable for double-checking their payouts and making sure the numbers match as I know 1/1 artist already do with verifying/checking against their royalty payouts from OS

2 Likes
7

This could likely be somewhat automated with The Graph and a bit of scripting. It is more work for payouts but having a unified collection for community art is a desirable thing.

Any contract that is written should include ERC2981 support for setting royalties at the collection and token level because I am optimistic it will be widely supported in the future. Initially this can point to the vault and if/when its useful, royalties can be configured for each token.

3 Likes
8

@Dontfeedthewolf

Very excited. Looking forward to the weekend.

2 Likes
9

Super impressed with how awesome team & community are reading through this thread.

High fives all around.

1 Like
10

Hey Tenacity, wanted to follow up on the ETA. The Artist Guild press release is ready. If you could just make sure the wallet address name is wagdieartistguild.eth that would be great.

1 Like
11

Hey.
It’s hard for me to nail a good ETA as I’m still figuring stuff out as I go due to lack of experience. I expect at least another weekend on this.

I did ERC1155 (tokens) + ERC2981 (royalties info) mash up contract and it works (will publish it for review first thing). But one thing that I realized is that ERC2981.royaltyInfo() response has only a single target address in the response. So I figured, since we want to split royalties into 3+ parts, we could use PaymentSplitter contract. FYI: that means “pull payment” model for the final beneficiaries.

So the whole flow will look like this:

  1. A sale happens on the marketplace that supports royalties (ERC2981).
  2. The marketplace asks our contract about where to send the royalties for that particular token and what is the royalties’ share is (out of the total sale amount). And since we can return only a single “receiver” address, we should be expecting deploying an unique PaymentSplitter contract for each royalties split configuration (meaning: if different artists require different royalties, then a new splitter contract needs to be deployed for each one). But we’re starting with just one configuration basically, so only one splitter needed to handle this flow.
  3. The marketplace takes it’s own ETH share.
  4. The marketplace transfers seller’s ETH share to the seller.
  5. The marketplace transfers “royaltyAmount” (ETH) to the “receiver” address for the sale that happened. :warning: I don’t think we actually discussed what should be the share of the royalties within the total sale amount - only discussed what are the artist/Panel/Conclave shares within the royalties part of the sale.
  6. From here, each of the final beneficiaries (artist, Panel, Conclave) will have to pull their share from each existing PaymentSplitter (actually, anyone can trigger these pulls, not necessary the final beneficiary themselves - can also be done by some scheduled worker). So, some tx overhead here is expected. Can be automated, but still an overhead.

Then another flow for the marketplaces that doesn’t support ERC2981, but can still transfer royalties part to one receiver (or many) - OpenSea case.

  1. The marketplace performs the sale, takes it’s share and transfers “royalties” ETH, for example, to a single “default” PaymentSplitter or a contract with customized “withdraw” methods (or just to final beneficiaries according to the our storefront’s royalties settings - as the least effort option, but can’t easily sort out shares precisely among all artists due to manual work).
  2. Our automation can track events and the exact sale amounts around the collection’s contract and then work with the contract that’s accumulating “unsorted” royalties to transfer the shares precisely.

I guess, for now we can just focus on the first flow as the first milestone and just ask people to use particular marketplaces on the rollout.
Lmk what you think.

3 Likes
12

So, that will be The Art Panel multisig, right?
What about all those domains that @KingOffling squatted? :laughing:

wagdieartists.eth
wagdiearts.eth
wagdieartist.eth
wagdieart.eth

We point those to the collection contract itself then?

1 Like
13

Lol. Would prefer wagdieartistguild.eth for sure for consistency.

RE: The update, I am 100% blockchain/tech inept. Will need others to chime in here.

1 Like
14

All of those are available.
Snagged them for this purpose.
They’re held by the CoR account.

Let me know if you’re in desire.

2 Likes
15

Right good catch. We CAN do per token royalties but CAN NOT do per token royalties with multiple payment addresses.

To streamline and reduce the cost of splitter contract creation we can look into https://docs.0xsplits.xyz or a general EIP-1167 minimal proxy setup.

0xsplits seems like a good and easy way to do this without much dev overhead and deployments cost about 100k gas or around $2-$3 currently.

3 Likes
16

Thank you! I’ll read through 0xsplits today.

2 Likes
17

Hey. I’m sorry it takes forever. Couldn’t focus on it lately, but I intend to finish this ASAP.

3 Likes
18

Just saw this on my timeline, idk if the WAG is still trying to solve the shared contract issue

@Icculus @tenacity.eth

1 Like
19

Thanks!
I think our royalties implementation and the payments splitting/pushing (with 0xsplits) are pretty much sorted out. I just need to do the minting functions, roles/collection management and put it all together, which isn’t a big amount of work. And ofc validate the whole setup with Artist Panel to make sure everything is good and as expected (and the limitations are also identified/acknowledged) - I have an idea how to do it, so they’ll hear from me soon.

2 Likes
20

@tenacity.eth Can we select a concrete date for minting with this? WAG is all ready to go.