Crypto Composables ERC-998 — Update 3: First Contact
I’ll talk about setting up the “NFTy Magicians” community, what was discussed on the first “Composables Call” and some thoughts on creating a standard interface for Composable Non-Fungible Tokens (CNFTs).
Background and Recap (skip if you’re hip):
First Contact
After attending EDCON in Toronto and networking primarily NFT in NYC, I was encouraged by James Pitts of the Ethereum Foundation to setup up a Discord and Discourse. The purpose is to move some of the token standards discussions from the Ethereum Magicians discourse into a broader community. Ethereum Magicians is primarily concerned with core Ethereum code base improvements and while standard interfaces for tokens are great to have, there’s not enough bandwidth for everything in one forum sometimes. That is why I launched NFTy Magicians, a community based on NFT ideas, projects, use cases, discussion, implementation, interfaces and standards. 👍
NFTy Magicians — a Discord and Discourse Community
Everyone that has joined the Discord channel has been incredibly enthusiastic and helpful. I would like to thank everyone for their time and energy. 🙏
A place to discuss standard interface proposals like ERC-998 CNFTs is essential since there’s a lot going on in the NFT space right now. A great summary by 0xcert team about why NFTs matter can be found here. Standards not meant to serve a small subset of projects or developers, but the whole community. Discussion is crucial to arriving at the best possible solution. A thorough deliberation of finer points related to composability of digital scarce assets is a necessary step toward an abstraction that has objective and logical consensus for most people. Think of community driven development like qualitative research that is discussed, codified and abstracted into roughly quantitative results. It’s really quite elegant. Thank you James Pitts for encouraging me to start this process.
First Call — ERC-998 CNFTs
We had an amazing first call on Tuesday, May 29th, 2018 and I’d like to recap some of the high level points that were made:
- Standard events needed? Yes. Tabled till interface is complete;
- Fire callback or event when NFT is removed from CNFT? Callback;
- Approval needed for other contracts to add / remove, to / from CNFT;
- Sub-tree operations in CNFT. Dynamic Programming solutions? Tabled;
- Nomenclature: NFTs -> parent / child; FTs -> balances; Consensus;
- Continue to explore ways to interop with Composable Registries;
It was a tremendously productive call with lots of great minds and voices in attendance. It helped to clarify where I should spend my time in coding the sample implementation and how others can help out as well. I’ll unpack these points a bit more here.
Standard events are of course going to be needed to listen and log events related to composables, but for all other NFT events the ERC-721 events will suffice. CNFT specific events would be something like:
event ChildAdded(uint256 _tokenId, uint256 childTokenId, ...)
event ChildRemoved(uint256 _tokenId, uint256 childTokenId, ...)So you would know the parent NFT token ID and the child token ID in this instance. Perhaps we would also pass along the contract address of the child token; it would be assumed that you’d know the contract address firing the event (the parent).
For context, we have already approved a callback when adding children or balances to CNFTs, in order to restrict the composition of … composables. In point (2) we debated whether or not we could avoid a callback when an NFT or portion of token balance is removed from a CNFT, and if an event would suffice. The point was made by Maciej Górski and myself that the “stickiness” of certain items is important in some instances. Therefore a callback is necessary. Here’s what that might look like:
removeChild(..., uint256 childTokenId, ...) {
...
require(childToken.isRemovableFromParent(this, childTokenId));
...
}We also decided quite quickly that we need an approval process for composables to approve the sending and receiving of children or balances that is initiated by other smart contracts. This came out of a use case Maciej Górski had when he was busy WINNING @ ETH Buenos Aires. Brilliant!
We’re all a bit concerned about deep nesting of composables and the complexity to “decompose” these assets. This would require multiple transfers or some scheme to make this work. I mentioned a dynamic programming technique of adding the root address of the tree as an approved sending of each sub-tree, but the bookkeeping may be too cumbersome. Tabled.
Nomenclature was more fun than I thought. We’ve got this interesting situation where NFTs can own NFTs or FTs, or both. So how do you name the child items and balances and also avoid namespace issues when dealing with multiple inheritance… Hmmm… So we stared at the Composite pattern a bit:
Alright, so the parent/child thing definitely works for NFTs owning other NFTs because each NFT is like a unique instance of an object in OOP software terminology. But what about balances of an ERC-20? We’ll have to revert to using the same terminology as the ERC-20 spec. Consensus achieved!
Lastly, it’s important to everyone creating Crypto Composables to not create extra bloat, gas costs or implementation headaches for end users / developers. And once again Maciej Górski from Userfeeds.io has created a Composable registry for all projects and even existing ERC-721s to use. I think this is a great way to get the benefits of composability without having to deploy a CNFT. However, people are people and there will be projects that want to have final say in all the contracts they deploy, especially if it’s integral to how their token economy functions. My goal with ERC-998 is to create the interface that is standard for how you interact with a CNFT, registry or not. I believe these two approaches can be supported in the future.
Thanks to everyone on the call:
Alexandra933
Chentschel
Dafky2000
Jimbobbins
Jwaup
Flynn
Maeste
Mattlock
Mino
Moskalyk
Mg6maciej | Userfeeds
Nathalie-ckc
Tdng
Trung | Axie Infinity
Goals Goals GOOOOOOOOALS!
My goal has never been to hand down an interface for CNFTs as though it were the 10 commandments and expect every project Dapp and wallet to implement it. Amazingly, I don’t have my own project for CNFTs and am not involved with any at the moment. So, I look to the energy and enthusiasm of the community for the answers to what we should build and why. My end goal for CNFTs is not to be the one to kick this across the finish line. The community needs to do this as a team.
The kindness of the Ethereum Foundation members who took the time to guide me and the community that is now behind building standard interfaces and token building blocks is incredible. I get a lot of energy from the blockchain and token engineering space already; giving back by providing a space for others to catch that wave as well was an easy decision.
YOU TOO can help support a groundswell of standard interfaces, tokens and interoperability for decentralized applications. All you need to do is start.
Come join us on Discord 🧙
For a more formal discussion on standards, interfaces and implementations, join our Discourse @ nftymagicians.org 🧙
Keep in touch, stay closed for modification and stay open for extension… 😉
medium.com/@mattdlockyer
twitter.com/mattdlockyer
linkedin.com/in/mattlockyer
