1

I’m creating an ERC1155 contract for a marketplace. The marketplace will deploy one contract and then anyone minting an NFT via the marketplace would do so via that contract.

As such, over time this one contract could end up with millions of tokens mapped to it.

Is there a theoretical limit regarding the total amount of storage / data that a single contract can consume?

For instance, in this contract the balanceOf mapping could have millions of entries. We also have additional mappings to store meta data specific to each token minted - again, there would be millions of those.

I’m just trying to make sure that we have the right contract strategy. Any input would be hugely appreciated. Thanks!

Improve this question

1 Answer 1

Reset to default
3

At its core, ERC1155 uses a mapping to store the balances of tokens (see the code here: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/defcf20042479d995a0688bdfd019e44c9e79d76/contracts/token/ERC1155/ERC1155.sol#L24). As you can see, it uses a uint256 for both the token type and the balance that an address has, so, you would safely be able to have 115792089237316195423570985008687907853269984665640564039457584007913129639935 token types and a single address would be able to have that amount as a balance for a single token. That value is the maximum of a uint256 (see What is the maximum input value for function uint256 parameter? for a bit more context).

So long story short, if you expect to have millions of token types, you are WELL below your ceiling and your proposed approach should be more than fine.

Improve this answer
5
  • Thanks @julianwyz. That’s really helpful to know. In terms of read performance, is there anything I need to be concerned about there? Does reading a mapping with millions of items or querying events (again if there are millions) effect the read performance?
    – Benjamin Dell
    Commented Feb 8, 2022 at 6:38
  • I’m considering a minimal proxy (erc1167) approach where each marketplace listing/collection would technically have its own contract with as many tokens as it needs. Apart from this perhaps being a little neater for the listing creator (as they’d end up with their own contract vs piggybacking on a much larger and shared erc1155 contract) are there any performance, gas cost or storage limit advantages to lots of smaller proxy contracts vs 1 very large erc1155 one?
    – Benjamin Dell
    Commented Feb 8, 2022 at 6:44
  • Read performance should be no different regardless of the amount of things in the mapping. Technically speaking, when a mapping is initialized, it has every possible key mapped to the value of 0x000.. (whatever the specific datatype's representation of 0x0 is). docs.soliditylang.org/en/v0.8.11/types.html#mapping-types has some good information in it.
    – julianwyz
    Commented Feb 9, 2022 at 22:25
  • As for the contract architecture you propose, there isn't a huge difference to me at first blush. The main difference I can see is the gas involved in creating the contracts per marketplace. Contract creation is very expensive so if you aim to have this on Eth mainnet and not an L2 or something, I would watch out for the economies of that. However, depending on your vision, either solution should be okay. If it were me, I would try and use a single contract. If/when that proves to be an issue, I would look to break it out.
    – julianwyz
    Commented Feb 9, 2022 at 22:29
  • 1
    Amazing thanks @julianwyz - super helpful.
    – Benjamin Dell
    Commented Feb 11, 2022 at 17:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.