MAYC还有一些M1、M2和Mega的药水还没有变异，这样就存在有些变异猴是开盒，还些变异猴还未开盒的情况。首先要明确的是，所有20000只变异猴都是已经做出来的，而不是用药水去变异时才实时生成的，只是项目方对Metadata做了控制，让未变异的猴子的Metadata没有对外公开而已。

大家都知道，ERC721的元数据是通过tokenURI方法获取的，我们以前几天刚开的Mega变异猴30005为例，可以看到它的元数据URI是

https://boredapeyachtclub.com/api/mutants/30005

获取到的json如下

{"image":"ipfs://QmcCMYfyDfTQs3ZFsu9rv436gJKskzu5uabKQJukZPzhEC","attributes":[{"trait_type":"Name","value":"Mega Trippy"}]}

里面的图片用brave浏览器打开就是对应的Trippy变异猴

那么，有些人就会用30006去尝试下能不能看到下一个未开盒的Mega变异猴的样子

结果返回token不存在。

因为在这里项目方用是中心化的API来返回json元数据的，所以很好对这个开盒的私密性进行控制。以上面的30005变异猴的mint为例，看下对应的tx交易0xef0c7af927424fc8416fc62315c18ff4ea93306eb1a467f062b2af608b75de3a的日志

可以看到from参数是全0地址，表示新mint；to参数是token接收地址，也就是mint用户的地址；tokenId就是当前mint出来的tokenId。项目方应该在中心化那里做了一个event监听服务，监听到此事件时，根据tokenId将图片上传IPFS，然后API Metadata reveal。

那么，有人会说，项目方是不是可以人工操控30006的开盒图片呢？答案是：不能。因为MAYC合约部署时已经公开了图片哈希provenance码，在合约里可见

string public constant MAYC_PROVENANCE = "ca7151cc436da0dc3a3d662694f8c9da5ae39a7355fabaafc00e6aa580927175";

因此，所有20000张变异猴的图片顺序在合约部署前都排好了，只是未mint出来的还没有公开元数据。从这小小的技术点就可以看出项目方在技术上是有用心的。