ERC721CSBT — Claimable Soulbound Tokens
- ERC721CSBT (Claimable Soulbound Tokens) are “soulbound” tokens that are claimable if you own a linked reference collection.
- Possible use cases include: allowing users to verify Twitter NFT PFPs using on-chain NFTs by creating a ERC721CSBT off-chain version that renders a PNG instead of SVG
- They can also be used for other purposes like creating optional companions that always follow the main NFT.
- Contract is verified on Etherscan and easily implementable.
Feel free to “fork” it and deploy your own implementations!
Introducing yet another experimental ERC721 token that I have created — The ERC721CSBT!
Ever since Twitter has allowed Twitter Blue, people have been able to set their PFPs on Twitter with their hexagons and verify their ownership through connecting their wallet with their Twitter account.
This is great for normal tokens, but ERC721 tokens with on-chain images and metadata, we got left in the back-burner with huge unsupported tags because Twitter currently doesn’t support on-chain NFTs.
If you bought an on-chain NFT that you thought was super cool, and looking to rock it on Twitter with your verified PFP hexagon, you will swiftly be greeted with such experience.
After that, this is the pepe-equivalent feeling that you will have.
Fear not, the ERC721CSBT is here to save your hexagon.
A simple, extremely minimalistic ERC721 that doesn’t fully act like an ERC721 nor follows standards of ERC721. (You are fully free to turn it compliant and what-not)
The concept of a SBT (Soulbound Token) is that it is attached to the user’s wallet.
The concept of a CSBT (Claimable Soulbound Token) is that it is attached to the user’s wallet until someone else claims it.
That allows us to create “claimable” SBTs that are multi-use (is not bound to a single “soul” or “wallet”) but rather follows around and is readily able to hop onto a new wallet as long as the conditions are met.
For my specific use-case, that condition was that you had to own the reference-collection token (for example, to claim an Off-Chain Anonymice, you had to own the On-Chain version of the original Anonymice)
In addition to that, if the ownership of the original Anonymice changes, the new owner will be eligible to “claim” your Off-Chain Anonymice from your wallet into theirs!
In my implementation, the ERC721CSBT was used to create Off-Chain Anonymice, which coupled with a metadata service that returns a PNG image instead of an SVG base64 (actually, my CDN reads the smart contract, grabs the SVG base64, converts it to PNG, and returns it in PNG form!) allows you to rock your on-chain PFP on Twitter with your verified hexagon.
The contract uses a storage mapping instead of proxy-reading the initial contract’s ownerOf like some of my previous implementations. Why so?
Isn’t it more gas-efficient to use the storage data of the reference contract instead?
A: Yes, it is.
Since the method is used a lot by spammers maliciously airdropping “fake” collections to people, generally this method gets spam-filtered a lot, especially on OpenSea, who I have had to contact many times to get my weird, non-conventional contracts to get non-spam-filtered because I was reusing and repurposing storage slots in such ways that is not expected or convential.
Another reason is to provide compliant Transfer events.
If we use reference-contract storage, we cannot emit accurate Transfer events where there is an initial mint, followed by transfers from owner A (previous owner) to owner B (new owner), because the only owner data that the contract can read is always the current owner. The previous-owner becomes unknown immediately when the reference-contract’s owner changes.
To be honest, I haven’t broken OpenSea or any other marketplaces with “illegal” Transfer events YET (for example, minting an NFT tokenID multiple times without burning) and more. Whenever I have time, I may experiment more to see what such things do.
So, how do I get mine?
I deployed the first ERC721CSBT for Anonymice, and my first token is 7194 (the OG 0xInuarashi Anonymice) as I think many in the community would love to have their PFPs verified on Twitter Blue.
For now, there is no front-end created yet as I basically whipped this up within a day. So for the tech-enthusiasts, Etherscan is your companion.
Simply go to Etherscan, connect the wallet that you have your Anonymice, and call the callToken method with the Anonymice ID that you want to summon.
If you ever want to burn your ERC721CSBT to get rid of it, you can call burnToken in the same way as well.
The code is a pretty stripped-down version of ERC721 which has some special ERC721CSBT compliant functions here
Once there’s a front-end set up, I’ll update this blog post with it and also share it across other platforms.
I’m planning to make the same thing for Ether Orcs next. Gogogo!
You can view the verified smart contract here:
ERC721CSBT | Address 0x955a556b4edb6ce89a476c96030f892152717c3a | Etherscan
The Contract Address 0x955a556b4edb6ce89a476c96030f892152717c3a page allows users to view the source code…
ERC721CSBT | Address 0x4f1b00d4f9ad3448a47f44dabbcdbf47836b3fc3 | Etherscan
The Contract Address 0x4f1b00d4f9ad3448a47f44dabbcdbf47836b3fc3 page allows users to view the source code…
ERC721CSBT | Address 0x0525fBd0828Bb8CEf59892277A4582504706668A | Etherscan
The Contract Address 0x0525fBd0828Bb8CEf59892277A4582504706668A page allows users to view the source code…
The metadata and image delivery are powered by my own CDN, NonFungibleCDN, which reads the on-chain data from the smart contract, converts the SVG data to PNG data, and returns it as a normal token.
Totally head-banging here in terms of writing, so please give me some feedback if this style of writing is confusing, or if it’s great! It’s much more in-tune with how my thought processes are although I think it might not be how normal people write.