Custom Fractionalizing and Naming of MoonCats
A great feature of blockchain technology is it encourages open-source development that builds upon past projects. Though just because everyone can build upon any existing project, doesn’t mean it’s a safe or useful addition. So, it’s good to peer review those as they come up. In this article I’m going to take a deeper look at two contracts that were deployed by goatishduck, adding some utility to the MoonCatRescue ecosystem.
MoonCat Fractionalizing
0x2dC60583A5CeffCDfbb830326C32c04a235231F6
This contract is a “fractionalizing” contract. The concept of a non-fungible token (compared to a fungible one) is it is distinct and cannot be divided further. At least not on its own. For any non-fungible token, its own definition means it cannot be divided further, but someone could create a completely new asset that represents a fraction of the token, and that’s what this contract is.
This contract is not a generalized contract, but keyed to a specific MoonCat: bytes5 constant CAT_ID = 0x008a384e9b. MoonCatRescue is a project that predates the ERC721 standard, so the tokens that are part of that collection follow some of the ideas that became part of that standard “NFT” mentality, but not all. One of the unique things about the original MoonCatRescue contract is the unique identifier used for each MoonCat is not an integer, but rather a five-byte data string (usually shown in hexadecimal notation). This five-byte hex ID acts like the MoonCat’s DNA in that it contains a compressed notation of all the traits that MoonCat has. Plugging “0x008a384e9b” into the ChainStation website shows some more details about that MoonCat.
The published source code for this contract identifies itself as CatToken7989, which we can see “7989” is the rescue order of the MoonCat with the hex ID of 0x008a384e9b. The contract has no “owner” recorded, and it grants no additional privileges to goatishduck as the deployer of the contract. What the contract does allow is whomever the current owner of MoonCat 7989 is, they are allowed to deposit that MoonCat into the “CatToken7989” contract, and split it into 1,000 shares (an ERC20 token, given the ticker symbol “MC7989”).
When the shares have been issued, two features become active. Firstly, if someone owns a portion of the MC7989 shares, they can give MoonCat 7989 a name. MoonCats have a unique property that they can be assigned a name by their current owner, but once a MoonCat is named, it remains that name forever. Currently MoonCat 7989 is unnamed, so the first person to collect the required shares can take that action. The required number of shares to name the MoonCat starts at 500 shares (half the total supply), and drops by one every 17,280 seconds (every 4.8 hours, resulting in dropping by 5 every calendar day). You can run the tokensRequiredForNaming function on the contract to see what the current cost is. Naming the MoonCat doesn’t destroy the MC7989 tokens the namer has.
The second feature is the MoonCat is put up for adoption by anyone in exchange for 3 ETH. Triggering buyCat with a transaction sending 3 ETH to the contract will immediately send the MoonCat over to you. When the MoonCat gets sold, a new function activates: collectPayment, which allows any address that holds MC7989 shares to redeem them for a portion of the ETH collected. Since each share is 1/1,000 the total supply, each MC7989 token is worth 0.003 ETH. The contract provides no means to change the buyout price, and no means to adjust the number of shares, so that valuation will always be the same.
The contract is re-usable (once a new owner adopts MoonCat 7989, if all the prior MC7989 shares have been redeemed, the new owner can deposit it back into the contract again and start the whole process over again), and does have proper safety checks in place to make sure the different phases of the contract’s process do happen in the right order. Being hard-coded for a specific MoonCat and for a specific buyout price means this contract won’t be re-usable for the broader MoonCat or NFT community, but as a template for how to make a custom fractionalizing contract, it’s a pretty good example. My key suggestion for future versions or derivatives of this contract is to have mintTokens as a function take a few arguments, which would allow the owner of the MoonCat to set a different buyout price and total supply for the shares token for that cycle. But then again, once this contract has been in the wild for a while, it’s possible that at least a few of the shares gets lost or stuck with an inactive user. Since the cycle cannot start over again until all the shares are redeemed, it’s likely to get stuck at that point waiting for the last few stragglers to redeem, and not be able to start over again. So, having a way to trigger the collectPayment function on behalf of a different account (essentially, paying the gas fees to convert someone else’s MC7989 tokens to ETH for them) would be a good way to clean up the end of the cycle.
MoonCat Naming
0x6103760180D12eE883b93C988D0bEbbab51f3668
This contract is a helper contract to allow for two different functionalities around naming a MoonCat. And it allows both functions without needing to take ownership of your MoonCat (non-custodial)!
Like the previous contract, this one has no “owner” recorded, and it grants no additional privileges to goatishduck as the deployer of the contract. The previous contract worked for a MoonCat from the original MoonCatRescue contract, while this contract focuses on utilities for “Acclimated” MoonCats. “Acclimated” is the in-lore term used for MoonCats that are in a wrapper contract to behave as ERC721 tokens. Because the original MoonCatRescue tokens are prior to the ERC721 standard, if an owner wants their MoonCat to interact with modern projects that only interact with tokens that adhere to the ERC721 standard, that MoonCat needs to travel to a different contract, which knows how to speak the ERC721 standard. In the NFT space this has been labeled “wrapping” as it is only a thin veneer of extra logic on top of the token, which can be “unwrapped” if the owner wishes.
MoonCats that are Acclimated don’t have a means to be named, directly. This smart contract calls itself “CatNamer”, and helps with that.
The first feature it provides is a nameMyCat function, which de-Acclimates, names, and re-Acclimates an Acclimated MoonCat in one transaction. This is only trigger-able by the owner of that Acclimated MoonCat. So it serves as a gas-savings tool to combine what would be three separate transactions into one.
The secondary feature is the CatNamer contract allows an Acclimated MoonCat owner to offer up the rights to name their MoonCat for a specific ETH cost. Owners can call the sellNamingRights function to set a price (in wei) to name their MoonCat, and they can re-call it if they wish to adjust the price later. If the owner calls sellNamingRights with a price of zero, that sets the MoonCat as not having its naming rights for sale, so it is a reversible process if the owner completely changes their mind later.
If you wish to take someone up on their offer to have their MoonCat named for a fee, call nameTheirCat with the appropriate ETH value, and their MoonCat will become named.
This contract is general purpose for all Acclimated MoonCat owners, though one downside is it requires owners give “approval for all” rights to the CatNamer contract as opposed to approval just for specific MoonCats, so if you have multiple MoonCats, you may wish to keep those you plan to sell the naming rights of in a separate wallet. The CatNamer contract doesn’t allow naming someone else’s MoonCat before a price has been set, so granting it permission to all your MoonCats is relatively safe. The thing to check before you grant it access to all your MoonCats is to make sure someone who previously owned your MoonCats didn’t set their naming rights up for sale. You can check if a price had been set by querying the price function with your MoonCat’s rescue order.
