Collections allow artists to express a thematic relation among a group of their NFTs (just as a musician would for an album) and to describe the collection using the NFT's metadata. Collections also allow Foundation to aggregate and present data about a collection for potential buyers — such as its total sales, limits on the collection size, and floor price.
Each collection is described by a name, symbol, description, and an optional limit on the collection size.
Foundation's creators understood the implications of the feature quickly, as 228 artists deployed a collection within 24 hours (over 450 deployments at time of writing) — despite paying an Ethereum transaction fee to do so.
Previously, all of Foundation's artists minted NFTs on a single shared contract deployed by the platform. Although this made it cheaper to mint, it also meant that all artists were represented under the Foundation brand (instead of their own) on third-party marketplaces like OpenSea.
In our technical review, we explain how Collections are cheap to deploy, what the ownership and trust properties are, and generally dissect the engineering decisions that went into the most relevant features of the contracts.
Efficient Deploys: The Foundation Collection Factory
Collections are deployed via the Foundation Collection Factory. Deploying a Collection costs around 168k in Ethereum gas, which is very cheap — enabled by using OpenZeppelin's Clones library, which implements the EIP-1167 standard. Foundation also used this pattern in their Splits feature.
The goal of the standard is to deploy a minimal amount of code to Ethereum for any functionality that is intended to be used by many contracts. It achieves this by separating the contract's storage from its functionality.
The state is deployed many times as separate, minimal, identical contracts (hence called a "clone"), and the large logic contract is only deployed once. The clones simply delegate transaction calls to the logic contract, which can modify the clone's state. This delegation pattern is known as a proxy pattern.
As a result, artists on Foundation only pay for deploying a small clone that holds information about the collection (including its name and symbol) but that has the full functionality of a collection (such as minting and transferring).
A drawback of using a factory is that it makes the deployment an internal deploy call from the factory, and so some platforms might interpret the "creator" as the factory's address rather than the user's wallet. We've seen this happen on OpenSea before when using factories to deploy ERC721 contracts.
On the other hand, using a factory makes tracking collections easier (e.g. via a subgraph on The Graph Protocol), and it's easy enough to define the creator as the wallet where the transaction originated.
Additionally, an optimization could be to deploy the contract and perform the first mint in the same transaction; currently, two transactions are needed to get to the point where a token is minted.
Another thing to note: The minimal proxy standard should not be confused with "upgradable" proxies — the proxies deployed through the Foundation Collection Factory are not upgradable.
Enforced Rarity: Limiting the Number of Tokens Per Collection
Collections provide an optional way for artists to guarantee rarity in their collections — by allowing them to set a limit to the number of tokens that can be minted.
Each collection has a field maxTokenId, which defaults to zero, but can be set to a positive integer by the owner. Since each token's ID is effective an index — starting from zero and increasing once per mint — this field is used to prevent a token from being minted if its ID will be greater than the intended limit.
If the maxTokenId is never set and remains at zero, the owner can mint an unlimited number of tokens to the collection. However, once set, it can only be modified to a value that is lower than the current value. In other words, once the artist has committed to a limit for the collection's size, the collection is guaranteed never to grow beyond that limit.
Each token can have its own royalty payment address defined by the owner when minting. Royalties are set to a fixed amount of 1000 basis points (10%). The collections contract implements the royalties system defined originally by Rarible.
The royalties implementation differs from the NFT Royalty Standard defined by EIP-2981. Builders in the space will benefit if a large platform like Foundation implements the EIP royalty standard as it allows for easier interoperability. Manifold has recently written a meticulous library for marketplaces to aggregate all royalty implementations into a standard. Standardization reduces the need to use libraries that aggregate many disparate strategies in a single function as added optionality is error-prone.
Ownership and Trust Assumptions
The collections factory and logic have roles that manage different privileges.
The collections factory contract has a roles contract set to Foundation's treasury, which extends OpenZeppelin's Access Control implementation. The roles contract serves two purposes:
- It defines the admin role that has privileges such as updating the implementation of the collections contract, meaning it can update which "logic" gets deployed with the proxies
- It defines the operator roles queried from the collections contract
The collection contract implements a standard ERC-721 with two roles. An owner role that is set to the user's wallet; and an operator role that is set to a role contract specified by the factory.
- Set the maximum number of tokens that can be minted in the collection
- Update the baseURL
- Burn any tokens owned by the collection owner. Collectors cannot burn tokens.
- Mint tokens with a combination of automatically approving a specified operator (auction house, marketplace, etc) and setting a royalties recipient
- Migrate tokens from one account to another with the original token owner's permission (using signatures)
Web3 is about ownership. Foundation has taken a necessary step towards giving creators more ownership over their work and image while making it as accessible as possible through opinionated product decisions and inexpensive deployments. We like the collections.