Restrict addresses allowed to mint

[antho1404]

Currently, the tokens can be created by anyone. This is a valid use case for a public platform like rarible.com but makes the solution unsuitable for more restrictive business that wants only a certain subset of users to create new tokens.

I can see many use cases where a platform would want to limit user access:

• Admin only (basically, the platform become a single store)
• Partners only
• Invite-only user
• VIP users
• ... many more cases

OpenZeppelin already has a role-based access control that would be perfect as it became quite standard.

This should, of course, be combined with an option to have role-based access or public access.

With that, a mint function like this one for ERC1155 could use a modifier like that (really simple example):

import "@openzeppelin/contracts/access/AccessControl.sol";

contract MintAccess is AccessControl {
    bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
    bool public hasAccessControl = false;
    
    modifier minter() {
        require(!hasAccessControl || hasRole(MINTER_ROLE, msg.sender), "Caller is not a minter");
        _;
    }
}

The default would still be public, but hasAccessControl could be set to true and limit access to only users with MINTER_ROLE.

[skogard]

This is the #1 highest priority IMO, as in it should be implemented yesterday.

Based on my experience this is the #1 reason keeping all the independent NFT builders (like generative art NFTs and what not) from adopting Rarible protocol. They want to be able to control the supply, and Rarible protocol currently doesn't provide this. Simply adding this feature should act as the tipping point to bring many creators to Rarible protocol.

[ReidOutLoud]

+1 from the cocoNFT side of things as well. We originally created a collection through the Rarible UI and as we started to gain traction random people started adding NFTs to it. We had no ability to remove them from the collection and couldn't stop more from coming in. Most people don't want other people's stuff added to their collection. This will be critical for projects and developers building on the protocol.

Here's our original collection.

[insiderq]

Is this issue regarding lazy minting or the usual minting?

[ReidOutLoud]

@insiderq I believe both.

For example, the following 3 NFTs were not created by cocoNFT but they got added to our collection:

https://rarible.com/token/0xb66a603f4cfe17e3d27b87a8bfcad319856518b8:96125377743998653960494675778880041635752995411996976536756870116996571725843?tab=owners

https://rarible.com/token/0xb66a603f4cfe17e3d27b87a8bfcad319856518b8:64368353088522448742955036133310326787112359855705897450330012652471593205761?tab=owners

https://rarible.com/token/0xb66a603f4cfe17e3d27b87a8bfcad319856518b8:12529620606114914337153296827475757346887726858953420827220808269590302838819?tab=owners

[antho1404]

Yes, both definitely. The behavior should be the same for lazy mint and traditional mint.

For the traditional mint, that wouldn't be too hard to add, but for the lazy mint, that would require a change in the API and enforce the rule when the first transfer occurs.

[skogard]

but for the lazy mint, that would require a change in the API and enforce the rule when the first transfer occurs.

Does the API need to change if the API simply rejects mint requests that are invalid? This way people can just use the API the same way, but invalid messages get rejected with error messages, which the endpoint is already doing.

The API shouldn't be the thing that enforces the rule, the contract should. The contract can check the submitted sigs and the token at mintAndTransfer time and reject or accept.

But yeah I think this involves some changes in the contract code.

What if just implement a simple "Only an address in a whitelist array can mint to this contract"? That probably solves a lot of the problems. And there may be offchain solutions to implement additional features on top of this.

For this I think 2 changes need to happen for this to work for lazy mint:

1. The contract implements a whitelist, allow only the addresses in the whitelist mint to it
2. The lazy mint API at rarible.com rejects all lazy mint requests that try to mint outside of the whitelist.

[mynamebrody]

Would also be cool to explore if we can have the contract check an allowlist of some kind that is external. That way the "list" of users doesn't have to be on chain and use transactions to add each users. Ideally we only want our users to be able to upload. So it would be nice to only give those users the ability to mint.

Bad actors could still get by this if they are added to the list, they technically could still mint anything to the contract, even not using our product.

[antho1404]

I like the idea of accepting a large "external" list of users, but this would require some oracles and API normalization that would make things extremely complicated and costly.

I do have an idea that comes to mind that might be complementary and solve the issue.

Extra signature while minting.
When a user mints a token, they first need to contact your server to sign a certain payload (probably the payload for the mint), and this signature can then be sent while minting and verified on-chain.
With this solution, the contract would require to be restricted to specific minters (at least the signer from your server) and verify that the signature sent is included in the allowlist of minters.

With this solution, your server will be responsible for permitting the user to mint, which can be used to restrict only to registered users but also anything that can be done to control who can mint (anyone for a certain period of time, only the first NFT minted by a user...)

Would such a system work in your case?

[evgenynacu]

Hey guys!
Thanks for your opinion here.
My thoughts:

1. We have private token contracts in the repo, not yet used anywhere. Contracts are audited. only owner can mint there. (https://github.com/rarible/protocol-contracts/blob/master/tokens/contracts/erc-721/ERC721RaribleUser.sol for example)
2. We can change this logic add minter role there. That's useful (also, rarible.com UI can show these contracts to mint into)
3. We add custom fields to Mint message (for example, we can add signature from the backend). Also, we can add custom validator to these contracts (so this validator can validate signature).

I think, 2nd is relatively easy to implement, pretty useful and consistent with current contracts.
3rd is much more complicated + that's not very straightforward and we need more time to think about this. I think, this can be done by external team(s). (But anyway we need to add support for extra data field inside Mint message, then it's possible to implement in non-standard protocol token contract)

[chusla]

possible to start with simpler scenario if it makes sense and is a more incremental approach? that is all public or only private to original creator of collection. a true whitelist scenario probably more sophisticated and time intensive to implement. just a suggestion.

[bobwith2bees]

Is there a severity/priority status that can be set for this issue? If I were in production - this would be one of the top priorities as it is 1) is actively being exploited and 2) affects the security integrity of the NFT project. Maybe not drop everything, as there is a manual workaround to clean up items.. but really this is a problem. I would expect it to be included in a security vulnerability list (which might have a limited distribution) - since there effectively is no access control at the moment.

You could argue that this is out of spec for now, that's fine. Just understand it is a production showstopper for me. I can beta with this, but not realistic for production.

As the team/process evolves I can help you with this (how to manage bugs/customers and security vulnerabilities.)

Workaround?
Is there a manual process we can use to create a collection with just one creator? I can live with that for my first collections.

[artsyassets]

Dear Team, I just want to share our experience. This is somewhat of an emergency for us, as we're getting lots of traction. We were not aware of this and were right about to do another wave of 100 Cybergoats (our NFTs lazy minted on Rarible's token factory contract), when somebody minted some weird image and sunglasses to our collection. Our users brought it to my attention. Naturally, we didn't give our permission for this to happen, and we don't know who did it. We had to emergency stop the drop, and now we can't sell any more NFTs until this is resolved. Our immediate plan was to drop 10,000 pieces, but if anyone can just randomly mint spam to our collection and potentially impersonate us by minting NFTs that look like ours, etc., then we cannot sell any more NFTs until this is resolved. It would be a mess, and buyers would be upset. Please help, we have lots of people waiting for an answer/impatiently waiting to buy from us, and we would love to get them to use the protocol, but this is a complete blocker. Please help. @evgenynacu @eduardstal, or anyone who knows about this, is there any quick fix for this that you would recommend, at least a temporary one? Thank you for your time.

[rimb05]

I've also had random items appear in our collections. IMO, this is a serious problem and should be given high priority. Anyone using Rarible protocol is susceptible to this right now. Is there a more concrete roadmap for how this will be addressed from a protocol or contract standpoint?

Are there any known workarounds?

[antho1404]

We are starting to work on this with Liteflow. We made a proposal to fix this issue that has been accepted.
We will be working on two systems:

• Role-based permissions in the smart contract as described in the initial post
• Signature-based minting so any backend can sign a specific authorization to their users.

The goal is to have these features in the token created by the factory already in the rarible protocol. This way, any new token will have these features (that will be opt-in with public collection by default as it is right now). This should also work for any already deployed tokens from the factory.

We will be working on the development part, but the deployment will depend on the rarible team. The code will be pushed on Github and reviewed by the rarible team.

[chusla]

Hi Anthony thanks for the response that is promising as it stands this is pretty much a deal breaker for any custom collection. Aside from approval which is out of your control do you have any insight on timing of your development? We have some urgent waves of drops we've had to indefinitely postpone until this is fixed. also if there is anything the community could do to facilitate or expedite please let us know. Thanks!

[chusla]

Sorry one more question what is the degree of confidence you have around the retroactive aspect of it for existing factory collections? We have had to migrate collections once already due to the difference between old rarible.com collections and new token factory collections which continues to confuse our collectible community and would want to avoid another such migration at all costs if possible. Any thoughts or insight on that would be much appreciated. 🙏

[antho1404]

Hello @chusla, sorry for the late reply.

In terms of timeline, we have already started some work on it. The first step is to have a basic authorization that might be sufficient for your case should probably be done next week. The whole "delegated authorization" will take longer, at least another week, so we can expect a good two weeks to have everything at least ready to review by the rarible team. This does not mean it will be available at that time. Hopefully, everything will be smooth, and it can be merged and deployed quickly, but that would be out of our control.

For the level of confidence for the backward compatibility, I'm pretty confident it would be technically possible. We still need to do a lot of testing to make sure we don't break anything, and after the issue might come more from the financially possible. This will require rarible to update all the existing tokens, and that can be quite expensive #11 (reply in thread)

[eduardstal]

There is now a contract where only the owner can mint.

We will have the possibility to deploy private contracts via the SDK, this feature is in the backlog. The release can be expected Monday / Tuesday next week (first week of November)

Any collection that has already been released won't be able to benefit from this.

[rimb05]

Has this been merged yet?

[eduardstal]

It was supposed to merge today but we are unable to upgrade tokens immediately because of high gas prices and many contracts that need to be upgraded. At the moment we need about 12k$ to upgrade. We planned to upgrade today but it seems to be delayed.

It will be done as soon as gas prices come down a little.

[rimb05]

Looks like gas prices have come down a bit. Any chance of merging today?

[artsyassets]

Thank you for the hard work. We are also waiting for this. An update would be much appreciated. Gas was in the 70s last night. Is this in the mempool already? What is the number we are waiting for?

[eduardstal]

Aiming to deploy either Saturday (6th of Nov) or Monday (8th of Nov).

[artsyassets]

Excellent! Let's take this one to the moon!

[rimb05]

Thanks so much for deploying the new contracts Eugene! Can you please provide the new contract factory addresses (mainnet and rinkeby)?

[chusla]

This is awesome if true. we see a deployment on etherscan here: https://etherscan.io/address/0x3482549fca7511267c9ef7089507c0f16ea1dcc1

is this the new token factory? if so looks like we just need the contract code to be verified before we can access function calls in etherscan?

https://etherscan.io/address/0xe441aefa11e775803dd47f5e949886b71a4b312d#code

[eduardstal]

We upgraded the exchange contract on main-net, so the latest fixes about signatures should be there.

Didn't upgrade tokens yet, it's planned for this week to sort out problems with the code (Eugene was talking about this on Friday)

[chusla]

We upgraded the exchange contract on main-net, so the latest fixes about signatures should be there.

Didn't upgrade tokens yet, it's planned for this week to sort out problems with the code (Eugene was talking about this on Friday)

Ah! Got it ok thanks, got excited for a second there, ok will continue to monitor, waiting eagerly, thank you!

[basti4nos]

So does this upgrade allow users of the Rarible SDK to let only some creators mint? Is it implemented?

[NicolasMahe]

Hey guys. Pull request to implement the suggestion of this discussion created: rarible/protocol-contracts#105

[eduardstal]

@NicolasMahe There's a pending change requested here rarible/protocol-contracts#105. Just letting you know in case you missed it.

[NicolasMahe]

Thanks! Working on it.

[eduardstal]

Closing this as the PR is merged.