I have a few comments on metaplex, the batteries-included go-to solution for everything NFT related out-of-the-box, that I wanted to share with the world.

These are mostly thoughts I had when dealing with metaplex during the lifetime of a few projects, from the perspective of someone who just joined the Solana ecosystem.

About myself: I worked on a few production projects on Solana, am sometimes active on the Solana discord #developer-support channel to help newcomers out, and currently work on other (NFT related) projects. The following points are my thoughts and experience from building projects in this space.

Instructions (often) unclear

When you arrive in Solana land and want to do anything NFT related, chances are that you end up on the metaplex GitHub repo, or documentation at https://docs.metaplex.com/.

Coming from Ethereum, we have the ERC721 standard that dictates a handful of functions a smart contract has to implement to be considered ERC721 compliant.

In solana there are no smart contracts like in Ethereum, instead we’re dealing with pRoGRaMs. Tokens are also not handled by an individual ERC20/ERC721 contract per token, but by the central spl-token program. In fact, each token on Solana is owned by the spl-token program (spl stands for Solana Program Library).

After clicking around you might land on this page describing a metadata standard on Solana. Okay so far so good, but how do you actually use it? What is the address of this metadata program that you’re supposed to use? How does the function call look like to register metadata to something? Don’t know.

There is a metadata overview docs page available at https://docs.metaplex.com/overviews/metadata_overview but at the time of writing is still empty.

After a bit more of digging and wrapping my head around it, I found the metadata program address defined in the lib.rs file of the program itself:


Why is such a crucial bit of information not easier to find?

Then there is a single spl-token-metadata crate available on crates.io that you might want to use to submit metadata from your onchain rust programs, but after banging my head against it for literal hours and trying to get it working, it turned out this isn’t an official package and has a bug that makes it impossible to submit metadata - whoops. (Thanks for the kind folks over at #developer-support that helped me debug this)

The issue I have is that for something that wants to be the standard of something like NFTs on the entire chain, the experience can’t be frustrating but has to be as welcoming and easy to use as possible. Right now, from a newcomers perspective, figuring out how to simply add metadata for a token is incredibly frustrating. (Nowadays there is a JS SDK available that has functions to create metadata, but try to figure that out without initial guidance)

When dealing with other metaplex components such as candymachine (a program to sell mints of a NFT collection) we are running into a similar situation - the official documentation available here is missing half it’s pages* and instead of giving a technical overview of how it works, relies on commands to copy. If something isn’t working, which it often doesn’t, people flock into the discord to ask questions because they aren’t able to debug it themselves.

Instead of official documentation guidance, people relied on blog posts by other people that explain how the candymachine is working and how to set one up properly.

*/EDIT: in the time it took me to finish this post, the documentation has been updated and has more pages now. Thanks!

That brings me to my next point

Copy & Pasting encouraged over thinking and understanding

While dealing with metaplex, be it the metadata program, candymachine or other components, it became very apparent to me that the creators of metaplex had envisioned one very specific way of dealing with their projects.

Candymachine, fair-launch and other tools have a very specific way to set them up that they want users to copy and paste, rather than trying to understand and reason with. Of course being friendly to non-technical people is good, but this doesn’t teach users (technical and non-technical alike) how things are actually working, but instead encourages to stop thinking and follow guides. When technical people (like myself) try to understand and reason with the programs, we run into more road blocks due to lack of documentation, code quality and resources available.

In tech, copy-pasting and using big blobs of programs without attempts to understand them is usually a bad idea, especially when money flow and your business depends on it. If anything breaks you need to be able to reason with the program and figure out what is wrong.

When using metaplex like the creators intended to, so following candymachine instructions step by step with the provided CLI, and submit NFT metadata through candymachine itself, then everything works fine (unless you run any of the small issue resulting in one of the many crypto errors that have no reply on github). But when you try to use them individually, such as only using the metadata program without any of the master edition stuff, or candymachine components without the CLI, things can get fuzzy. (I still don’t know if it’s okay to remove the minting authority from a token that needs metadata - https://github.com/metaplex-foundation/metaplex/issues/279)

One example is IPFS. Candymachine supports IPFS, but only through Infura instead of allowing to actually use IPFS p2p. Without paying for Infura it is not even possible to create a candymachine with 10 mints without running into rate limitations and constant retries (I had to find the code and add a blocking sleep for things to go smooth). Of course when using arweave, like the creators wanted it to be used with, everything works fine. It’s also what 80% of the candymachine projects use because the instructions use that as default, often without understanding what arweave actually is.

Of course biased tools are completely fine, but my problem is more the messaging that everyone in Solana is supposed to be using this otherwise you’ll have a “bad time”. There are occasionally even people that don’t want to deal with you if you created your own minting onchain program and don’t use candymachine.

And that’s a shame because…

Candymachine is centralized and heavily botted

I mentioned above that in Solana, the spl-token program is kind of a central program (like the system program) that handles one thing - tokens.

For a system program I think that’s fair, but candymachine (and metadata but that’s not that big of an issue) are following the same pattern and trying to be the centralized thing that your application or dApp is talking to. Imagine it a little bit like having a “NFT sale server” and to buy an NFT you make a request like this (imaginary example):

POST candymachine.com/buy
	candymachineID: "abc123",

The candymachine program manages all candymachines. This program can also be upgraded at will (upgrade authority has not been revoked - https://explorer.solana.com/address/cndyAnrLdpjq1Ssp1z8xxDsB8dxe7u4HL5Nxi2K5WXZ by it’s creators and functionality can be changed without prior notice).

Being a central program, it is very trivial to see the transactions from other projects to setup a new NFT mint. It usually goes like this (pseudocode):

POST candymachine/setup-machine
POST candymachine/add-mint project1 1 "My Mint #1"
POST candymachine/add-mint project2 2 "Another Mint #2"
POST candymachine/add-mint project2 5 "Another Mint #5"

Once you monitor the onchain program you can very easily extract all available NFTs including their mint order from any project that uses candymachine. This sparked a huge amount of botters that take advantage of this, to either snipe rare NFTs, buy-out huge amounts of NFTs or in some cases even accidentally buying all available NFTs.

In other words: If you are a NFT buyer on Solana, you have almost no chance to mint a rare one. Bots know ahead of time if a mint is rare, and will be faster than you buying it.

To combat this, projects are now creating multiple candymachines with some fake ones, just to confuse botters.

If, however, candymachine was setup to be a program that you fork, adjust and deploy yourself, it would be a different story because botters would be unable to figure the program address ahead of time and thus can’t bot it (let alone knowing what input is needed to submit a mint transaction).

I see no reason that candymachine should be a central program. A strength of blockchains is decentralization so let’s take more advantage of it instead of relying on central entities that aren’t immutable.

Wrapping up

I sound critical and grumpy, but it’s good that there is so much NFT adoption happening on Solana. Candymachine being this easy to setup is certainly a reason why we have a huuuge amount of new projects popping up every day (although some with very low quality).

I hope the Solana foundation can pickup the Metadata standard or make an official one, and I hope that candymachinev2 will solve some of the issues I mentioned above. Or even better: Make something slim that people can fork, modify and deploy themselves, that would be nice!