# JuiceboxDAO Town Hall July 19, 2022

## BuildlGuidl Recap by @nicholas

**filipv**: Let's get into the the BuidlGuidl sponsorship recap with Nicholas. I just want to briefly say that, for anybody who's listening because they participated and they're wondering about payouts. We'll have them out by this week. We're just working with awesome @Griffith to get the last few transactions and things through, so they are in progress.

**nicholas**: Basically the sponsorship the BuidlGuidl Hackathon went really well in my opinion. We, the DAO, allocated $20,000 grant to BuildGuild, half of which is allocated to prizes. Actually with all the extra contributions that people made, it's gonna end up being 13.x ETH distributed to the hackathon winners. We used JokeDAO for the voting and it went really well. Over 9 teams who submitted projects, some of them were really interesting ones. One of them that comes to mind is the one that you buy one of the 3 NFTs and the proceeds go to the BuildGuild, they did it as a starter kit so that other people could use for their own NFT collections to raise funds for Juicebox projects.

The winning project was [**bananas**](https://www.juicebox.money/v2/p/102) by [Ellieday](https://twitter.com/heyellieday) and Co., who did a multi-sig.lol which is like a BuidlGuild version of the Gnosis multisig. They have their own multisig software, smart contract and front end, called multi-sig.lol. Ellie's team did a mixture of the multisig.lol and Juicebox, all on one really attractive front end. So we'll see if they're going to continue that and if they're interested in working with PeelDAO in the future, that should be cool.

And there are other projects that were interesting. One project did a "Tornado.Cach" thing where you could immediately swap for tornado cash to anonymize contributions to a Juicebox project.

There's another project doing a customer support chat using GunDB where you can get approvable chat conversation with the owner of the Juicebox project, So you're getting chat support from the real people.

A lot of cool projects that are definitely worth checking out. We got some good feedback on what it's like as devs trying to build, both the front end devs and as Solidity contract dev, extending the protocol or building things that interact with it, led to some improvements to the documentation and to the actual code. There was even an update to the NPM package that makes it easier to integrate the protocol with NFT contracts in the same contract.

**Mieos**: Is there any incentive for the winners to continue to move forward on their project or is it gonna be just your personal interest at that point?

**nicholas**: Great question. So today @Zom_Bae and I were talking a little bit about it, I'm gonna propose in the next round. We do a JBX grant to anybody who fills out a survey about their experience. @jango floated the idea of people starting Juicebox projects, and I've been encouraging folks in the Telegram to do that. I don't know if there's any specific incentive, but I like what @jango said during the Twitter spaces for Juicebox 1st birthday on Friday, which was that *there needs to be some amount of momentum around the project for it to be worth setting up the Juicebox treasury as well*. I hope some of them do. If you have any ideas, we can definitely try things.

**Mieos**: It's a good opportunity for me just to state out loud that, I went into it with mediocre expectations of what was going to get done in the Hackathon, to be fair I've never been part of one or watched their final or whatever, so I didn't have any expectations, but I was blown away by the level of competency that people were showing not only in their technical capacity but in their consumption of what Juicebox was capable of and really extracting a lot of value from all the little payable terminals that Juicebox have and all the little mechanisms that Juicebox has and has folded into itself. It was really wild to see that. I thought that Ellie and the team really crushed like the idea of displaying Funding Cycles in a more prominent different unique way. The idea of a Tornado to be able to anonymize payments or semi-anonymize payments is a really cool idea, and I think that would be a 2nd tier project where people could have a fork version of Juicebox to enable it or actually built it into Juicebox down the road. I thought those were both killers.

**flipv**: The cool thing is you don't even need to fork Juicebox or anything for that project. The inflow should work with existing Juicebox project. I also want to quickly shout out some of the other projects that were made but didn't get the chance to follow along.

- @Jacobo made a really cool extension to Juicebox project payer that integrates well with Slice.
- There was a multi-sig or a treasury management tool for BuidlGuidl treasury.
- Someone made a starter kit for new Juicebox front ends that works with React and Scaffold-ETH.
- Someone also made an automated Juicebox governance tool.

So if you didn't get a chance to look at these submissions, I recommend taking a look at [the JokeDAO contest](https://www.jokedao.io/contest/polygon/0x3Aa9538c6aCD23526fF72f75A9b9160a275379C3) where you can see all the repos and code. I'll put together an article that goes over some of the submissions soon on the blog for those who are following along.

**jango**: Also shout out to everyone who was contributing here for being present in the Telegram group and helping out, often throughout the day, and for writing great documentation ahead of time. I think a lot of the graphing of what JB's capable of is a testament to a lot of the work done in preparation. Obviously I think the tangent upside of all this is really understanding the DevOps experience and how to improve that also.

**Mieos**: On that note, I felt like that was one of my big takeaways, too. There was a big Ellie's point of what Juicebox could use as a better docks for developers. Do you feel like she was correct on that front? Is that something we want to put time and energy behind to build out?

**jango**: Yeah, I think there are always iterating on how it's messaged and how to organize. But I think in large part, the queries in the graph are a private thing that we pay for over time. It's an interesting thing of how to make those endpoints for data accessible, and I think that's on @peri's mind now and those of folks at PeelDAO. We have starting point docs on interacting with the protocol, but I think we're starting to figure out how to branch from the abstract into the very practical, and it's definitely a work in progress. There's for sure merits to it, but I don't know if some of it is as simple as just altering a few pages, there might be some info limitations.

**nicholas**: Yeah, there's a good [link](https://discord.com/channels/775859454780244028/998771733253341305) that @Aeolian put in the town hall chat for further discussion of the subgraph economics and things where @peri put down some pretty good thoughts.

The goal is to basically just not break the bank of our own but enable devs to get up to speed quickly and able to interact with the protocol without having to deal with the graph as much as possible.

We definitely learned a lot about the experience of being a developer trying to build on top of Juicebox in a variety of ways. I think it was really really successful. I'll wait for the feedback to do an additional postmortem. My sense is that for the amount of money that we spent on it, there really is a lot of exposure amongst devs, as there were over 50 people in the Telegram chat, and there were nine teams each one had like two or three people on them. It was also overlapping with the BuidlGuidl Scaffold-ETH Squad which was really successful and that's something we should replicate in the future. I think it would be very smart for us to do something similar where we partner with a group of devs like developerDAO and basically just seed the water with the idea of using Juicebox and essentially pay folks to have fun and encourage them to play on Mainnet as much as possible.

This notion @jango presented in the Twitter space that *creating a Juicebox project is a way to measure demand for an idea you have while just registering a domain name isn't*. It's fun to just register domain name when you have an idea, but when you create a Juicebox project alongside, I think we could encourage people to think about: "you have an idea, you have little prototype proof of concept, throw up a Juicebox project, and if it starts accumulating suddenly you have a budget". So I think some really interesting learnings from this whole process. I'm really happy with the results.

## NFT Rewards final contract specs by @jango

*@JohnnyD is doing demo on screen*

**jango**: This is running on Rinkeby and we're doing some final touch-ups at the NFT rewards specifications and contract before it goes to Mainnet. We also have a `JBController` dependency for this that I'll talk about right afterwards. Let's do the demo, and then I'll talk about the extent of the contracts that's not yet on the UI, what this contract is capable of and other stuff.

**jango**: The contract that we're going to do here is setting up these reward tiers, which I'll show afterwards what the data looks like. This is getting injected in the first funding cycle, so whenever someone pays into the project, if the payment surpasses one of these contribution floors, it'll also mint that NFT from this collection to the beneficiary's wallet.

Then we wrote a deployer contract, instead of deploying project via the `JBController` that we were doing, there's like a proxy controller that you send all this data to and it'll deploy the data source contract that the actual NFT which is listening for the pay events as well as the project. So the whole launch-project transactions are actually a little bit more expensive with the NFT rewards, but then you have a NFT that's baked into your project for your community to use.

**JohnnyD**: Exactly. So here we can see the NFTs of the new project. You will receive this NFT automatically when you contribute between its contribution floor and the contribution floor of the next tier above it. So if we contribute over one ETH, we won't receive both of these but just one of them. You can click these and automatically get that payment amount in the pay input.

**Felixander**: Is there a limit to how many of these get generated or they'll just get generated endlessly if somebody pays the 0.1 ETH or the 1 ETH?

**JohnnyD**: That is an option. We'll probably look to add that field back straight away.

**Mieos**: Does that payment end up in the activity feed with the NFT that was generated or just the payment?

**JohnnyD**: No implications for the feed as of yet. I guess it'll be coming to the "paid" feed to indicate that an NFT was received for that amount. Nothing yet. It's a good idea.

**jango**: Right now the image isn't baked into the memo like other images are, but there're enough events to get fired during that NFT minting process, I think front end would know that this payment also created an NFT and then go and query the NFT and create a special rule for this. It's a good idea, but it won't be out of the gate.

**Felixander**: I understand these thresholds if somebody pays more than a threshold to get an NFT. Can you also set it up so that let's say the first thousand contributors get an NFT? Is that also possible?

**jango**: Look at the front end section and the way it attaches is on a per Funding Cycle basis. So you could basically have that contract attached to the first Funding Cycle so all the rules will apply for that Funding Cycle. Then in Funding Cycle 2 you could remove the NFT data source, then payments no longer mint from that contract. You can add a new one and use these on a per funding cycle basis.

With respect to the options that you have when you deploy, I'm posting the structure of what a tier is and we'll go over it.

- Essentially you can define upfront what the remaining quantity is. So if you want to have a contract that a tier only has one object in it, like a 1/1, you can do that. You can have 10, 100, you can give any open amount, and you can decide that on a per tier basis.
- Then for each tier, you can also define an amount of voting units that it has. If you want to use this in a governance scenario using one of the standard governor contracts that the tally support, you can define how the voting units of each tier are playing into governance.
- And then you can set a reserved rate. We removed the ability to free mint or burn for the project owner and instead replaced it with a reserve rate. So ahead of time, for every tier, the project owner can decide how many NFTs can get minted or as a proportion of how many NFTs that have been minted totally in the tier.
- And then tokenURI is where the tier metadata is. Each token initially can be set, so all the tokens in that tier get the same metadata similar to that of an 1155. But then the project owner can replace this and override it with the results of a URI resolver contract that he can then customize the imagery per unit in the tier per NFT.

This is the scope of this initial thing, we can always ship upgrades to this. So the beauty of these extensions is that they work on a per-funding-cycle basis. So this hopefully will serve some purpose for a while, until we learn of a better way to do it that justifies deploying a new contract, going through the verification of that and attaching it to the front end so that it can deploy easily. But it's all malleable. We'll kick it off with this and see how these parameters work, but they seem like they solve the bulk of the NFT demands that projects like StudioDAO have in the sub projects thereof.

**Mieos**: Any descriptors or properties that pop up when viewed on Opensea that are particular interesting, or is it pretty generic and we're doing a blend first pass on this?

**jango**: Yeah, that's a front end question. So as the front end receives all the data that @JohnnyD was showing in that screen, it's going to shove it all on IPFS and construct the content for the metadata. I don't know what's in it right now, though. Maybe @JohnnyD or @tankbototms can speak to it?

**JohnnyD**: Yeah, I can grab real quick. I'll post it on the Town Hall chat.

**Gogo**: It's incredible. Can I have a NFT minted to people who already donated previously? Or like they could claim it for free and get the same?

**jango**: You won't be able to do that at first. If you want to write something of that nature, you can do it with retroactive airdrops or something. This will only be for project starting out.

**Gogo**: Oh, you can't use these in the projects that already started?

**jango**: You you will be able to, I'll touch on this after we finish talking about the contract itself. We're going to start by making it available only to new projects, and then there's one more step that current projects are going to have to do before they can use it, which is a little bit of a front end migration thing. So you'll just be asked to go to a version V2.1 controller.

**Gogo**: Got it. Just because in comicsDAO we know that it's gonna be deployed, we have been planning to play with it.

**jango**: Yeah, it'll be soon. We want to do it for JuiceboxDAO and for all projects.

It looks like the IPFS tiers have some of the baked-in data, but I imagine like anything is doable in that screen on the front end, right?

**JohnnyD**: Yeah for sure, that could be changed as much as we like.

**tankbottoms**: When we originally did this, it's really just kind of getting the MVP out. But the image key， name key， external link key and inscription key get presented, the contract itself has a contract URI where you can populate the banner, the profile picture and the information on the Opensea for the project.

We can do anything, it's just about how much acts do you want to put onto the front end to generate. And this was really an experiment in terms of how much front end computational work needs to be done. Having unique metadata for each file looks pretty un-Opensea versus a floor for infinite amount of supply. But the way all the contracts are constructed, you can do anything and I'm sure it's gonna be iterated upon.

**jango**: And you can also update it later as a project owner if you send yourself as the owner of the NFT. You have a couple of extra powers and those are setting the `TokenUriResolver` to overwrite the per tier URI, and then also setting the contract URI. Whenever you want to lock those, you can send the NFT or the ownership to a burn address or something.

A few more things that are relevant in this version of the contract.

Let me send the parameters for the constructor.

So each project will have to deploy one of these in that deploy transaction which is more expensive, but you'll usually just have to do it one time, or whenever you want a new collection, a new set of tiers.

The `UriResolver` we currently leave blank and then you can fill out all the stuff that @JohnnyD was just explaining or that @tankbottoms was just explaining. But I think by default you can leave them blank and it'll just use the tier level information.

The tiers get passed in and then this one flag should mint by default. If you set that as true, then every time payment comes through that surpasses the contribution floor of a tier, that floor or that tier will get minted if there's still supply left. If it's set to false, you have to explicitly in each payment send in the metadata the tier IDs of the NFTs you want. So then you can have any number of NFTs that even share the same price point. For example, You could have an option of 10 or 20 things on your page for 0.18 ETH, then the payer can select any number of them and send in an amount, and in one transaction mint them all into their wallet.

We'll start out just doing the shipment by default thing, but you can if you want to treat it more like a shopping experience where you can just bring whatever inventory and not think about it as tiers, you can also just flip this on.

This is like the extent of what the contract does, it doesn't do anything else. We'll see if we even flip some of these flags around before we have other needs. But this should be a pretty good starting point and it's very well tested and the documentation is tight at this point. So I'm excited to play with it on Rinkeby, and see it out the door very very soon.

**nicholas**: On the reward tiers, maybe they shouldn't be called tiers if that feature makes it possible not be treated like tiers. If I contribute 0.2 ETH and there're two 0.1 level rewards, can I select both if I pass both in that parameter?

**jango**: If you are minting by default, but if you do send metadata in the pay event, you can mint any number of them as long as the amounts are bound by obviously how much you're paying. If the default flag is true and you do want to mint by default, and you're not specifically setting which you want, if there are two tiers at 0.1 ETH and you send 0.1 ETH, then it'll try to mint the one in the last array if there's still any left. If there's not, then it'll keep trying to mint the best possible one by default.

**nicholas**: Let's say there are two tiers at 1 ETH and I send 2 ETH, can I claim both?

**jango**: Not in the default situation. Only if you set the metadata that you explicitly want both.

**nicholas**: If I do set the metadata that I explicitly want both, sorry, this is the deployer of the NFT reward, can the payer specify that I want both 1 ETH NFTs for my 2 ETH contribution.

**jango**: Yeah in the contract level. Yes, this is something that can be exposed.

**nicholas**: Does it mean in a future version you could send your total checkout price and claim all the NFTs up to the sum.

**jango**: Right, exactly. It's pretty powerful. You can do a lot of things. It's a pretty small contract and I think we narrowed in the concepts and some pretty tight little mechanics that should solve a lot of the problems in a good JBX way without opening up a lot of liability for project owners who are now having to manage a new thing. And with the reserve tokens as those accumulate, it's a public transaction just to mint the reserves into the project owner's wallet, so that the project owner doesn't necessarily have to be the one to distribute this.

## Code4rena findings and next steps with @jango

**jango**: About the the code4rena audit, We were writing a new controller，[the `JBControllers`](https://info.juicebox.money/dev/api/contracts/or-controllers/jbcontroller/), which if you don't know much about it, it's the contract that glues projects funding cycles and tokens together to pull off the functionality. And it's migratable, so you can move to new controllers over time that use the same funding cycles and tokens，etc.

We're going to propose moving to a new controller that takes some of the feedback from the code audit into account. Most of the bugs and unefficiencies only occur at very high numbers and it's just like purely dumb precautions of the numbers ever reaching absurd amounts. So it's technically correct, and since we have to migrate the controller for one fairly significant reason, it's worth just doing it right away.

The one significant reason is that there's a bug when one of the projects tries to reconfigure itself and put the start time of the funding cycle way into the future, that has to overflow 2 to 56 storage slot, which might mess up funding cycle scheduling. So having the configure go through a controller that checks the condition prior to cofiguring the funding cycle, it's a prudent move. Obviously most Juicebox projects and the project owner in the community are aligned in interest, there's already this understanding that the project owner has a lot of control over treasury although bound by Juicebox protocol rules. We should definitely make sure the documented rules are tight and crisp. But it's not a big vulnerability.

And obviously through the `JBController` where the launching funding cycles or reconfiguring funding cycles happens, which is what the data source is all about, when you launch a funding cycle, you'll also deploy a contract that does both things: deploys NFT, deploys a project, and stitches them together. So we are first going to deploy this new controller for new projects, which will make the NFT deployment work right at the gate with it. Then we'll work towards encouraging people to migrate from controller V2, which are currently on, including JuiceboxDAO, to V2.1 and then the NFT rewards can be part of subsequent configurations.

## Gnosis update by @filipv

**filipv**: Juicebox is now a default app on Gnosis safe. So when you go to [Gnosis](https://gnosis-safe.io/app/eth:0xAF28bcB48C40dBC86f52D459A6562F658fc94B1e/apps?appUrl=https://www.juicebox.money), you no longer need to add Juicebox as a custom app. It is now one of the default ones.

### Podcasts and articles by @matthewbrooks & @brileigh

**matthewbrooks**: All right. So Brileigh and I have published two recent articles on the Juicebox blog.

We have one article that was written alongside the [Lexicon Devils podcast episode](https://open.spotify.com/episode/3dVbEegY8abnQSbejulgiL?si=u_ax-E5LSNSwtwr-irRGOw), pretty much everything about the metaverse architecture firm that Lexicon Devils is running on Juicebox. So these articles are little case studies, a little bit of history and lore, but also talking about practical uses of the protocol. I think we're also gonna start introducing little articles alongside that talk about their config and how they did it.

We also have another [article fresh off the press for SharkDAO](https://info.juicebox.money/blog/2022-07-18-sharkdao).
They recently celebrated their Shark Anniversary, one year of SharkDAO. We have an article that runs through that history and some of the early NounsDAO OGs and how that all got started. So that also goes along with the [episode that we recorded with @dropnerd](https://open.spotify.com/episode/0XpNBemAlNZCFEh4waPDs5?si=MCos92odSQuZtROTZciV8A).

There will be more blog content that we'll be publishing. I think it'll be a mix of these articles that run down DAO history and that kind of cultural ethnography. But also hopefully some practical stuff about configs and how all the shit was done, so that it can also be an educational material. So yeah, that's what we've been up to.

**Brileigh**: And the other thing is to try to make sure that we time these things with events that those DAO or groups are doing, just to try and leverage that community that's already being active on Twitter or on Discord and trying to be in their communities. So just trying to take advantage of that when we put out the content that is about the projects that are running on Juicebox.

**jango**: It's interesting noting that now that we're at year-end. This is our first town hall after one year of Juicebox. Like everything that has a one-year anniversary in a way, so we were kind of creating these. Over time you'll naturally create content in a reflective manner and I think the way you captured these are really strong.

**Matthewbrooks**: Yeah, it was really fun to write the SharkDAO in particular because we had to really dig into how that crystal ball works. I don't know if anyone's familiar with this shit, but it's real arcane like you have to call a function on the auction house contract and basically you can preview what the next noun will be if you call this function, at that exact block you can basically choose the next noun anyway. There's now FOMO Nouns like @Kent pointed up, but you can still do it manually by calling that function on the auction house contract. So if anyone wants to know how to do that, you can check out the article because it's all in there. It's one of the only places you can find that information.

## Quizz time:

Two truths and one lie:

The correct answer is...

*Mattew Brooks*

And lie is that he is no Japanese Rap band member.

## Juicebox Birthday Banny mint by @nicholas

**nicholas**: I wanted to congratulate all the chads who got the birthday with @sage's art.

I'll post the [link](https://context.app/collections/birthday-banny?utm_source=mint.fun). It was time limited 24-hour-only NFT sticker drop for Banny's birthday. And that was a cool experiment. I don't know if anybody was looking at the Juicebox page for the V2 project, all these mints spammed the activity feed which is kind of fun.

**jango**: That was sick, very very well done. You could imagine it just being a primitive part of the ecosystem that any project can spin up and leverage.

**nicholas**: Yeah, if anyone wants to do anything else like that happy to help deploy. Someone has some art or something, they want to try doing a time limit, obviously that can be pointed at something of the Juicebox. And I just set at a low price to prove out the concept, but you can design them for actual money.

## Saying hello with new/old friends

**Syntonikka**: Hi, everyone. Wanted to say hi. I really enjoyed the stand up. I met some of you guys in New York at the ice cream shop and I've been really curious about what Juicebox have been working around. So I'm just gonna keep working for a bit and learn how you guys coordinate.

**nicholas**: Cool. Is there something you like to work on already in your life that you might like to contribute to or maybe start a project?

**Syntonikka**: Um, I was working with CityDAO for a long time before this, but recently I've decided to quit all my other DAO responsibilities and launched my own projects. So we're still working on the details and stuff and building up a little demo tech stack. Our project did win some prizes in ETH NYC. We hope to launch that on Juicebox at some point, but right now I feel like it's a bit too early to show about it.

**Gogo**: I would like to say something. ComicsDAO has a proposal for Nouns, and SharkDAO just voted that they will back us up in the proposal. So I'm just really happy that the Juicebox ecosystem support each other and it's so amazing that everything happens. Everybody's building just different stuff and they all come together at some point. It is not one year of only the Juicebox product but it is totally one year of the Juicebox ecosystem and I'm just glad that I'm here.

**jango**: Don't sell yourself short. I think you're adding a lot into the ecosystem also. It's cool to see that the ecosystem recycles energy around but y'all are crushing it. The artistry and the ideas coming out of ComicsDAO and the effort you all are putting in is pretty awesome, it pushes everyone forward.

## Discussion on making NFT more accessible to the community

**jango**: I think we'll have NFT rewards out next time around, I'm very very stoked for. That's like such a cool project.

**nicholas**: Maybe we should do an NFT drop.

**jango**: I'm so excited to unleash a NFT drop. Like I just patch that solution to everything with like, "oh, you should do NFT drop." And actually it is true enough.

**nicholas**: I showed the Birthday Manny a little bit. So basically what that one gives you is: set a deadline, point to an NFT, it's an open edition until the deadline and the contribution revenue goes straight to your Juicebox project. So that's one thing people can use, it's called Birthday Banning for now.

The other one is Banana auction, which @Austin and I built together and Perez pitched in. Also @0xBA5SED and @DrGorilla have been helping out with all these contracts giving tips. I'm just working on the final solution. I think it's actually fixed. I just need to test it a little bit.

It is like a Nouns style auction. You bring your own metadata, you deploy a contract that just has the metadata for an NFT, and then you deploy this auction contract and it uses the metadata you already put out there.

We supply a couple of contracts, one that gives you the same metadata for every NFT in the collection, and another one that lets you point the metadata at IPFS, and you can just have a IPFS file with a bunch of different metadata in it. I like different NFT basically, but in other case or you can do something completely yourself on your own.

You deploy that and the auction, then it sequentially auctions off the token IDs and the collection with a given interval duration between the auctions. So like basically we did one with like a one hour delay between the auctions. So there's like an on-chain auction for an hour limit, when the deadline comes, somebody finalizes it and the next auction is kicked off for the next token ID in the collection.

So both of those are available if people want to experiment. I think there's some improvements we can make to the auction one, but it definitely works as like a stunt NFT contract. I think if you want to make it your main NFT in your universe or whatever, you might want to think a little bit harder about not having the NFTs built into the auction itself, but definitely for something like the stickers or something fun. So it's a great working contract.

So the auction one has its own front end. You can check out [bananaauction.surge.sh](https://bananaauction.surge.sh/) was the V1 of that idea that I just talked about, the auction thing called banana auction or banana auction machine. @0xBA5ED,, JuiceboxDAO contributor, found a bug in that one. That was a vulnerability, so we exploited our own contract. It basically just killed the auction and made it impossible to start the next round of the auction. Since then I've been working on a fix with integrating a bunch of things.

**Mieos**: If I had a contract and a piece of art, where would I take it to actually push it up.

**nicholas**: Totally. I think what I want to do is to write a blog post for both of these, which just walks you through the steps to do it. It's maybe a little bit gnarly to deploy the contracts, maybe like a remix something. Basically the auction machine one has its own website because it needs its own buttons for bidding and then finalizing the auction which could use some love if any front end devs or designers want to think about how to make that prettier. But basically it feels like the nouns.wtf website.

The Birthday Banny has no interface at all, and I used the mint.fun website. I'll post the [link here](https://mint.fun/0x2c13ddc9adf2476b086344032b94d13230a10229), which @tankbottoms really taught me the lesson, but basically they indexed any website that has any NFT contract with a mint function. They just create button for every price point. The way I wrote this the contract let you mint the same NFT as long as you gave at least 0.001 ETH. I sent 2 transactions at 0.001 ETH and another 2 transactions at 0.01 ETH, and it created two buttons automatically at those two price points. So you can kind of get away with using this as a cheapo autogenerated mint website. For the NFT insiders, gem.xyz has a similar function which I have not played with, but I think there's also a page probably for this collection already.

I mean honestly the mint.fun thing is great. I guess it would be nice if people could like customize it to make it feel more like their own.

**tankbottoms**: I think it would be cool just to do one and keep the free ones free and then for increments of whatever the amount is put in like 0.125 to a treasury. Because people just go there and just like mint crap and then if you take a fee off that give me a big disclaimer and we can route you to like flash bots or something like a mempool. I think it looks like mempool too for what's going on, so you could schedule it.

**nicholas**: We could do multiple tiers like a free tier, then we can put anything above free can get a different color such as blue Banny or something. Some people would ape into the rarer ones or the expensive ones, especially if you set low prices. We can probably beat some efficiency out and make that even cheaper to mint the free tiers pretty close to free.

We've got a lot of crazy ideas. There was this crazy idea I had last week about what you can do like an NFT. Imagine a poll where anybody can insert their own answer and it ranks them by the most votes for that answer. But each one of them to submit your poll vote is to mint NFT and they're all open edition NFTs for the duration of the poll so you can have a NFT poll basically where you can vote by minting. And maybe there's a mint price associated with it and all the revenue goes into a Juicebox project.

So if anyone's down for these ideas, we can just start building these like crazy. I think showing people what you can do is how we get the next level of Juicebox use.

**jango**: When another V2 is out and we have these stable contracts addresses, these experiments can have whatever lifetime that people end up giving them. So if you find bugs along the way we can cancel them and then do it again. They're gonna get better every time so definitely pump those out. It'll be sick if a lot of @tankbottoms's experiments could help inform the file uploads and make it less dev heavy, but we can start shipping these as standalone packages that people can post and serve themselves or rehab some hosting on .wft or whatever. Super neat.

See if we can proliferate these experiments and get them into experimentation production for whoever wants to try it out. People can judge how much weight they put on them over time as they get iterated on. How can we make it easier and create more ways that that projects can bring things off the shelf to create a mechanism for growing the community and helping to get new accounting primitive online for projects like these NFTs that can be used for voting if people wish. I'm very excited to be in that phase. Another V2 is out and we're playing with some of these early attachments.

**nicholas**: Actually while we're on the topic of making it easier for people to build stuff. @DrGorilla and I talked a little bit about a [forge template for the extensions](https://github.com/jbx-protocol/juice-extension-template) that you guys put together. I'm interested about making a quick start really easy for giving NFT to MVP of paying the Juicebox project or whatever. It's getting that up as quick as possible. So lots to think about there.

**DrGorilla**: It's kind of generic extension because that's our delegate data sources you can put in terminal there as well.

**nicholas**: I really just want something where they can just swap out the IPFS of what the metadata is and hit deploy and they've got it. They really just had to paste one value into a contract and it's pretty much done.

***

:bulb: Archives of JuiceboxDAO Town Hall can be found [here](https://hackmd.io/@zhape/jbx_town_hall_archive)

###### tags: `JuiceboxDAO Town Hall`