I’ve been talking a lot with the contributors of Blergs and thinking about how best to structure the next phase of the project. TLDR, phase 2 is actually 2 projects that are tied together.

Blerg traits aren’t actually Blerg traits. They’re not even part of Blergs at all, except for the fact that we’ll be making them and releasing them. Blergs will rather be the first consumer of the traits as a standard mechanism for changing the appearance of a PFP NFT project.

The goal is to make them interoperable across any project, therefore they shouldn’t be made to only work with one project. Their lifespan also shouldn’t be reliant on the longevity of Blergs.

We want traits to be able to be integrated by any other project, such as another PFP or a game or anything along those lines. To be willing to do that, 3rd party developers need to have the confidence that Traits won’t suddenly go away. They need to last forever and be immutable. They also need to have metadata that is specific enough to allow for an implementation, but generic enough to allow for any implementation.

Let’s focus on the Golden Cube trait as an example:

Before, I was thinking about Traits as they’re rendered in this card above. I’ve shown it before, but let me explain what it represents:

• A trait

• A torso

• A higher level trait than the tungsten trait

But it shouldn’t be that.

All of that is Blerg centric, and leaves other developers little room to implement it. After all, what possible other use would another project have to use a Torso in the shape of a golden cube?

Here’s what is should be:

• A golden cube

Let me explain the difference.

• No information about placement

• No information about relationship to other traits

• No information other than that it’s a trait called “Golden Cube” and it has some visual representation.

Blergs will choose to allow it to be equipped in the Torso slot, or the head slot, or the hair slot. But nothing about the trait itself would force that to be the case. Any developer, then, who wants to use this NFT as an element in their experience, could say this is an ingredient, a token, a piece of currency, or even that it has no meaning at all. Those developers would be free to interpret this golden cube in any way that they want. For Blergs, it would fit in 3 slots, but that’s because as the first implementors of this trait NFT, we can choose to make it that way.

Our implementation has no bearing on how others see fit to use it in their own project.

With the former idea, we were looking at having this Golden cube mintable 3 different ways. One as a hat, one as a head shape, and one as a torso. So in order to make a Blerg like this:

You’d have to hold 1 of each of those 3 traits:

This implementation would be fine for Blergs, but not fine for any other project to use, unless they wanted to basically recreate the project that we are making. If traits is open-ended, then it’s only limited by the imagination of the development team.

With this new iteration you wouldn’t need to hold a Golden Hair, Torso, and Head, you’d just need to hold 3 golden Cubes, all of which could be equipped in those 3 slots.

This allows all of the traits to be simplified down to their core metadata. All of the Puregs, for example are just the combinations of the trait in multiple slots.

Now, this is not saying that some things don’t make much more sense to be in specific slots, but it’s rather saying that those placements would be the responsibility of the developer who’s consuming the trait, not in the trait itself.

I spoke recently in the Blergs collaborator call about making something that lasts more than 6 months—about how product designers (like me) make things that are short lived. Apps, websites, software all change rapidly and should be almost unrecognizable after a year of progess. I envy architects because they can design a building that will shift uses, change and evolve over years, and outlive their creator. NFTs are the first digital product that has the potential to last in that way.

I’m not going to speculate on the adoption of these NFTs, or if their nature as long-lived will mean that they are longer-used, but if we can make sure that their data will live as long as Ethereum, we should. To help with that, trait NFTs should be fully on chain or at the least immutable.

If they’re not, then we can change them. Which would undermine them as a mechanism for other experiences and shake the bedrock that any platform should be. They need to last, they need to be unchangeable, and they need to have staying power.

Fully on chain would mean that the trait art would have to change from their current appearance, or drastically simplified. Max and I originally wanted Blergs Genesis to be on chain svg, but the costs to deploy are VERY high and there’s a lot of limitations in svgs. We’ll need to investigate this further and talk to other projects that have gone all on chain.

If Traits do end up being fully on-chain, then anyone can use them for anything. I’m talking creative commons, total ownership level open for the community. If there’s any technical barrier to adoption, then it will push back on their ability to be adopted at all.

So, Blerg builder and the Traits should be thought of as 2 separate projects and products. The builder, which will look like Blergs and be a PFP project, will be the first (and maybe only) consumer of traits.

Traits will be a project that will release maybe at the same time, or even before the Blerg builder does. It will have a starting number of items, and those items will be heavily influenced by Blergs, but over time it will be added to and grow in the overall collection. Its primary focus should be on being totally extensible and generic, so that any developer can implement them in their project how they see fit.

Our steps now are to define the traits that will launch, define a mechanism to add to them over time, talk to other projects who might want to also use a shared protocol, and then launch our first versions to test these ideas.

I’ve been talking a lot with the contributors of Blergs and thinking about how best to structure the next phase of the project. TLDR, phase 2 is actually 2 projects that are tied together.

Blerg traits aren’t actually Blerg traits. They’re not even part of Blergs at all, except for the fact that we’ll be making them and releasing them. Blergs will rather be the first consumer of the traits as a standard mechanism for changing the appearance of a PFP NFT project.

The goal is to make them interoperable across any project, therefore they shouldn’t be made to only work with one project. Their lifespan also shouldn’t be reliant on the longevity of Blergs.

We want traits to be able to be integrated by any other project, such as another PFP or a game or anything along those lines. To be willing to do that, 3rd party developers need to have the confidence that Traits won’t suddenly go away. They need to last forever and be immutable. They also need to have metadata that is specific enough to allow for an implementation, but generic enough to allow for any implementation.

Let’s focus on the Golden Cube trait as an example:

Before, I was thinking about Traits as they’re rendered in this card above. I’ve shown it before, but let me explain what it represents:

• A trait

• A torso

• A higher level trait than the tungsten trait

But it shouldn’t be that.

All of that is Blerg centric, and leaves other developers little room to implement it. After all, what possible other use would another project have to use a Torso in the shape of a golden cube?

Here’s what is should be:

• A golden cube

Let me explain the difference.

• No information about placement

• No information about relationship to other traits

• No information other than that it’s a trait called “Golden Cube” and it has some visual representation.

Blergs will choose to allow it to be equipped in the Torso slot, or the head slot, or the hair slot. But nothing about the trait itself would force that to be the case. Any developer, then, who wants to use this NFT as an element in their experience, could say this is an ingredient, a token, a piece of currency, or even that it has no meaning at all. Those developers would be free to interpret this golden cube in any way that they want. For Blergs, it would fit in 3 slots, but that’s because as the first implementors of this trait NFT, we can choose to make it that way.

Our implementation has no bearing on how others see fit to use it in their own project.

With the former idea, we were looking at having this Golden cube mintable 3 different ways. One as a hat, one as a head shape, and one as a torso. So in order to make a Blerg like this:

You’d have to hold 1 of each of those 3 traits:

This implementation would be fine for Blergs, but not fine for any other project to use, unless they wanted to basically recreate the project that we are making. If traits is open-ended, then it’s only limited by the imagination of the development team.

With this new iteration you wouldn’t need to hold a Golden Hair, Torso, and Head, you’d just need to hold 3 golden Cubes, all of which could be equipped in those 3 slots.

This allows all of the traits to be simplified down to their core metadata. All of the Puregs, for example are just the combinations of the trait in multiple slots.

Now, this is not saying that some things don’t make much more sense to be in specific slots, but it’s rather saying that those placements would be the responsibility of the developer who’s consuming the trait, not in the trait itself.

I spoke recently in the Blergs collaborator call about making something that lasts more than 6 months—about how product designers (like me) make things that are short lived. Apps, websites, software all change rapidly and should be almost unrecognizable after a year of progess. I envy architects because they can design a building that will shift uses, change and evolve over years, and outlive their creator. NFTs are the first digital product that has the potential to last in that way.

I’m not going to speculate on the adoption of these NFTs, or if their nature as long-lived will mean that they are longer-used, but if we can make sure that their data will live as long as Ethereum, we should. To help with that, trait NFTs should be fully on chain or at the least immutable.

If they’re not, then we can change them. Which would undermine them as a mechanism for other experiences and shake the bedrock that any platform should be. They need to last, they need to be unchangeable, and they need to have staying power.

Fully on chain would mean that the trait art would have to change from their current appearance, or drastically simplified. Max and I originally wanted Blergs Genesis to be on chain svg, but the costs to deploy are VERY high and there’s a lot of limitations in svgs. We’ll need to investigate this further and talk to other projects that have gone all on chain.

If Traits do end up being fully on-chain, then anyone can use them for anything. I’m talking creative commons, total ownership level open for the community. If there’s any technical barrier to adoption, then it will push back on their ability to be adopted at all.

So, Blerg builder and the Traits should be thought of as 2 separate projects and products. The builder, which will look like Blergs and be a PFP project, will be the first (and maybe only) consumer of traits.

Traits will be a project that will release maybe at the same time, or even before the Blerg builder does. It will have a starting number of items, and those items will be heavily influenced by Blergs, but over time it will be added to and grow in the overall collection. Its primary focus should be on being totally extensible and generic, so that any developer can implement them in their project how they see fit.

Our steps now are to define the traits that will launch, define a mechanism to add to them over time, talk to other projects who might want to also use a shared protocol, and then launch our first versions to test these ideas.