Protocol ReviewLens Protocol 🌿
Lens is a decentralized social graph protocol created by the AAVE team. The purpose of the protocol is to empower creators to own the links in the social graph that connects them with their community. Lens allows accounts to create and follow profiles, publish and collect posts, and much more, focusing on the economics of social interactions. The protocol is EVM compatible and is still in development (see Github). A version of it has been deployed to the Polygon Mumbai testnet. Nomenclature:A...
Protocol ReviewBridging to Optimism
During times of high congestion, Ethereum can price out even its most enthusiastic users. We’ve seen this happen many times – quite recently with the Yuga Labs NFT drop, where some users paid thousands of dollars for a single transaction. There is an immediate need for scaling solutions for Ethereum that don’t compromise on its security guarantees. Optimism is one such solution. It makes transacting with Ethereum assets more affordable by constructing a separate “layer 2” blockchain where tra...
Protocol Review0xSplits
Introduction0xSplits is a trustless protocol for splitting on-chain income. The protocol takes the form of a “hyperstructure”—a permissionless piece of infrastructure that distributes value to all users, operates at gas cost, and persists as long as the underlying blockchain reaches consensus. The smart contracts have been deployed to Ethereum mainnet and independently audited by Shipyard. The core components of the income-splitting mechanism are Splits and Recipients. A Split is a payable sm...
A DAO that provides accessible, technical reviews of decentralized protocols.
Protocol ReviewLens Protocol 🌿
Lens is a decentralized social graph protocol created by the AAVE team. The purpose of the protocol is to empower creators to own the links in the social graph that connects them with their community. Lens allows accounts to create and follow profiles, publish and collect posts, and much more, focusing on the economics of social interactions. The protocol is EVM compatible and is still in development (see Github). A version of it has been deployed to the Polygon Mumbai testnet. Nomenclature:A...
Protocol ReviewBridging to Optimism
During times of high congestion, Ethereum can price out even its most enthusiastic users. We’ve seen this happen many times – quite recently with the Yuga Labs NFT drop, where some users paid thousands of dollars for a single transaction. There is an immediate need for scaling solutions for Ethereum that don’t compromise on its security guarantees. Optimism is one such solution. It makes transacting with Ethereum assets more affordable by constructing a separate “layer 2” blockchain where tra...
Protocol Review0xSplits
Introduction0xSplits is a trustless protocol for splitting on-chain income. The protocol takes the form of a “hyperstructure”—a permissionless piece of infrastructure that distributes value to all users, operates at gas cost, and persists as long as the underlying blockchain reaches consensus. The smart contracts have been deployed to Ethereum mainnet and independently audited by Shipyard. The core components of the income-splitting mechanism are Splits and Recipients. A Split is a payable sm...
Share Dialog
Share Dialog
A DAO that provides accessible, technical reviews of decentralized protocols.
Subscribe to Protocol Review
Subscribe to Protocol Review
<100 subscribers
<100 subscribers
NFT marketplace Foundation recently launched Collections — a way for artists to mint groups of NFTs on their own smart contracts.
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.
https://twitter.com/saturnial/status/1466198872875667460?s=20
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.
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.
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.
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.
Owner capabilities:
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
Operator capabilities:
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.
References:
NFT marketplace Foundation recently launched Collections — a way for artists to mint groups of NFTs on their own smart contracts.
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.
https://twitter.com/saturnial/status/1466198872875667460?s=20
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.
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.
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.
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.
Owner capabilities:
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
Operator capabilities:
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.
References:
No activity yet