Comparison to ERC-998

In this section we discuss the key similarities and differences between ERC-998 and Capsule NFTs.

ERC-998

ERC-998 tokens can be separated into two distinct categories: top-down composables, and bottom-up composables. A top-down composable is an ERC-721 token with additional functionality for owning other ERC-721 tokens, or ERC-20 tokens. A bottom-up composable can be either an ERC-721 or an ERC-20 token with functionality for being owned by an ERC-721 token.

In theory, ERC-998s allow for implemented internal tokens to be transferred in and out. In practice, the more tokens and methods an ERC-998 compatible token supports, the bigger the contract becomes. This can quickly reach a point where the token surpasses the 24KB maximum contract size limit, and becomes undeployable.

EIP-998 is a draft, and does not yet have a leading implementation for developer use. It is rarely used, complex, and updates to its supporting protocols have been few and far between. It has also not been officially audited. Implementing EIP-998 requires a tremendous amount of research, code-writing, and testing.

Links

The creator of the standard has no further plans to further improve the ERC-998 proposal.

A discussion in the OpenZeppelin contracts Github repository on why the addition of a standard ERC-998 implementation would make little sense.

CapsuleNFT vs. ERC-998

The Capsule Protocol simplifies the process by giving users dependable, optimized methods to interact with tokens.

Developers and NFT creators utilizing the Capsule Protocol need only to call one method to create a unique Capsule NFT contract for themselves, and these Capsule NFTs natively support all Capsule NFT holding methods - which do not require extra token specification and implementation.

In addition, the entirety of Capsule’s ecosystem is upgradable at no cost to the user, meaning it could evolve to support other tokens, or anything else the community desires. For example: a new Capsule NFT minting method would be automatically supported by any existing Capsule Collection.

The Capsule Protocol is the simpler, clearer, and more flexible way to go about NFT composability. Capsule NFTs fixate on security, ease-of-use, and upgradability. Whether you are an aspiring NFT creator, or a hardcore developer, the Capsule Protocol is designed to bring users more secure, efficient, and robust solutions than implementing your own ERC-998 token standard.

Security

Unlike the unproven ERC-998 standard, the Capsule Protocol has undergone a thorough audit by Quantstamp, with the results viewable here.

Examples

Here are some examples where using the Capsule Ecosystem trumps the ERC-998 standard:

Anyone

• Anyone, lacking knowledge of Solidity/testing frameworks/web3, wants to create a composable NFT Collection

• Anyone, lacking knowledge of Solidity/web3/React/HTML, wants to allow other users to mint from their collection without building an frontend

• Anyone, lacking knowledge of existing token types, wants to create a flexible solution for himself/his users to mint different types of composable NFTs from his collection

• Anyone, interested in the improvements built atop of the Capsule Protocol, creates a Collection to leverage the additional usecases of Capsule NFTs

• Anyone using the ERC-998 standard, realizing all-too-late their collection needed more flexibility in token-storing types, needing to redeploy their entire ecosystem

• Anyone, interested in the composability of Capsule NFTs (placing Capsule NFTs within another) without additional hassle, implementation, and testing.

• Anyone, interested in the protocol level NFT additions (private/public, lockable, tokenURIOwner) that Capsule NFTs have, without building, verifying, and testing their own code

Developers

• A developer who appreciates the ease, lack of maintenance, and flexibility in outsourcing composability to a secure (see audit results here), upgradable outlet

• A developer who wants to build an ecosystem focused on a specific application of composable NFTs, rather than the generation of them

• A developer interested in building a ticketing/redemption application which requires the provable burning of the composable after usage

• A developer who seeks financial benefit in adding onto the Capsule ecosystem, allowing users to create different variations of Capsules, claiming additional fees.

• A developer who seeks to monetize his own NFT Collection atop the Capsule ecosystem

• A developer who seeks to build public, composable NFT Collections, potentially limiting minters of his NFT Collection to certain holders (NFT holders, wBTC holders, specific addresses, etc.)