On Natnerds

How it went down + next steps

7 min readMar 10, 2024

Intro

Let me take you back what exactly happened and share details how it went wrong, cause some of you seem to think I just released stuff without thinking it through or even discussing it with The Block Runner Guys (TBR).

Yes, I am the one that eventually did the deployment so am responsible for why it went wrong, but here’s an overview of how it went down and I’ll highlight a few moments in time where this could’ve been catched.
I’m not trying to blame anyone else, but want to share information and I hope this prevents a future deployment from going wrong.

If you know me from the crypto space you know I care for transparency and will try to make this right. ✌️

History

Since summer last year I was working on my (back then generative) art project. I didn’t have a name yet, but was working on building a complete SVG from several elements since those are properly scalable. Natcats for example mixes HTML with SVG so aren’t scalable properly from scratch.

As many of you know I made the Natcats viewer to explore how they did traits that were tied to block data (the NAT way). When I saw this I felt like this was how my art collection should be released, cause this was so cool!!

Preparation

Fast forward to the beginning of March, I was preparing my collection for UNAT (Unique Non-Arbitrary Token) and asked TBR if I could use a pattern for field “0” (block hash). They told me they’re only indexing field “11” (bits field) rn so if I wanted to be “in the mix” I should use that.

👉 this was the first time where the element name could’ve been prevented, but we simply didn’t talk about that “minor” detail

Ok so I had to use the bits field. I had explored some data (also read this article https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/digital-elements/.element-registry) and came up with “cc” cause there were 10,080 block numbers that had “cc” in the bits field (11.element). Since 10,080 is a multiple of 2016 (epoch) this pattern occured 5 times in the history of bitcoin (Natcats uses “3b” which occured 4 times which makes the total supply 8064).

I also looked into the art ascpect cause Natcats (and NAT token itself) had added art at a later point in time (aka a reinscribe on the deployment sat). More info here https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/resources/guides/how-to-convert-your-nat-deployment-into-a-unat-reinscription-guide

Then I asked TBR guys on X if this would be the way to deploy my collection:

👉 this was the second time where the element name could’ve been prevented

So I went ahead and was working on the NatNerds viewer script so I could inscribe it upfront. This eventually worked cause the images were shown on mscribe (although the collection being invalid).

I noted for myself that I had to do these steps for the deployment and asked a few friends what they thought about it.

👉 this was the third time where the element name could’ve been prevented

The uniqueness of the pattern field (in other word a new name) wasn’t clear as even my friends had different opinions reading it back.

imo it just makes sense for name.pattern.field.element to be valid if unique as it would as a text string too

Deployment itself + mints

One of my friends said “after deployment lets first check luminex string to make sure its showing correct blocks and supply”. He insisted a few times to wait for Luminex before announcing it.

First time

second time

So yes we decided to wait for Luminex to detect and confirm the deployment was valid (cause they generate a page if so). Luminex detected it and showed the list of mints with block numbers so I thought we were good to go and I posted it on X, this link: https://luminex.io/ordinals/mint?search=dmt-natnerds-7b51b31023c713362a7a820a2e228a8857c5524bc28b4537860ed7f19703eae4i0

Luminex seems to have updated their detection mechanism after this because now they’re showing “valid deployment not found”. Here’s two screenshots however showing the mint process on that night:

👉 this was the fourth time where the element name could’ve been prevented, and the most important one!!

The mint itself was a great success, they were all gone in a 10 blocks (832745–832755). I truly appreciate everyone who minted!!! 🙏

Debacle

Then user “BolognaSlacks” replied to me on Discord asking “Is this a valid deployment”? and then the bubble burst, the deployment ended up being invalid because I used a wrong element (“natnerds.cc.11.element”). There already was a “corn.cc.11.element” so apparently that invalidated it.

When reading this I could cry, because of all the time I had put in to shape the collection but especially for all the people who minted some nerds.

I edited the “mint tweet” so people couldn’t find the block numbers and the luminex link anymore so trying to save what could be saved (cause yes I care about you). I also explicitly tweeted “stop minting”.

I then immediately tried to contact TBR asking how this could be fixed and if I could “reinscribe” the deployment on the same sat with the correct element (the same way you can update the viewer script by providing a different “id”, see here https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/resources/guides/how-to-convert-your-nat-deployment-into-a-unat-reinscription-guide).

Their reply however:

reinscribing your deployment pointing to the valid element will not correct your issue. This is a purely indexing problem, it would create too many indexing consistency issues if this were to occur.

So I couldn’t use this method to fix the deployment. We agreed on speaking about this later as they were offering to find a solution (which I truly appreciate, they’re very cooperative 👌). Since they’re very busy guys and have a lot going on and also are in a different time zone it’s not easy to just talk about this every day fwiw.

So I eventually went to bed cause I couldn’t fix anything at the time and was tired af cause it already was getting quite late (like 1:30 am over here). I had a rough night, didn’t sleep much and was sweating, had nightmares etc etc (not that you care probably but fwiw)

A second natnerds?

When I woke up I learned someone else (user mitoshi on X) deployed another collection (with the same ticker) using a different element. It ended up having 2016 mints (1 epoch) despite I told everyone to stop minting.
He didn’t reach out if he should do this, went on with it and then acted like he tried to save the day. He even sent me the deployment so I could “take it from there” 🤷‍♂️

Conclusion

Let me reiterate that I’m not trying to blame anyone in this article if it sounded like that. I truly appreciate everyone reaching out trying to help!! 🙏

We confirmed on Luminex. It showed the blocks available to mint. You’ve seen the screenshots where we waited to confirm on Luminex so we made sure no one would get destroyed.

Next steps

After discussions with The Blockrunner Guys (Iman and Will) and also Benny, we have a potential solution.

The good news: there will be a new collection and the current holders (which means if you originally minted a “original valid block” or bought a valid natnerd of the original 10k on secondary) will be able to claim (we’ll call this “whitelist”). It will be 10,080 claim spots in total (which matches the original supply). And of course it will maintain original art and traits.

The “not so good” news: the whitelist claim for a new deployment is being build by The Blockrunner Guys and Trac. We will keep you updated on this development! Until then we have to wait.

We also briefly spoke about the “mitoshi 2k” mint but that won’t be part of the new collection, cause it simply won’t work (because it uses a different (2b) element).