After the genesis collection of WITCHES, we ruminated on which part of the weird wilds (the world that Crypto Coven inhabits) we wanted to build first. Since our project has always been grounded in rich storytelling, we decided to launch a introductory project as the very first location: the home of our elusive NARRATOR. With it, a series of short stories about witches of olde, told by said narrator.

The brilliant Keridwen wrote five achingly poignant stories (about which you can read more in her own post), and quickly, as our ideas often do under the wing of visionary Nyx, the project grew into one much larger and grander.

What if these stories could be minted as magical objects (what we’ve called ARTIFACTS) imbued with the memories of their erstwhile owners?

What if they weren’t just static images, but richer multimedia assets?

What if people could interact with their metadata on chain?

And, the cherry on top, what if they could be tailored to each WITCH?

Back in February, I set out to pen a series of design docs for everything we needed to build:

• A series of audiovisual NFTs to hold animated art and voice-narrated stories

• A point-and-click interface for interacting with and minting these NFTs

• A smart contract with minting gated through a server

We spent the better part of a year creating five (!!!) generative collections of multimedia NFTs, the immersive experience to bring the lore to life, and a set of contracts to stitch it all together. So here, witches, is a glimpse into it all.

The Multimedia Storytelling NFTs

Static images have largely been the dominant medium for NFTs since they’ve existed. To break out of that mold and showcase a new paradigm for what NFTs could be, we chose to explore a multimedia format.

With five short stories chronicling WITCHES of note and the desire to form them into a collection of art, we realized we could weave the two together—by turning them each into a magical object (ARTIFACT) that the subject of the story had once owned, with the narrated story as the echo of that WITCH. As Nyx put it, each ARTIFACT was like a seashell you could press against your ear to hear a faint impression of a memory.

So, then, what exactly is an ARTIFACT?

1. A work of generative art, either “attuned to” a WITCH (if you have one) or random (if you don’t). An attuned ARTIFACT reads from the metadata of the WITCH who minted it and generates its own appearance to match.

2. An animated HTML page. Some of the ARTIFACTS, like the CROOK below, are even interactive, with physics interactions to give the object heft and life.

3. A gorgeously narrated audiobook, replete with music and sound effects to augment the storytelling experience.

https://opensea.io/assets/ethereum/0x270488657c6724172372615ea8eb2802b233d41c/1

The Medium of Choice

Why did we choose to go with HTML? When presented with the dilemma of how to make this collection multimedia, video and HTML were the immediate two options.

The upside of video was better support across platforms—they were handled in most places. But the downside was file size and flexibility. How would we generate tens of thousands of code-customized videos in high-res?

Writing code for web, on the other hand, was our strength. It made it easier for us to create animations, add combination logic, etc., and it added the element of interactivity. On top of that, it meant a smaller file size. The only problem was that the support across platforms was patchy. Some marketplaces like OpenSea and Zora supported HTML pages, and a few tools like Gallery did as well, but many other platforms, especially wallets, didn’t support it at all.

To choose, we focused on what these multimedia storytelling NFTs could be—they were a means of injecting the weird wilds with a new kind of dimensionality and physicality. Without the limitations of static imagery, the ARTIFACTS could be living, breathing objects that could (quite literally) tell a story. HTML was the ideal medium for that.

The exploration led us to the SIREN’S SHELL, our first multimedia NFT that we released as a NFT NYC party favor. It emerged out of the research we did for the HUT, allowing us to test out the concept and iterate on it.

https://opensea.io/assets/ethereum/0xa2177f14aad9b44c2fe04ee6731629b8d4e7270c/1

The Generative Logic for the Artifacts

But just explaining what an ARTIFACT is doesn’t begin to cover the sheer complexity that this work entailed.

To call THE NARRATOR'S HUT one generative collection isn't quite accurate—it's more like five generative collections, or even thirty-five generative collections. This grid just shows the spectrum of possibilities, with thousands to millions of combinations represented by every single square in this matrix.

There were five ARTIFACTS (so five objects conjured from the five short stories), and each needed to be able to take seven distinctly different manifestations: one for each of the six archetypes of WITCHES and one for “faceless ones,” or anyone without a WITCH.

Then, within each artifact-archetype permutation, the real magic unfolded. We wanted each ARTIFACT to be visually and/or conceptually customized to the individual WITCH who conjured it. In the lore, we framed the minting process as placing your hands onto an object to make an impression, or copy, of it, thus imbuing it with your essence.

Each ARTIFACT could be affected by a WITCH’s archetype, attunements, astrological signs, and appearance. Some were direct one-to-one references, while others were more abstracted. Some were guaranteed, and others existed on a spectrum of random probability.

Here’s one simple example of WITCH metadata affecting ARTIFACT metadata:

The art for THE NARRATOR’S HUT encompassed a staggering 2,169 individual layers, each of which needed to be filtered through often complex rules and constraints that had to be codified into logic.

But the final outcome? An ARTIFACT that visibly bore the mark of a particular WITCH.

Conjuring with Cohesion

We’d been pushing on the project for many months, and the ARTIFACTS had finally started to take form in all their wonder (and woe). But as I started generating sets, I realized that they didn’t look like they were sets. One crucial ingredient was missing: color coordination, with the WITCH and with the other ARTIFACTS conjured by that WITCH.

We tossed the question back and forth: how should we balance matching aesthetic across six generative art pieces against the magic of randomness?

I put forth two ideas. First, background was an easy win. Each WITCH had one of eight possible background colors, and we could quickly coordinate a set of ARTIFACTS to the WITCH who minted it by matching their backgrounds.

Aletheia created these gorgeous textured gradient editions of each of our original backgrounds that added new depth and dimension but also immediately tied together the color palettes, reinforcing the relationship between a WITCH and their ARTIFACTS.

Second was creating the concept of a primary colorway across an entire set of ARTIFACTS. That meant that each set would have one dominant color across the different objects, ideally matched to some visual aspect of the WITCH.

The logic was different across archetypes—for instance, for MAGES, to select a primary colorway, we checked for script tattoos, then script circles, then hair color. For ENCHANTRESSES and OCCULTISTS, on the other hand, the colorway was based on the WITCH’s attunements: lighter for WONDER, darker for WOE.

Nyx and Aletheia worked overtime to iron out all these rules and then to create the art for them—a daunting task that meant reinterpreting some layers in as many as seven different colorways for each archetype but ultimately shaped cohesion from chaos.

The Hut

Ahhh, our titular HUT. This project was our first chance to build out the point-and-click narrative experience of the weird wilds—how it looked, how it sounded, how it felt. From a technical perspective, it needed to be dynamic and flexible for future use cases. From a creative perspective, it needed to feel immersive and expansive, seamlessly matching the aesthetic of the WITCHES.

After some exploration, we decided to go with PixiJS, a 2D rendering engine that enabled us to support more kinds of mechanics for interactivity. Oizys built component wrappers for PixiJS so that we could declaratively create “scenes”—of which this one would be the first.

Our jack of all trades Starman set to work on the design. We had a difficult task ahead of us: to create a rich interface for a complex set of mechanics conveyed largely through ui cues, all while keeping the environment immersed in the lore. Slowly but surely, we plucked bits and pieces from game design and product design and wove them into an experience somewhere between the two, a fresh take on building a world and telling its stories.

The intention of THE NARRATOR’S HUT was to evoke a sense of a rich and layered world, ignite the imagination with what might be lurking right outside the frame. That meant that we wanted the experience to be experiential and to feel immersive.

Cue this scene: a distinctly magical home, abundant with trinkets and treasures alike.

The interaction starts with a conversation with the NARRATOR to give context to the HUT. After telling you about her home and the ARTIFACTS she keeps within it, she invites you inside. You can immediately hear the ambient sounds of the HUT—a crackling fireplace, the scratching nib of a pen on rough paper, the soft creak of a rocking chair.

The five mintable objects are highlighted with a permanent glow, but in fact many of the objects are interactable, triggering anything from exposition of the world to nods to community creations to witty commentary from the NARRATOR.

When you do decide to take a closer look at one of the glowing ARTIFACTS, you are presented with the option to have the NARRATOR tell you the story bound to it—her memory of the WITCH who once owned it.

To create this effect, we used Google’s Transcription API (with a heavy layering of manual editing) to timestamp each narrated word and sync the story reader’s text to the audio. Starman created a Snapchat Stories-inspired interface for separating out each story into many pages, with the ability to move back and forth between them.

Once you’ve sufficiently explored the nooks and crannies of the HUT, you can choose to mint some ARTIFACTS of your own. The minting screen takes the form of a summoning—a pentagram pointing at the five ARTIFACTS that lights up when each one is selected.

Each ARTIFACT could be minted by any number of WITCHES in a wallet, and the pricing logic differed between wallets based on a few different factors, which made this interaction particularly complex to communicate. But with some tricky maneuvering between design and engineering work, we wove together a simple yet clear interface for minting.

And finally, a finishing touch we added to build out the experience was a brand-new homepage, with the layout of the beginnings of a map of the weird wilds. To enter the HUT, you first click on its exterior—and fall into a portal to another world.

The Contracts

We embarked on this project with two aims markedly different from our first contract:

• We wanted to require people to mint through our web experience, rather than directly through the contract.

• We wanted people to be able to access metadata about the ARTIFACTS on chain.

Why require people to mint through our website? That was explicitly the opposite of what we wanted for our first mint. Then, as a new project by an anonymous team in a time when swindles and tricks were commonplace, we wanted anyone to be able to mint directly through Etherscan.

But for this project, centered on world-building, we wanted these ARTIFACTS to be interwoven with the lore that created them, to situate them in a rich imaginative context—not just offer them as isolated objects. That meant we needed to gate the minting by signature, a task that code whisperer Oizys quickly untangled.

The other focus, on on-chain metadata, came out of a wish for higher composability in our work. Our vision for the weird wilds is a world co-created, anchored by decentralized technologies, and so many of the interesting experiments I’ve seen in this space exist on chain.

Because our rich art style and lore are cornerstones of this project, there were many parts that could never be stored on chain. But this time, since we were starting out with the concept of generative objects with (initially) a much lower degree of complexity than the WITCHES, maybe that metadata could live on chain.

I sketched out our contract—really, two contracts: a metadata contract and a minting contract.

For each token, we would need to store a tokenId, an artifactId (to identify which of the five ARTIFACTS it referenced), and a witchId (since each WITCH could only mint each ARTIFACT once)—already triple the data most off-chain art NFTs need to store.

With the default ERC-721 contract, we couldn’t store that data efficiently, and so Oizys forked ERC-721 to write our very own version, packing the data we needed into fewer storage slots for significant gas savings.

For most of the project, we had planned for entirely on-chain metadata. But as the ARTIFACTS expanded in complexity, the constraints of storing all of our metadata on chain grew and grew—until it became clear that the ARTIFACTS would have millions of possibilities and be much more customized to each WITCH than we had ever anticipated.

And so in the last few weeks leading up to launch, we decided to take a risk and pivot to a hybrid approach. Oizys rewrote our contracts to store only specific metadata (about each ARTIFACT and its attunement modifiers, but excluding all visual attributes) and surface that through on-chain getters accessible to any contract.

Our tokenURI() would instead point to our own servers, to allow us to dynamically and (still) deterministically generate metadata for a given token, including all the visual attributes that had become impossible to surface on chain.

In the end, that left us with three contracts:

• The token contract, a fork of ERC-721 with customized storage for our data

• The minting contract, which handled minting tokens and storing the specific data associated with each one

• The metadata contract, which stored all of the possibilities for each ARTIFACT and deterministically returned the right metadata given token data

Once we were just about finished with the code, we reached out to Solidity Guild to audit the contracts. We weren’t eager to repeat our error from the first project, and so we worked with w1nt3r.eth and obront.eth to refine and hone our code to a sharply pointed tip. To date (knock on wood), we haven’t encountered any bugs in this contract after deploying to mainnet. A fortuitous first!

On Second Acts

Second acts are hard. And they are really, really hard when everyone is burnt out and the market is collapsing. There were many times this past year I wasn’t confident we’d pull it off because of timing, because of luck, because the stars weren’t aligned. But after working on this project for the better part of a year, I think it’s a fitting one for us. It pushes the entire NFT space into new and interesting places, technically and creatively—and, well, we never go by halves.

THE NARRATOR’S HUT is a project crafted with heart and hope, the seedling of the world we’re building. We hope this world beckons to you—as we like to say, the weird wilds await.

If you haven’t yet conjured your very own ARTIFACTS: now’s the time. This phase of minting ends on the winter solstice (December 21).

If you don’t have a WITCH: minting closes forever on the solstice.

If you do have a WITCH, you have until the solstice to claim a gifted ARTIFACT for every WITCH in your wallet and mint additional ARTIFACTS at 0.07 ETH. After that, gifting closes, and minting goes up to 0.2 ETH.

Our second collection invites you into the home of our world’s NARRATOR. Inside her HUT are five magical objects, or ARTIFACTS, previously owned by powerful WITCHES. Each is accompanied by a story of their past.

The five stories are fully narrated, voice acted, and sound designed (an absolute dream come true for me as a writer, but I digress). They’re also completely free to experience. You don’t need to pay or hold a WITCH NFT to visit the NARRATOR and learn a bit more about our world, the weird wilds.

One of our goals as a project is to serve as a peculiar yet warm welcome to the crypto space for the uninitiated. This world, woven by words, art, code, and magic, is not exclusive or gated. We want you to be a part of it. We’re laying out a welcome mat and hot cup of virtual tea.

When I wrote these stories, I knew I wanted to show how witchcraft in our world looks and feels. What are the exhilarations and limitations of power? What does it mean to forge or sunder bonds with the powerful? What kind of genius might a friendly neighborhood omniscient narrative device find crawling on her stoop?

I also wanted to demonstrate how characters, both WITCH and unattuned, exist in the wilds in a concrete way. Our goal is to collaborate with you to build these people and places. Part of that is establishing locations like THE HALLOWED HALLS or THE DEMON MARKET and telling you more about the WITCHES who founded them.

Before I dive into some of my inspirations behind each story, you can experience them in the HUT on our website.

If you don’t have an Ethereum wallet, you can experience just the audio version of the stories on Spotify, or anywhere you get your podcasts. If you’re interested in getting one to experience the HUT in all its audiovisual glory, we have a handy guide for beginners here.

The Stories

AVISA AND CYPRESS

AVISA AND CYPRESS was the first story to find shape, and in many ways the most akin to a traditional tragedy or epic. I knew I wanted to tell the story of THE ORACLE, a near-deity at the center of a vast desert, and the dark secrets of its power.

The idea of SEERS as pirates came from these sick eyepatches Nyx and Aletheia drew into the first collection. Of course WITCHES with the ability to see the future would make the best seafarers and maruaders! Who better to predict the movements of the ocean and the treasures of its guests?

SEERS’ power over time itself makes them both terrifyingly powerful and terrifyingly vulnerable. Several of these stories explore that exchange and its dangers. THE ORACLE, ultimate knower and dispenser of wisdom, is not exempt from laws demanding unbound sacrifice in exchange for power. In contrast, the work of a NECROMANCER can be inherently grounding. The entrance of CYPRESS helped me explore that.

While writing, I spoke often with the NECROMANCERS in our Discord about how the archetype could manifest as patient, kind, steady, and balancing. To face spirits, to calm them, to bring them peace, is the work of someone generous with those who need it most. I was inspired by these conversations and the community entries to our ECHO TREE to represent that kind of death magic practitioner.

I’ve also always been excited by stories of disability and magic, or fantastical worlds that incorporate a wide range of experiences. It was fun to think about how a NECROMANCER so used to speaking to spirits might communicate differently with the living, and how languages like sign might find new contexts among the fantastical.

NULL AND RIJHA

The next story, NULL AND RIJHA, is just the beginning of what we have to share about the relationship between OCCULTISTS and DEMONS. Their pactmaking was a recurring idea in the articulations of the WITCHES and community discussion of THE DEMON MARKET map location.

Where do DEMONS come from? What kind of WITCH was the first to make such a deal and how? What kind of rad extra limbs and organs did they have because of it? Asked and answered. We know OCCULTISTS are the kind of WITCH to seek out sacrifice and deception… but what about ENCHANTRESSES?

ENCHANTRESSES are beguiling, power hungry, principled, driven by ideals and execution. How far might one go to achieve her goals? What might she sacrifice? I’ll admit this story only hints at these answers as a way to set up our future work in THE CITY OF MIRRORS.

Aside from the plot itself, this story also exemplifies our interest in representing a diverse set of experiences in a fictional universe. Null (in addition to Cypress) is nonbinary and uses they/them pronouns while Rijha’s name evokes south Asia. As I was drafting, high witch Xuannu expressed a desire for cultural touchpoints in the wilds that would build on the choices we’d made in the first collection, for example, her own WITCH name derived from a Chinese goddess rather than conforming to a more Western approach to witchcraft and fantasy. The goal of these stories was not only to show WITCHES in action and conversation, but also to introduce the range of people and places that populate the wilds.

IONA AND THE UNATTUNED

One of the core principles the team wanted to communicate was that our kind of magic is not exclusionary. Our stories are not of gifted vs ungifted, but rather of spirit, building, and becoming. While no one may own a WITCH, anyone can become one.

While this is most intuitive with MAGES, it’s not limited to only their archetype. IONA was the first HAG to shape herself through stubbornness and WILL. She protected the earth not because it was her birthright but because it was her lived experience.

As an archetype, HAGS are in tune with nature. That extends beyond an immediate relationship with plants or animals to one of balance on a large scale. HAGS are protectors, architects, and guardians. They correct the natural order of things. IONA points out the unsustainability and disrespect of the BEAST’s actions rather than best it in combat. While we have emphasized the soft, floral cottagecore aesthetic of the archetype in the past, this story expands on HAGS as active arbiters of equilibrium.

We also meet our first BEAST, an amorphous kind of creature oft the enemy of WITCHES. Unlike DEMONS whose powers and behaviors have been loosely mapped, BEASTS are wide-ranging and highly unpredictable. Their origin and motives are yet to be known, if such knowledge is even up for the knowing…

DOVE AND THE ASYLUM

DOVE’s story is a fable, one that made its way to the NARRATOR through lineages of storytelling. DOVE is the only WITCH the NARRATOR herself has not beheld in some form. She is lost to time the way her wards, WITCHES who ruptured the limitations of magic, are LOST.

Approaching the story this way evokes some of our aesthetic inspirations—oral histories and folktales. The wilds’ history finds texture in the contrast between stories immediately recollected and those that have been smoothed by many tellers. THE ASYLUM is something of legend, a relic of the past whose true nature is unknowable to all except the most in need. It is as much haven as it is mystery, a call to the adventurous and determined.

THE ASYLUM is a location Aradia introduced when naming the WITCHES, an origin that appears only for OCCULTISTS and SEERS. It’s fun to see the roots of our ideas for the world planted in each of our contributions to the original collection as we expand on them.

We wanted to create a location at odds with the modern understanding of the word and closer to its original one: a place of solace and safety for those most in need. DOVE’s story follows her as she negotiates with the keepers of such a place: the snow monkeys of THE ASYLUM. Its setting and keepers are inspired by the onsen monkeys of Japan’s Nagano Prefecture. It ends with perhaps the most direct call to action to the reader, or “player” of the narrative experience. Will you be the WITCH to cure the LOST?

SPINOR AND THE DESIGN

Lastly, SPINOR! MAGES are a particular favorite of mine and the archetype I personally identify with. Xuannu and I have racked up many a Discord log chatting about magic that is learned, precise, and innovatively threatening to existing systems. This story is the most “recent” to the narrative timeline of the wilds, as MAGES are the newest archetype of WITCH. Their work, mechanical and strange, has a momentum that thrusts the world into an unknown new era.

Here we see the most of the NARRATOR herself, and experience the liveliest story, one that is present and punctuated by snappy dialogue. I wanted the form of each story to mirror its age. While AVISA AND CYPRESS has the rolling prose and epithets of epic poetry, SPINOR AND THE DESIGN is grounded and immediate. After all, it happened only a few dozen years ago.

Part of what makes SPINOR fascinating and dear to me is how feral she is. Crypto Coven is deeply interested in varied interpretations of femininity and feminine power. A WITCH can be an austere goth, a nonbinary conartist, a scientist who crawls around on all fours observing lizards in nature and attempting to trap them in the claws of her manicure. MAGES have a sharpness to them because of how they experience the world—through tearing it apart.

One of the most distinct visual cues for MAGES are their glowing tattoos and rings, shown here on both a WITCH and their ARTIFACT. SPINOR’s story follows the moment of their invention—the feral scientist who redrew her own limits unlike any before.

SPINOR declares that she will teach her new art at a school of her invention: THE HALLOWED HALLS. The HALLS are a map location home to professors and students, dissertations and expertise on even the most niche subjects. You can find much more information on these studies in the articulations, names, and visages of MAGES. The story behind each WITCH’s tattoos and MAGE rings are yours to tell.

The Future of the Wilds

These stories are the beginning of our expansion, built on the foundation of all the love and detail poured into our original WITCH collection. Through the winter solstice, you can mint ARTIFACTS that contain the audio recordings of each story to take with you on your travels.

There are both attuned and unattuned varieties, either adorably canon or customized to your WITCH if you have one. I am not at all biased towards the spectacular MONKEY CHARMS because they have my voice in them…

It’s been an absolute honor to have these stories out in the world swaddled in such gorgeous art and seamless, tireless code. Thank you for reading and being a part of this adventure.

Narrative is at the heart of what we do, and this is far from the last time you’ll hear from me. In fact, I have three new stories on the ECHO TREE as part of our latest writing contest. If you’ve made it this far, you’re exactly the kind of magic-maker—dare I say, WITCH—we want to build and experience this world with us. We want to live inside your stories, gush over your art, be challenged by your game design, find delight and strangeness in the recesses of your mind you may have to brush the dust off of.

We would love to welcome you to THE NARRATOR’S HUT as well as our Discord and fluttering sphere of socials. Reach out, hang out, we’re waiting by the crow’s nest for your transmission.

As some of you know, I worked on crafting the ERC-721 contract for the initial series of WITCHES for the project. It was the first smart contract I had ever written—about a week or two into knowing what a smart contract was at all. An experience better not repeated, decidedly, but an edifying one nonetheless.

The cryptic art of spellcasting in Solidity can be inscrutable at the surface, but we were able to draw from a collective pool of wisdom that deepens daily… and so we bring our own to you, young arcanists. Here is the story of a contract cast into the ether to bring to life a coven, as well as the trials encountered along the way—the curse of the void witch, and their untimely return.

Unraveling the Meaning of a Smart Contract

It was a few weeks before the Halloween launch of Crypto Coven and, thus, the date at which we were meant to deploy the smart contract for our collection of WITCHES.

The catch? There was no smart contract; and, frankly, we weren’t yet sure what exactly a smart contract was.

We had begun working on the project in mid-September, and there was a seemingly infinite amount to do—drawing art, sculpting a generator, weaving lore, creating a website, and so on. As arcanists with keen competencies in web development, the generator and the website were easy (and, granted, crucial) places to focus our energies. They were already enough work on their own that we had been pulling four a.m. nights for weeks. The smart contract, by contrast, was uncharted territory. We regarded it with no slight amount of trepidation, and so we procrastinated on it until we had simply no other recourse but to dust off the sacred tomes and, well, learn what it meant to write code on the blockchain.

Of course, we could have just used a platform like OpenSea or Zora rather than develop a contract from scratch—but we wanted to write our own. For one, a major part of why we had undertaken this project at all was to explore and experiment with the blockchain as a medium. Intrigued by the possibilities that emerged out of permissionless code and decentralized data, we sought to understand the technologies underpinning them more deeply for ourselves. More than that, we weren’t just dropping a collection of WITCHES—we were crafting a world around them. Having our own contract would enable us to design the entire experience around the summoning of a WITCH, setting the tone for the community we hoped to manifest by offering an early glimpse into the weird wilds.

With that aim, I first set out to get a technical base of the problem space, starting with just one Saturday spent perusing the entirety of the Ethereum Foundation docs on the subject.

What is a smart contract? It’s a misnomer, really. A smart contract is a program that lives and stores its data on the blockchain, typically with APIs to interact with its contents. Poking around contracts on Etherscan makes that much clearer; you can see the entirety of the code for a verified contract, as well as call read and write functions on them.

What, then, is a non-fungible token (NFT)? It’s a record of ownership created and stored within a smart contract that follows a particular standard (ERC-721), and it can point to anything—an image, a song, an HTML page, and so on. Unlike cryptocurrencies, where tokens are interchangeable (fungible), NFTs reference unique objects.

Even as competent engineers, we initially struggled with the specifics of how NFTs work—in part because it’s so simple that it’s counterintuitive. It was hard to believe that that was it. Most NFTs are just pointers: a blockchain-based database entry that points to content somewhere else on the internet. On-chain NFTs are the exception; the content itself lives on the blockchain, not just a pointer to it, but that also means that the content is limited to formats that can feasibly be stored, given the size limitations of the blockchain (i.e., vector or pixel art rather than high-res raster art).

But for our project, for instance, there is absolutely nothing in the smart contract that defines what makes a WITCH—there are just arbitrary IDs (1 through 9,999). Everything about a particular witch exists at the URI at which the smart contract points. That meant that the surrounding infrastructure we needed to write was more fragile and more complex, but the work of writing the contract was relatively straightforward.

Poring over Past Spellwork

After developing a high-level understanding of smart contracts and NFTs, I started looking through existing contracts, from older, well-known projects like Cryptopunks, Bored Ape Yacht Club, and Blitmaps to projects that were just launching at the time, like Doodles. Seeing real code bridged a lot of the gaps in my mental model. Nyx and I had worked to sketch out the functionality we wanted in our smart contract; browsing other projects’ contracts on Etherscan helped to see countless examples of different implementations and feature sets.

As much as we gleaned from all this prior work, perhaps one takeaway was even more salient: not every contract is well-written, and in fact even common practices can be anti-patterns. This space is still early, and many of the people deploying to mainnet are, like us, new to developing on Ethereum—which means that it’s important to never assume that even a well-known project necessarily has good code. Understanding the fundamentals rather than replicating code can be essential to ensure that you aren’t copying inefficient, incorrect, or (worst of all) insecure code.

The Desired Functionality

• Minting

• Gifting

• On-chain royalties

• Gasless listings on OpenSea

• Batch reveals

• Low gas

• Testability

• Transparency

Minting

We had a few aims with minting: we wanted to support both a community sale (limited to a list of addresses) and a public sale, with a three-WITCH-per-wallet limit across both.

Figuring out the public sale and the per-wallet limit were trivial. Figuring out how to limit minting for the community sale to a list of addresses, though, posed a more complicated question. Few of the contracts I read included logic for limiting minting to a list of addresses.

But when I tweeted a different question, asking how people usually implemented airdrops, indreams.eth shared Mirror’s DroppableEditionsLogic contract. I scrutinized it with acolytes Oizys and Enthea, breaking down each function to understand how it worked. We focused on purchaseWithProof(), learning what a Merkle tree was. But even after we understood what it was, we still didn’t understand why this seemingly convoluted logic was necessary. Without any reference points, we kept wondering: why not just write this code, the obvious solution?

function setCommunityList(address[] calldata addresses) external onlyOwner {
    _communityList = addresses;
}

function mintCommunitySale(...) external payable {
    require(_communityList.includes(msg.sender)); // this `includes()` method does not exist!
    ...
}

After some experimenting with code, the reason quickly became clear: gas. The cost of storing so much data on-chain was astronomical. It was perhaps the first revelation we had about how writing Solidity differed from most of the code we’d written in the past. Storing a whole list of addresses just to check whether a given address should be able to mint was a really inefficient use of on-chain storage. Instead, we could use a Merkle tree and only store the root of the tree.

Gifting

With gifting, we wanted to be able to support airdrops and claim drops. In a “true” airdrop, the project takes on the cost of gas and directly sends tokens to recipients. In a claim drop, the recipient covers gas.

We wanted the flexibility of these different options because, around the time the project was launching, gas was particularly high. On one hand, we were super low on funds and weren’t sure if we could feasibly take on the cost of airdropping gifts to people. On the other hand, many of the people we wanted to gift were new to NFTs, and, in an environment where a few hundred dollars to mint an NFT wasn’t out of the question, making the experience as frictionless as possible was important to us.

In retrospect, we probably spent too much time optimizing for this question—it was a relatively minor feature in the grand scheme of everything, and we overcomplicated the contract by deploying it with multiple gifting implementations. With smart contracts, simplicity can be key, especially when it comes to functionality as core as minting, but more on that later.

On-Chain Royalties

One recurring question I had as I browsed examples of ERC-721 contracts was: where are all the royalties? None of the contracts I reviewed had any mention of royalties written into them. Because of that, it was difficult to even learn what percentage royalties a given project received.

We realized that the state of royalties at the time that we were writing our contract wasn’t what we had expected—marketplaces like OpenSea had off-chain implementations, and the one on-chain royalty standard (EIP-2891) that existed was strictly opt-in. In other words, royalties (an oft-touted benefit of NFTs for artists!) only existed at the discretion of third-party implementations that decided to respect them.

Still, a standard for on-chain royalties was certainly preferable to the alternative, so we decided to implement it.

Gasless Listings on OpenSea

Because we were writing and deploying our own contract, by default, people wouldn’t be able to list their WITCHES on OpenSea without paying gas. But we had noticed in their docs, sparse as they were about the specifics and why any of it was necessary in the first place, that we had the option to lower this friction by allowing gasless listings. Oizys was able to piece together what we needed to do to enable the functionality: override the isApprovedForAll() function to allowlist the OpenSea proxy registry address.

Batch Reveals

We were never expecting an instant sellout for the project, nor was that our aim, which meant that we needed some way to slowly unveil new WITCHES and ensure that minters received a random WITCH (rather than competing to snipe the most desirable WITCHES).

That would be simple enough if we were hosting our metadata on our own servers. But we had decided to use IPFS, a distributed, peer-to-peer file storage system. That complicated matters to some extent. IPFS works by using content-addressed storage—in other words, all files that live on IPFS are hashed, producing a unique identifier based on the specific content of that file, and that determines its “address” on IPFS.

In our case, each time we wanted to make changes to the metadata (i.e., by replacing placeholder WITCHES with revealed ones), we would need to upload a new directory containing all of our metadata files—which meant that the IPFS address would change, which then meant that the contract would need to point to the new one. Because of that, we had to be able to update the base URI rather than have it hardcoded into the contract.

Our acolyte Enthea wrote a script to programmatically reveal batches of WITCHES, reading the number of WITCHES already minted to the contract and then populating the directory of minted witches with the correct metadata, creating placeholders for all the others. We then uploaded a new directory to IPFS each time and updated the base URI in the contract to reflect the new address for the metadata.

Low Gas

Lowering gas usage was a high priority for us, given that gas fees had become so onerous around the time that we were launching. At the time, gas hovered solidly at hundreds of gwei, often even spiking to the thousands.

There were a few different ways we attempted to tackle the issue—compiling the contract with Hardhat using gas optimization for 100,000 runs, minimizing data storage with the Merkle tree for the community sale, and looking into best practices for airdrops (specifically, where we covered gas) to make them more financially viable.

For this last case, we spent a huge amount of time implementing different methods for airdrops and comparing gas usage between them, to see if there was a way to get the best of both worlds. We spent days experimenting with different options, ranging from exploring Cargo’s batch transfer EIP to... just minting on a for loop. Underwhelmingly, sequentially minting with a for loop turned out to be the most gas-efficient option.

Testability

Oizys, meticulous arcanist that they are, brought up testing. We needed to be able to easily write tests for the contract to ensure that we didn’t break anything as we made changes.

What that meant for the contract was moving some of the variables we had hardcoded (maxWitches, maxCommunitySaleWitches, and maxGiftedWitches) into the constructor. The tradeoff was that it made it harder to read these values at a glance, but it became easier and faster to write tests checking key logic, like what should happen when we hit each of these limits. And, in fact, we did catch several off-by-one bugs this way before we shipped the contract. Tests! They work.

Transparency

And, finally, transparency. We wanted the limits we’d set for ourselves to be clearly encoded in the contract (i.e., the total number of WITCHES we could ever gift). We hadn’t seen that in any of the contracts we read; the owners of contracts could typically reserve an arbitrary number of tokens for themselves—in BAYC’s case, an infinite number of tokens because the owner-only function wasn’t subject to the max total tokens check.

Similarly, once all the WITCHES were revealed, we wanted to add a verification hash for all the images (which are currently hosted on S3) so that anyone could confirm in the future that they hadn’t been modified.

A First Iteration: The Curse of the Void Witch

Late on the night before Halloween, we finally had a contract that had been heavily tested locally and on testnet. It was time to deploy.

We opened the community sale, to no small amount of chaos—there were a few bugs in the minting UI (notably, that the addresses for the community sale were case-sensitive), but people were finally able to begin summoning their WITCHES.

Oizys and I stayed awake until five a.m. that morning, debugging issues and pushing fixes, but at that level of fatigue, we were breaking more than we were fixing. At some point, everyone started experiencing issues with minting. We decided to figure it out in the morning.

The next day, after a few hours of sleep, I quickly realized what had been wrong—we had reverted to an incorrect Merkle tree at some point the previous night, which is why all minting was failing rather than just some of it. I recreated the tree and added the correct root to the contract, and after we redeployed to the website, we announced that minting was fixed. All was well.

We had decided to do a few batch reveals that same day (rather than have people wait) to commemorate the occasion. The first went smoothly on our end—I updated the metadata and set a new base URI pointing to the new IPFS directory without any issues. But it was taking an unsettlingly long amount of time to update on OpenSea.

We kept pressing the refresh metadata button, to no avail, and we were searching for what might be wrong when we came across a (spoiler: incorrect) writeup about how IPFS files couldn’t include file extensions. Then, when we tested the token URI with OpenSea’s validator, it threw an exception, unable to pull the metadata. The .json extension was written directly into our tokenURI() function. Did we make an error that would prevent the WITCHES from ever rendering?

Luckily, it was just OpenSea’s slow queueing to process metadata refreshes, and within the hour, the unveiled WITCHES began to appear.

In retrospect, this panic didn’t make any sense—the metadata for the placeholder was working perfectly, for one. But we were exhausted and paranoid, and our first WITCH unveiling had stalled. It was our first post-deployment panic over a bug in immutable code; it wouldn’t be the last.

As people unveiled their WITCHES, the tension and stress of the day dissipated. The reception was glowing, and I was floating on the high, dizzy from the whiplash of emotions. The remainder of the day passed in a blur, with each subsequent reveal unfolding smoothly. I decided to go to bed early that evening but first wanted to send out the WITCHES we had been planning to gift to the friends of the coven on launch day.

I went to Etherscan to call the giftWitches() function in our contract, but when I attempted to pass it the full list of addresses (eighteen), I was hit with an impossibly high gas fee and an ambiguous error. Tired, I opted to deal with it in the morning.

The next morning, I woke, ready to figure out the gifting at last. I still had no idea what could possibly be wrong; I wondered vaguely if there might be an issue with one of the addresses or even the number of addresses in the list. I started testing the function with different combinations of addresses, with differing outcomes. With just the first half of the addresses, everything looked fine. Swapping some of the addresses worked as well. Without a definitive answer, I decided to mint to the addresses that looked fine, the first half. All good.

I checked the transaction to see if it had been successful. It had, but upon looking more closely, I noticed that two of the WITCHES hadn’t been gifted after all. We had skipped over two IDs entirely.

What happened? Skimming the function, I remembered that we’d implemented a per-wallet limit for gifting as well as for minting in the community and public sales; two of the people we had intended to gift had already minted three WITCHES in the community sale in the short time that it had been open. Disappointing, but not the end of the world.

I turned back to the second half of the addresses. Except, this time, none of them worked—not a single one could be minted without triggering the astronomical gas fee.

With a growing sense of doom, I decided to call giftWitches() from the command line to see if that would work. Immediately, there, I saw the real error that using Etherscan and Metamask had buried:

ProviderError: execution reverted: ERC721: token already minted

That wasn’t what I had been expecting to see, at all. Suddenly I had a flash of understanding and rushed back to the contract code to reread the function, line by line. How could we be minting a token that had already been minted?

As I read, the situation became clearer, but only to our detriment.

Here was the function I had called:

function giftWitches(address[] calldata addresses) ... {
    uint256 ts = totalSupply();
    uint256 numToGift = addresses.length;
    
    ...

    for (uint256 i = 0; i < numToGift; i++) {
        if (balanceOf(addresses[i]) < MAX_WITCHES_PER_WALLET) {
            _safeMint(addresses[i], ts + i + 1);
        }
    }

    numGiftedWitches += numToGift;
}

There was one crucial error in this code and then one design choice that made it irreparable.

First, we included a check for the per-wallet limit in a for loop and relied on the iterator to assign IDs—which meant that IDs could be skipped, not a desirable behavior under any circumstance.

Second, we were using totalSupply() to assign token IDs because we had assumed that the total supply would always be equal to the last token ID we had minted.

But now we were stuck in a situation where we had a total supply of 135 WITCHES, but the last token ID that had been minted was 137. We had skipped 130 and 135, and there was already a token with the ID 136, which the contract considered the “next” token ID. It was an infuriatingly simple bug, one that could have been easily fixed if we had thought to test that edge case.

But we hadn’t, and the contract was trapped in this state, unable to ever mint again—the crisis we had been so relieved to avert just the prior day had come to pass.

Facing the Fire

So it had happened—our contract had hit a snag that would force us to redeploy after the community had already summoned WITCHES. What now?

The high witches flew into action. Nyx posted a pronouncement notifying the community that minting was on pause as we investigated a flaw in our gifting logic, and we started reaching out to all the people we knew who might be able to help us figure out a fix.

Oizys and I analyzed our options to see if there was any way at all that we could circumvent the bug within the contract. Could we burn all the tokens after the first gap in IDs to reset it to a pre-broken state? Could we deploy a new contract but have it delegate back to the v1 contract for tokens that had already been minted? Redeploying the contract and re-minting all the tokens that had already been minted felt prohibitively expensive—it could exhaust all the funds we had earned from the mint thus far.

After we announced that minting was paused, one Discord user named mersenne inquired about the nature of the bug. They had noticed another potential issue in the contract upon reading it on Etherscan: namely, that the community sale could be drained if a malicious user who had added their address to our community list minted three WITCHES, transferred them to another wallet, and then repeated the process.

In a frankly implausible stroke of luck, this random person who had only just wandered into the Discord an hour earlier turned out to be Matthew Di Ferrante, an experienced Solidity auditor and developer who had been contributing to the Ethereum ecosystem for years. He offered to help us figure out what to do in exchange for a custom WITCH; we agreed, gladly.

With someone with, well, more than a few weeks of experience with writing code on Ethereum, the necessary course of action quickly became clear. We would need to redeploy and roll over all the WITCHES that had already been minted. Outside of the contract, then, we would need to replace the art for the tokens on the v1 contract and (ideally) integrate it into the lore for the world we were building.

Nyx went to work on writing a post explaining the situation to the community. Aletheia started developing the art for what would become the soul vessels—decadent bejeweled vials containing the souls of the WITCHES lost to the ether. Aradia delved into the world-building around the soul vessels, while Keridwen put her pen to weaving the lore behind the so-called VOID WITCH who had snatched these lost WITCHES.

Once we had solidified a plan, Nyx shared out the update to everyone affected, along with what they should expect: that they would be granted new copies of their WITCHES as tokens on another contract, and the WITCHES they had would be turned into soul vessels to commemorate minting at launch. We were terrified of how people might respond to the news.

But perhaps we didn’t need to be. The replies were overwhelmingly kind; not a single person expressed so much as frustration, and, in fact, the community told us to take our time and not rush ourselves. The relief I felt upon seeing that was—indescribable.

With the pressure of immediately redeploying a fixed contract alleviated, Oizys and I turned our attention to the new contract. We now had an opportunity to improve it, not just push out the fixes for the two issues we had discovered.

A Second Iteration: Inscribing a New Contract

So we had our order of business: patch the bugs, roll over the mints from the v1 contract, do a proper audit, make any additional improvements we wanted, and then redeploy.

Patching the Bugs

The first problem we needed to fix was the giftWitches() function. Here was the original glitchy code:

function giftWitches(address[] calldata addresses) ... {
    uint256 ts = totalSupply();
    uint256 numToGift = addresses.length;

        ...

    for (uint256 i = 0; i < numToGift; i++) {
        if (balanceOf(addresses[i]) < MAX_WITCHES_PER_WALLET) {
            _safeMint(addresses[i], ts + i + 1);
        }
    }

    numGiftedWitches += numToGift;
}

We addressed the issue in two ways. First, we chose to remove the per-wallet check—it didn’t make sense to us that we would no longer be able to gift a WITCH to someone if they had already minted three on their own.

function giftWitches(address[] calldata addresses) ... {
    uint256 numToGift = addresses.length;
    numGiftedWitches += numToGift;

    for (uint256 i = 0; i < numToGift; i++) {
        _safeMint(addresses[i], nextTokenId());
    }
}

Just removing the logic around the three-token limit eliminated this specific bug.

But the higher-level problem was how we were assigning token IDs—using totalSupply() made it unnecessarily fragile. Beyond that, Daniel McCartney (a skilled arcanist and friend upon whom we had called to review the code) observed that we were calling _safeMint() in five different places, calculating the correct token ID in each place. He suggested extracting the logic into a nextTokenId() method we could call instead.

We decided to switch to using OpenZeppelin’s Counters library and wrote a new nextTokenId() function (as used above) that would ensure that we would never be able to get stuck in a state where the next token ID pointed to an existing token again.

Counters.Counter private tokenCounter;

function nextTokenId() private returns (uint256) {
    tokenCounter.increment();
    return tokenCounter.current();
}

The next problem was the potential community sale exploit that Mersenne had flagged. The tweak for that was simple; instead of just requiring that msg.sender had fewer than three WITCHES in their wallet at the time, I added a mapping that tracked community sale mints by address and checked against that count.

mapping(address => uint256) public communityMintCounts;

function mintCommunitySale(
    uint8 numberOfTokens,
    bytes32[] calldata merkleProof
) ... {
    uint256 numAlreadyMinted = communityMintCounts[msg.sender];

    require(
        numAlreadyMinted + numberOfTokens <= MAX_WITCHES_PER_WALLET,
        "Max witches to mint in community sale is three"
    );

    ...

    communityMintCounts[msg.sender] = numAlreadyMinted + numberOfTokens;

    for (uint256 i = 0; i < numberOfTokens; i++) {
        _safeMint(msg.sender, nextTokenId());
    }
}

Rolling over WITCHES

We needed a way to replicate the mints from the previous contract, which was straightforward enough. I wrote a function that took an array of addresses and minted them in order, along with a script that created and formatted the list by talking to the v1 contract.

function rollOverWitches(address[] calldata addresses) ... {
    require(
        tokenCounter.current() + addresses.length <= 128,
        "All witches are already rolled over"
    );

    for (uint256 i = 0; i < addresses.length; i++) {
        communityMintCounts[addresses[i]] += 1;
        _mint(addresses[i], nextTokenId());
    }
}

All of these mints would count toward the community mint counts. It wasn’t a perfect mapping because a handful of these WITCHES had been gifts, but we didn’t want to further complicate the logic by attempting to differentiate between the two.

Making v2 Better

Now, the interesting bit. What could we do to improve the contract? With Mersenne, we suddenly had access to a depth of experience with Solidity. As we made changes to the contract, he reviewed them and suggested others. In the end, the v2 contract included five key improvements over v1.

Much Lower Gas

We had made an effort to optimize for gas in v1 of the contract—but we didn’t realize that one choice we had made increased gas usage by ~30,000 per mint and per transfer. Nearly every single ERC-721 contract we read used ERC721Enumerable, the extension that supplied the totalSupply() function we had been using and, more importantly, maintained a mapping of which tokens belonged to a particular address.

We had added it without thinking too deeply about it; the value-add was ambiguous to us, but everyone else was using it, so we assumed it wouldn’t hurt to have the functionality. Without a clear mental model of what kinds of computations cost more or less gas, it didn’t occur to us that the data structures that the extension added could make the two key features of our contract (mints and transfers) as much as 50% more expensive.

With that knowledge, we decided to cut ERC721Enumerable in favor of off-chain implementations that didn’t require witches to pay a premium on every mint or transfer forever.

Reentrancy Guards

In writing the original contract, we considered reentrancy as an attack vector but incorrectly believed that our contract wasn’t susceptible because we weren’t calling arbitrary contracts. It turned out that we had missed a call inside OpenZeppelin’s implementation of _safeMint()—there was a function that did call a function on the receiver address if it was a contract. That meant that it was possible for contracts to call back into ours, sidestepping the checks we had put in place.

Because of that, we had to restructure how a few of our functions were written to update the state we were tracking in the contract before minting to ensure that they couldn’t be exploited with reentrancy.

For example, here was the original claim() function that allowed people to claim a WITCH for the cost of gas only:

function claim(bytes32[] calldata merkleProof) ... {
    uint256 ts = totalSupply();

    ...
    require(!claimed[msg.sender], "Witch already claimed by this wallet");
    ...

    _safeMint(msg.sender, ts + 1);

    claimed[msg.sender] = true;
    numGiftedWitches += 1;
}

Logically, this code made sense—only once the mint was successful did we consider it claimed by the address and added to the total count of gifted WITCHES.

But because _safeMint() allowed reentrant calls back to the function, a malicious contract with a valid Merkle proof could keep calling back into claim() to mint more WITCHES, before we had been able to update our state.

Updating the state before performing actions like minting handled the issue.

function claim(bytes32[] calldata merkleProof) ... {
    require(!claimed[msg.sender], "Witch already claimed by this wallet");

    claimed[msg.sender] = true;
    numGiftedWitches += 1;

    _safeMint(msg.sender, nextTokenId());
}

On top of that, we opted to use OpenZeppelin’s ReentrancyGuard module, which offers a nonReentrant modifier that prevents reentrant calls to functions. We took care to add guards even to onlyOwner functions that only we could potentially exploit, as a measure to increase trust.

Modifiers

And, speaking of modifiers, they were the next improvement that Mersenne offered. We hadn’t been familiar with the concept in Solidity, but I had felt the pain of our oft-duplicated require calls across our functions.

Function modifiers are a declarative way to “modify” functions, with code that runs before or after a function call. They’re typically used to wrap checks, both for readability and reusability.

Here’s one example of how our mint() function changed. We started out with this code:

function mint(uint256 numberOfTokens) external payable {
    uint256 ts = totalSupply();
    require(isPublicSaleActive, "Public sale is not open");
    require(
        balanceOf(msg.sender) + numberOfTokens <= MAX_WITCHES_PER_WALLET,
        "Max witches already minted to this wallet"
    );
    require(
        ts + numberOfTokens <= maxWitches - maxGiftedWitches,
        "Not enough witches remaining to mint"
    );
    require(
        PUBLIC_SALE_PRICE * numberOfTokens <= msg.value,
        "Incorrect ETH value sent"
    );

    for (uint256 i = 0; i < numberOfTokens; i++) {
        _safeMint(msg.sender, ts + i + 1);
    }
}

Not the worst, but also not easy to parse at a glance. Especially since several of those require calls were the same ones we needed in other functions like mintCommunitySale() or giftWitches(), pulling them out into modifiers vastly improved the reading experience and made the code less error-prone.

With modifiers, the content of the mint() function became trivial—three lines of code, with an easy-to-understand list of modifiers that applied to it.

modifier publicSaleActive() {
    require(isPublicSaleActive, "Public sale is not open");
    _;
}

modifier maxWitchesPerWallet(uint256 numberOfTokens) {
    require(
        balanceOf(msg.sender) + numberOfTokens <= MAX_WITCHES_PER_WALLET,
        "Max witches to mint is three"
    );
    _;
}

modifier canMintWitches(uint256 numberOfTokens) {
    require(
        tokenCounter.current() + numberOfTokens <=
            maxWitches - maxGiftedWitches,
        "Not enough witches remaining to mint"
    );
    _;
}

modifier isCorrectPayment(uint256 price, uint256 numberOfTokens) {
    require(
        price * numberOfTokens == msg.value,
        "Incorrect ETH value sent"
    );
    _;
}

function mint(uint256 numberOfTokens)
    external
    payable
    nonReentrant
    isCorrectPayment(PUBLIC_SALE_PRICE, numberOfTokens)
    publicSaleActive
    canMintWitches(numberOfTokens)
    maxWitchesPerWallet(numberOfTokens)
{
    for (uint256 i = 0; i < numberOfTokens; i++) {
        _safeMint(msg.sender, nextTokenId());
    }
}

ERC-20 Withdrawals

We had a withdraw() function in v1 of the contract to withdraw the ETH from the mint, but Mersenne added a function to withdraw ERC-20 tokens as well, so that we were able to pull out any accidentally sent to our contract address.

Initially I thought that it was nice to have this function, just in case, but also the odds weren’t super high that we’d need it. I was wrong! EIP-2981, the standard for on-chain royalties, explicitly does not specify a currency or token, and, in fact, some major marketplaces like LooksRare that have implemented on-chain royalties pay them in WETH, not ETH. Without this function, we wouldn’t have been able to withdraw these royalties; they would be trapped in the contract forever.

Escape Hatch for OpenSea

Finally, as we wrapped work on the contract and readied for redeployment, Mersenne noted that the OpenSea proxy registry approval we had enabled for gasless listings could be a vulnerability for the contract, in the event that OpenSea were ever compromised. If we thought there was a chance that Crypto Coven could become a truly long-term project, it would be wise to add a toggle that allowed us to disable access.

bool private isOpenSeaProxyActive = true;

function setIsOpenSeaProxyActive(bool _isOpenSeaProxyActive) ... {
    isOpenSeaProxyActive = _isOpenSeaProxyActive;
}

function isApprovedForAll(address owner, address operator) ... {
    ...

    if (
        isOpenSeaProxyActive &&
        address(proxyRegistry.proxies(owner)) == operator
    ) {
        return true;
    }

    ...
}

It was a helpful reminder that, in a world of code as long-lived (and an environment as adversarial) as Ethereum, it can be important to take the long view. Companies come and go; the blockchain is forever.

Sealing the Contract

At last, on November 3, we were ready to redeploy. The whole process, as long and arduous as it had felt, had taken just two days.

I deployed the v2 contract, ran the script to generate the most up-to-date list of current owners of tokens from the v1 contract, and called the rollover function. Just like that, minting could resume. The next day, we updated the base URI for the original contract, replacing the WITCHES with the soul vessels. The transition was complete.

In the coming weeks, the state of the project would transform utterly. The coven would start to grow—slowly at first, and then all at once. Soon, countless people we admired, in and out of web3, would start to assume the visage of a WITCH. The first sprouts of conceptual expansions of our world would start to emerge out of the community. And, underneath it all, the contract (its own subject of no little praise) hummed, surely and steadily, holding the coven fast.

Coda

I close this imparting of learnings with perhaps the most important one of all: no smart contract is perfect. The same is true for ours. The Crypto Coven contract that now lives on mainnet contains two known bugs, one of which spelled the return of the void witch. Both are detailed in this earlier post, and fortunately neither was severe enough that we had to take more drastic action again.

Even outside of these flaws, with the knowledge we’ve accrued since this first attempt at conjuring artifacts out of the ether, there are further refinements I’d make—for better on-chain composability, for even lower gas usage, for less fragile batch reveals, and so on. This domain is still just emerging; day by day, week by week, the collective wisdom evolves in novel and intriguing directions.

And, finally: writing immutable code that deals in large sums of coin is emotionally taxing. The sob emoji became the most frequently used on my keyboard; I’ve cursed the very existence of smart contracts more times than I can remember.

But, more earnestly, it is good to face shipping Solidity with apprehension. That’s how it should be. It’s not a responsibility to take lightly. Doing high-stakes work has high-stakes consequences, and once the die is cast, it cannot be undone. The choices you make, knowingly or unknowingly, have gravity.

There will be errors, because code is code, and constructing an incantation to perfectly mirror your wishes requires more than just caution or care. But, as arcanists, the most we can endeavor to do is our finest work—and no less.

Today I’d like to speak to our generator and how a WITCH is forged.

Our generator is responsible for two parts of your witch’s creation:

1. Defining a .json file of text that contains the metadata for your witch, so their definitions are in a parseable format for anyone to read or display (like so)

2. Choosing the traits that comprise their visage and painting the final image

To begin, some background context on ERC-721s and what that inscrutable .json file contains:

The technical shape of a witch

(If you would like to skip to the more creative code, feel free to hop below!)

The final form of a witch is an ERC-721 token, stored on the Ethereum mainnet. As a construct, they are quite simple—a token with an owner and a pointer to an amorphous blob of metadata. ERC-721s are called “non-fungible,” since the abstraction is used to attest that each witch is unique and may not be equivalently exchanged for any other.

A US dollar or a bottle of perfume still in its package is, by contrast, fungible and can be swapped for another of the same kind interchangeably.

Witches associated with a non-fungible tokens (NFT), allow their owner to take them to any web3 destination that may welcome a WITCH. It is stored in your wallet where you alone have custody, rather than a centralized database that may only be accessible through a single platform (like your Fallout 3 character, or an instagram post).

A witch’s metadata takes the following shape, complying to a loose standard for NFTs in general, augmented by recommendations from OpenSea to help standardize their marketplace.

Inside the attributes array, we define aspects that are custom to the project and not shared by the overall NFT standard (physical traits, attunements, horoscopes, etc.). The shape of these objects are arbitrary—we followed a standard that lets marketplaces create filters for the collection, so you could find a Taurus enchantress with pink hair if you like.

Once a witch is constructed—name, archetype, articulation, astrological chart, physical aspects, and final image—our generator uploads all of the above to ipfs, a decentralized file storage system similar to a peer-to-peer torrent network.

We pay Pinata to “pin” our metadata .json files there so that they are distributed across the network and are not subject to garbage collection if they are not accessed for a while. Our smart contract points to the individual metadata files on ipfs, and thus a witch is stored and rendered persistently.

The final images of the witches themselves are hosted on s3—we wanted them to load quickly when a witch desired them, even at large sizes. The caching and infrastructure of a more mature platform lends itself well to that. The images are also easily backed up in case the centralized entity disappears and can be restored using the metadata if all else fails.

Painting a witch’s visage

Constructing a witch, however, has little to do with how it is stored. It’s similar to coding a doll-maker, the ancient internet girl art form perfected by Dollz and Picrew.

What was most important to us is that we had the flexibility to create a set of witches that were truly diverse—a range of body sizes, skin tones, and hair textures, where as many people as possible could find themselves in a witch. A lofty goal, made difficult to achieve by traits that by default are randomly shuffled together.

We also wanted the witches to be visually unique, not merely computationally. Especially at a large scale (such as 9,999 witches) with hand-drawn layers, it’s easy for each of the characters to blend together or feel extremely similar if there are not enough combinations. We needed to optimize for composability so we had enough variety each witch could stand on their own.

The first task of constructing the witches was to define what attributes we would need and their relationships to each other.

Our very first iteration of the generator was based on hashlip’s generative-art-node, which buckets layers in the file system by attribute (eyes, mouth, hair, etc.), randomizes them, and has a simple scaffold to paint onto a javascript canvas using Node.js. It’s a great place to start for simple 2D character projects.

The setup feels similar to processing.js, which has a deep archive of excellent tutorials if you’re looking to dip your toe in generative art and would like more structure getting started. It’s helpful to have a mental model that your code paints layers on a canvas, where each canvas is a single frame in time.

For the witches, I began by creating some quick sketch layers to deliberately trigger edge cases and collisions.

I think an easy trap is to create layers that look cohesively good on a single character but are not composable, limited the range of your collection. Or to avoid tricky edge cases like the purple starry skies hair that do not work well with hats until the very end, coding yourself into a corner where your abstractions are not flexible enough to accommodate them.

Quickly we refined some basic rules—different parts of a hairstyle should be the same color, and witches should not roll conflicting items to wear on their head (forehead jewelry would not fit with hats).

A witch with every attribute at once often looked cluttered, so we decided to flip a weighted coin to determine which layers were present and which were not.

While isolating layers by style or parts of the body worked for most accessories, our most complicated guardrail logic revolved around hair.

A simple color match often resulted in chaotic styles and limited the range we could achieve. We defined textures that were a requirement for the matching logic (straight, wavy, curly, braids, cloud) and broke hair up into even more granular layers we could compose.

Composing hair became a series of array intersections. Roll for bangs, flip a coin to determine optional back, front, middle—then choose from a set of styles for each category that matched restraints for hair texture, color, body shape, and archetype.

Some styles (like the dramatic swoop or cloudy skies) were intentionally drawn with a matching bang and back, while others were made to mix and match to diversify the silhouettes in the overall collection.

We defined requirements and exclusions for certain styles and the large set of possible combinations helped the coven feel visually unique, not just computationally.

For more complex styles, we experimented with how we wanted to solve visual collisions by adding generic rulesets in the code, versus changing how the layers were structured in Photoshop.

For example, the pearl hood on the top left below chained multiple requirements when one of the pieces were rolled (the hood front required the matching hat-back, body-over, and pearl facewear), but the pearls could be rolled alone as headwear requiring nothing else.

To achieve all ends, we defined 21 attributes (or layer types) to express the witches. We settled on a system where some attributes would deliberately exclude each other (horns could not be worn with hats), and others would always be required (hat-backs require a hat-front). The strict layer order is the one rule it is easiest not to circumvent in the painting code, since edge cases and bugs are already complex enough to reason about.

Tagging each hand-drawn style with extra metadata like hair texture, color, body size, archetype, requirements and exclusions, we soon had a witch roller that produced a ~cute~ witch for most rolls.

Assembling an entire coven—scaling to 9,999

As Aletheia + I defined styles for particular archetypes, individual styles needed to maintain a relationship with each other and not just the broad categories of attributes.

We ended up tossing out most of the original generative-art-node structure that relied on filenames for style metadata and moved to a proper database. Xuannü devised a visually beautiful and easily modifiable table for us to upload and manage the individual styles, which allowed us to break out the metadata and have all the high witches help with tagging and refinement for each individual layer.

As the system evolved, our internal “witch roller” let us perceive the sum of these parts as the high witches refined separate aspects, spot-checking for edge cases as we added new assets. Articulations from Keridwen inspired visual styles, Xuannü charted the stars at each WITCH's summoning, and Aradia bequeathed each a name.

the overall structure of the generator also boiled down to something quite simple, thanks to the abstractions in our data model. (though hair continued to be quite complex)

1. roll to pick a witch’s archetype

2. roll to pick their base model (skin color + body shape)

3. roll for bangs, and choose a hairstyle.

4. check the remainder of the attributes in their drawing order, flip a coin if the attribute is optional, and roll a weighed dice to choose from the valid styles not excluded by any previous attribute. Add any dependencies for the chosen style.

5. check that the resulting witch is unique, and not duplicated in the overall collection.

When we needed to make a one-off exception for a certain art asset, Xuannü’s system of dependencies, exclusions, and requirements extended past attributes to individual styles, giving us the abstractions to create specific styles and tweak what assets they did not work with dynamically in our database.

Working with Aletheia to draw new styles and layering on rules and logic to accommodate them in the generator became a satisfying mix of art and science.

To define new rulesets, I’d roll massive test sets scanning for clipping errors and pulling out patterns where assets would clash.

Some edge cases were easier to solve in the art files, like accommodating bangs with transparency. Styles like the buzz cut and baby hairs needed to conditionally render on top of other assets that sat on the head, like horns or crowns causing clipping errors.

For the buzz cut, we ended up baking it into the base model, since there was no way to render the style that worked across skin tones and have it cover the base of horns properly. For baby hairs, it was easier to lower the hairline to not conflict with the horn assets.

By the end, we were able to accommodate an expressive range of fantastical and realistic styles combined with random-ish generation, like this rather generous interpretation of “hat” across the different archetypes I’m quite proud of.

With millions of potential witches, the last step of generation was a hand of human curation, and choosing which witches would be added to the collection. While most glaring visual issues were gone 🤞, aestheic preference that could not be captured by broad rules of thumb were imprinted in this final phase. (Aletheia still caught some subtle edge cases I definitely missed.) We rolled ~15k witches to narrow down to our final set of 9999.

Writing the generator was like taking a deep stretch after a long time spent stiff hunched over a chair. It rekindled my love of generative art (and coding), and was a fantastic introduction to the web3 space.

I hope your curiosity was sated, and that we may cross paths in the wilds ✨

-Nyx

As our anointed blockchain whisperer, I wrote the ERC-721 contract for the genesis series of 9,999 WITCHES, aided by our acolytes Oizys and Enthea and audited by our Solidity adeptus Mersenne.

We’ve been deeply gratified and (honestly) shocked to receive a lot of praise for our first foray into web3 development, and we’re quite proud of what we’ve been able to do with so little experience—we have a deeper dive into the contract as a whole in the works, coming soon.

However, for newer Solidity developers using the Crypto Coven contract as a reference, we wanted to pay it forward by sharing two bugs we’ve discovered in our contract and providing examples of correct implementations.

The Return of the Void Witch: Total Mintable WITCHES

Oh, gifting logic. A painfully simple but subtle bug in the gifting logic had our first smart contract grinding to a halt, and in our redeployed contract, we found ourselves plagued once again by a different gifting bug.

We wrote this modifier canMintWitches() to check if addresses should be able to mint more WITCHES in the public sale:

uint256 public maxWitches; // initialized to 9,999
uint256 public maxGiftedWitches; // initialized to 250

modifier canMintWitches(uint256 numberOfTokens) {
    require(
        tokenCounter.current() + numberOfTokens <=
            maxWitches - maxGiftedWitches,
        "Not enough witches remaining to mint"
    );
    _;
}

What’s the bug? It’s a difficult one to spot because it’s only a bug given certain conditions.

The problem is that there should be 9,749 WITCHES available to mint in the public function and 250 reserved to mint by the owner-only function, for a total of 9,999. This logic works perfectly if no WITCHES are gifted until the public sale is sold out.

However, we had always intended to gift WITCHES throughout the mint, which means that the right side of that check should have been dynamic. As the number of gifted WITCHES increased, the allowable highest token ID for witches in the public sale should have increased as well.

At the time that the public sale closed, we had gifted 93 WITCHES. That meant that tokenCounter.current() had reached 9,749, ending the open mint period—but only 9,656 of them were WITCHES minted in the community and public sales.

The canGiftWitches() function, however, intentionally limited the number of WITCHES we could gift to 250, which meant that we couldn’t circumvent the bug that way, either:

uint256 public maxWitches; // initialized to 9,999
uint256 public maxGiftedWitches; // initialized to 250
uint256 private numGiftedWitches;

modifier canGiftWitches(uint256 num) {
    require(
        numGiftedWitches + num <= maxGiftedWitches,
        "Not enough witches remaining to gift"
    );
    require(
        tokenCounter.current() + num <= maxWitches,
        "Not enough witches remaining to mint"
    );
    _;
}

As a result, 93 WITCHES are lost to the void—this contract will only ever mint 9,906 in total.

(For anyone curious about the fate of the WITCHES trapped somewhere in the ether: stay attuned, for these WITCHES may yet find their way back to the weird wilds...)

Fixing the Implementation

This bug is easily remedied in our contract by adding numGiftedWitches, a variable we already store, to the check:

uint256 public maxWitches; // initialized to 9,999
uint256 public maxGiftedWitches; // initialized to 250
uint256 private numGiftedWitches;

modifier canMintWitches(uint256 numberOfTokens) {
    require(
        tokenCounter.current() + numberOfTokens <=
            maxWitches - maxGiftedWitches + numGiftedWitches,
        "Not enough witches remaining to mint"
    );
    _;
}

A Sealed Vault: Royalties

A big thanks to Zach Burks (founder of Mintable and one of the authors of EIP-2981) for reporting this bug.

It was important to us to have on-chain royalties, not just use platform-specific, off-chain implementations, which is what led us to EIP-2981. The code to support the standard was simple:

function royaltyInfo(uint256 tokenId, uint256 salePrice)
    external
    view
    override
    returns (address receiver, uint256 royaltyAmount)
{
    require(_exists(tokenId), "Nonexistent token");

    return (address(this), SafeMath.div(SafeMath.mul(salePrice, 5), 100));
}

How does it work? Marketplaces call the function to read data for a receiver address and a royaltyAmount, then send the royalties accordingly. In our case, our receiver is the contract address, and the royalty amount is 5%. Easy enough.

Except, crucially, as of Solidity 0.6.x, smart contracts cannot receive Ether directly without implementing a receive() function, which we didn’t have.

While our tests checked that the royaltyInfo() function returned the correct values, we never tested receiving royalties to the contract, so transactions from marketplaces that attempted to send us royalties would trigger a revert.

The remedy for us, in this case, was luckily pretty simple, thanks to the Royalty Registry. We configured an override pointing to a different receiver address (in this case, our multi-sig wallet), so now marketplaces that read from the Royalty Registry will use the override.

Fixing the Implementation

The easiest way to fix this bug to support EIP-2981 is to simply return the same owner address that receives withdrawals, rather than the contract address. Another option would be to add a royaltyReceiverAddress variable and a setter to make this value configurable.

If you do want to receive Ether to the contract address, all you need to do is add a receive() function to the contract:

receive() external payable {}

Coda

Learning to develop in Solidity can be a trial by fire—mistakes, minor and major, live eternally ensconced on the blockchain, often at great cost. But the rigid, unforgiving nature of the space can have its own kind of magic, in the creativity born out of constraint and the solidarity forged through shared sleepless nights. To any budding arcanists making their own way through the wilds: I hope that this offering of our learnings further illuminates the path.

If you stumble upon any other bugs in our contract, please DM me on Twitter—we intend to keep this post up-to-date!

For Enchantresses

ENCHANTRESSES are beings of luxury and glamour—indulge in those ostrich feathers! Those fine faux furs, shimmers, and jewels! Turn to Circe or the Sisters Wyrd to put your ENCHANTRESS in touch with their rich lineage of desire and destruction.

1. Cassandra Dressing Gown in Dark Olive (Boudoir by D’Lish, $500)

2. Serpent Ring (Child of Wild, $170)

3. Wyrd Sisters by Terry Prachett (Bookshop, $9)

4. Chacha Duskita Turban (Wolf & Badger, £357)

5. Dauphine Eau de Toilette (Goest, $140)

6. Legendary Bestsellers Kit (Pat McGrath, $168)

7. Gold Halo Crown (CarbickovaCrowns, $89)

8. Circe by Madeline Miller (Bookshop, $16)

9. Pointed Toe Pompom Slippers (LarosaStyle, $100)

For Hags

The winter is a hard time for your cottagecore cutie. As nature lays down to rest, lift your HAG’s spirits with candlelight, the illustrious mushroom hat, or virtual farming set to the most calming soundtrack the internet can muster.

1. Mushroom Hat Patterns (OfTheFforest, $20)

2. Monstera Adansonii “Archipelago” Keychain (Hemleva, $18)

3. Queen of the Underworld Art Nouveau Crown (idolatre, $393)

4. Plant Magic E-Book (The Wondersmith, $9)

5. Steel Watering Can (MoMA Design Store, $28)

6. Fox Druid Enamel Pin (Gallery Nucleus, $12)

7. The Green Gables Cottage Puff Dress (Selkie, $295)

8. Take Off Temporary Tattoo (Inkbox, $12)

9. Stardew Valley (Steam, $15)

10. Avocado Vase (Huckberry, $48)

11. Winnie Floral Taper Candle Set (Urban Outfitters, $18)

12. Teak Bookends (CB2, $40)

For Mages

If you’ve noticed your MAGE lusting after their WITCH’s octagonal glasses, now is your time. Gift your favorite bookworm a new read, or light up their room with the arcane summoning circle of their dreams and dissertations.

1. Baba Is You (Steam, $15)

2. Agate Stone Bookends (West Elm, $52)

3. Duncan Octagonal Glasses (Tijn, $28)

4. Zodiac Ring (Catbird, $124)

5. AdaBox (Adafruit, $60)

6. HAY Neon LED Tube Light (MoMA Design Store, $75)

7. Equal Rites by Terry Pratchett (Bookshop, $9)

8. The Three-Body Problem by Liu Cixin (Bookshop, $17)

9. House of Leaves by Mark Z. Danielewski (Bookshop, $22)

10. The Hitchhiker’s Guide to the Galaxy by Douglas Adams (Bookshop, $7)

11. Prysm Halo Desk Lamp (WiseHomeProducts, $54)

For Necromancers

Necromancy requires polish, patience, and a fantastic hat. Check out some of the IRL inspirations for the necrotic headgear and jewelry of the wilds. Garth Nix’s Sabriel is a team favorite, and who could say no to a bewitching bat from Jellycat…

1. Wing Earrings (Stonehart, $174)

2. Sabriel by Garth Nix (Bookshop, $12)

3. Theda Headband (Hood, £395)

4. Drucilla Choker (Creepyyeha, $165)

5. Scarab Amulet with Pendant (ModEvil, $136)

6. Leather Gloves with Nail Embroidery (Vivetta, €220)

7. Bewitching Bat Plushie (Jellycat, $18)

8. Stargaze Headband (Hood, £190)

9. Alexander McQueen Pave Skull Earrings (FARFETCH, $380)

10. Framed Sunset Moth (Paxton Gate, $45)

For Occultists

We understand your OCCULTIST is a wildcard. Hard to shop for, even harder to track down as they stalk prey in the moonlight. Gift your favorite monstrosity some temporary ink, chibi totems, fire kits, or maybe even a signed-by-the-artist Animorphs poster. Chaos asked and delivered.

1. Worry Dolls (Sofia Zakia, starting at $168)

2. Demon Horns (HornMaskShop, $49)

3. Cthulhu Crocheted Plush (SweetPeachesInk, $23)

4. Ranger (Solo Stove, $180)

5. Silver Claw Ring (SterlingMalee, $39)

6. Animorphs Poster (AnimorphsArtStore, $50)

7. Talon Bone/Horn Spike Ear Cuff (House of Malakai, $602)

8. Divine Thorns Claw Rings (MyrilJewels, $81)

9. Hand-Shaped Nylon Padded Stole (Vivetta, €290)

10. Damascus Hunting Knife (SksenterprisesArt, $95)

11. Rainbow Flames Pine Cone Firestarters (WeMadeGardenCrafts, $20)

12. Dark Pathways Temporary Tattoo (Inkbox, $12)

For Seers

Having so many all-seeing eyes really tires a witch out, we’ll have you know. Gift your SEER a silk eye mask or calming incense to help their multiple consciousnesses finally catch some rest. If their mind is in the future, we’ve never known a SEER to turn away a new tarot deck or set of oracle cards.

1. Tarot Card Necklace (Sofia Zakia, starting at $595)

2. MTHRSHP MEGA: Celestial Odyssey (Pat McGrath, $78)

3. Cat Tarot (Urban Outfitters, $20)

4. Lirael by Garth Nix (Bookshop, $8)

5. Sleeping Beauty Opal Stud (Catbird, $112)

6. Elucidate Temporary Tattoo (Inkbox, $9)

7. Black Sleep Mask (Slip, $50)

8. Moonology Oracle Cards (Hay House, $12)

9. Le Patch Incense Papers (Ponsont, $24)

For Every Witch

Any witch could benefit from a good read, so here are some of our favorites. These narratives have helped shape the wilds, even as they grow ever stranger. We would also be amiss to not recommend a solid hardware wallet—we don’t want some ruffian absconding with your WITCHES!

1. The Night Circus by Erin Morgenstern (Bookshop, $16)

2. The Poppy War by R.F. Kuang (Bookshop, $15)

3. Foundryside by Robert Jackson Bennett (Bookshop, $16)

4. The Fifth Season by N.K. Jemisin (Bookshop, $17)

5. Exhalation by Ted Chiang (Bookshop, $16)

6. Invisible Cities by Italo Calvino (Bookshop, $15)

7. The Grace of Kings by Ken Liu (Bookshop, $17)

8. Queen of Camelot by Nancy McKenzie (Bookshop, $18)

9. Ledger Nano S (Ledger, $59)

10. A WITCH ✨ (Crypto Coven, 0.07 ETH)

As many of you know, our WITCH NFTs come with not only gorgeously rendered art, but also a name, an archetype, astrological signs, stats within our magic system, and an ARTICULATION.

Here's me:

And a few lovely examples:

When we first imagined this project, we knew we wanted the WITCHES to feel folded into the world we were building from the moment of their inception. Not just empty tokens who would one day populate the universe we create, but individuals with a firm place in it: hags with pumpkin cottages, mages with dissertations on star alignment, necromancers with brooches haunted by lost souls. We wanted the WITCHES to feel alive and bolstered by narrative—something new and exciting in this space.

I started drafting ARTICULATIONS, or WITCH descriptions, with scalability in mind. Our goal was 9,999 WITCHES, more than could be hand-composed without some sort of magic-making. I decided to break down the descriptions into five sentences each: an intro, a hobby, a magic origin, an archetype-specific trait, and an exclamation. I wanted a structure that would give each WITCH an identity made particular, idiosyncratic, and strange, that still unified the archetypes, created an overall tone for the voice of the project, and delivered our ethos of individuality.

To generate the sheer number of sentences required for that level of uniqueness, I used OpenAI's GPT-3 Playground as both a jumping off point for new ideas and a straight-up generator to churn outputs using my writing as a seed when it was up to the task.

Our initial acquaintance was... underwhelming. Here, my input is in bold and the AI output is in standard text:

Although the rhythms were excellent (I believe I used an adaptation of "You let your hair grow out. You let it fall."), the specificity wasn't quite where I wanted it.

More rigid structures, as shown below, yielded better results!

And there were occasional gems like, "Your magic spawns from... a good book with ten very attractive people on the cover," which 100% made the final cut. Polyamorous harem romance is, after all, the PREMIER source of magic.

Here's another AI replication of a firm structure that yielded fantastic results:

For something shorter and more abstract like the exclamations, I let it freestyle much more:

Sometimes the AI just wanted to write straight-up fiction with dialogue, and I hated to crush its dreams, but that was not our intended vibe.

I also found that our energy often struck fear into the heart of this machine.

A large majority of my initial completions were warned to be "unsafe," though the outputs themselves were fantastic and perfect for the OCCULTIST archetype with whom they made their home.

At the end of our labors, we produced hundreds of sentences to be mixed and matched across the metaverse, to combine and collide into thousands of consciousnesses. Aletheia, our WITCH of WISDOM, was the first to say that OpenAI had become something of a digital familiar—a friend and confidante that lent a helping artificial consciousness to the effort of bringing WITCHES to life.

But we were not yet done! One of our goals for the project was to incorporate the creativity and enthusiasm of our early supporters. We collected community moodboards and ARTICULATIONS with the goal of selecting those we loved most to fold into the makings of the weird wilds. The results were, frankly, fantastic:

So now, as our community sale churns on, the WITCHES are articulated not only by my initial writing, but also the strange magick of artificial intelligence and the imagination of some of the project's dearest supporters. Paired with the delightful names generated by Aradia, we've summoned some truly wondrous and woeful WITCHES. 🖤

Admire them all:

https://www.cryptocoven.xyz/witches

BE WELL; BE WILD; OR ELSE, BEGONE!