# Juicebox DAO Town Hall - Aug. 09, 2022


## V1 to V2 migration updates with @jango

So @zhape brought up a concern or curiosity coming out of the CN community of JBX, asking about progress the V1 JBX migration to V2 JBX along with the fee that can route project fees to the best price available for JBX, on an AMM or from the issuance, which is a thing that we discussed long time ago as part of general JBX issuance policy and part of the conversation about compensation we were having a while back. I think that mechanism seemed to at leat alleviate some macro concerns or to be where people's heads were at. It has not been implemented in production obviously yet. So I guess to reiterate some of the specifications of that project to recount where we've been the past two months or so.

We deployed the V2 protocol and have started supporting projects built on V2. The projects are paying fees down to our V2 treasury, which is issuing out this V2 JBX token back to them. We have yet to issue a V2 ERC-20 token, so it's being emitted just as a project token. And at the same time we still have our V1 treasury, which is also collecting fees and distributing V1 JBX. The V1 JBX is an ERC-20 token trading in AMMs and whatnot.

The initial idea was to deploy the V2 project and then work towards a V1 -> V2 migration payment terminal, where V1 JBX holders could send their tokens to the V2 Juicebox DAO Treasury and receive V2 JBX in exchange, at a conversion rate of 1:1. And that was implemented both contractually with the extensions afforded by the V2 protocol, as well as on the front end by @Aeolian. And we're still sitting on both of those pieces of work.

I think we learned a lot about some inefficiencies of the current delegate pattern, in so far as that when people paid with terminal, then we have to do this dance of using overflow allowance to pull funds out, go to the AMM and do the swap, send back to the user. I think we pulled it off, but we found a better design for implementing these delegates over experimenting with one in the background, where the funds are a little bit more accessible and we can route the project fees to an AMM little easier. The same time we did the code4rena contest, we found other little things to adjust in the payment terminal in the controller.

I guess the big deal is that we're prioritizing NFT rewards project extremely, so we were doing two things at once.

- We have this risk mitigation versioning that's onging, and we're figuring out, given what we know to be true, what are some simple steps to give them, where we are to a place that we feel more comfortable putting weight on and building on top of.
- Then we will be stress testing what we currently have with this NFT rewards feature, and also prototyping things along the way the fee extension thing.

So I think from where we stand right now, the things that I'm thinking about for the next few weeks is certainly the NFT rewards, get that out the door as we have been pushing on continuously and then a prerequisite of that is some of the versioning work.

Once that's in place, we'll have a choice to make with regards to JBX. If we do move forward and prioritize the Juicebox fee extension to route to AMMs, we can potentially choose to route fees to the V1 JBX, because otherwise we have to wait until there is a V2 JBX / ETH pool somewhere to find a price for，which might be a slower process unless the DAO wants to sponsor it in some way. We can try to just target the V1 JBX pool until it drains and we're back at issuance as the best price for JBX.

So we're getting into a world of small decisions like that and its tradeoffs, but the prerequisite is what we've been focusing on. Shoutout to @aeolian for doing the front and work and getting it all the way to the end, and then I think everyone treats it as a paused situation because we had some more pressing versioning stuff to do.

But in my mind that's still the best solution for JBX issuance. I think the DAO should really decide if it wants to involve itself in AMMs, if it were to actually put that extension in production. That's a thing of situation that we have to wait together, after a few more prototypes, after getting some of this prereq work at the door. Any questions on the whole V1 -> V2 or fee module work?

**nicholas**: Where's the best place to keep up with all these subjects?

**jango**: I think there's still a couple threads, which are for sure archived by now, that had the conversation brewing. I'm going to resurface them. [Fee extension](https://discord.com/channels/775859454780244028/967930005957005412).
I don't think there's much to keep up with right now, let's get all this prereq work done and then figure out what's on the table afterwards. Now we're gonna approach them like who's down to work on what.
The protocol conversation regarding the V1 -> V2 migration is [here](https://discord.com/channels/775859454780244028/978391524616331274).

**Question**: I've got a question. Who are the devs working on the current migration from V1 to V2?

**jango**: It's not like a full migration.

In general, @DrGorilla and I were doing contractual work with help from 0xBA5ED and @Viraz, which tends to be the cast that follows projects around and asks questions as you review and test. On the frontend side, it's the Peel DAO folks who are facilitating the general workflow in juicebox.money and how tokens holders of a V1 project might exchange them for V2 tokens, and creating a pretty clear workflow for the exchange, as well as for those V1 projects to stand up a version on V2 or figure out how to evlove from there.

But from V1 to V2, it's not a very clear cut migration, it's not like pressing a one button, you have to create a new V2 treasury, which is a whole another thing to manage. So it's not necessary to even migrate to V2 for most projects which are pretty well suited for V1, so it depends on how projects want to evolve. I think to that point, there is a lot in social layer of trying to understand what projects want to do or what the projects want to become, which is largely handled by @nicholas and @0xSTVG and @filipv and other folks who float around and answer questions for people.

## NFT rewards update @jango

**jango**: I think we're down to the last PR, apart from some crazy ideas that are definitely not scoped for this first version. I'm doing a couple of last tests. We had a pretty fresh deployment from a few days ago, but there're some PRs that do touch the deploy parameters. We could probably get one up at the end of this meeting or towards this in the next few hours, and I would love to spec out with that. @JohnnyD is stitching together the juicebox.money interaction point, but things are looking good there too.

A pretty big refactor got landed in the end of last week. We have some finishing touches to allow different reserved rate beneficiaries per tier, so that you can have many tiers and each of them have their own reserved rate and each of the tiers can route that reserved allocation to different addresses, so that folks can use the same contract for various different use cases. There is pretty sweet tweet from @Aeolian earlier this week.
Right now most things are serviced from juicebox.money, but there's definitely room for hyper focused clients to interact with the same contract and just reveal certain functions or prioritize certain functions.

**kentbot** I think there's a couple more features that are in the contracts just getting exposed now, and I think we're there. There's another conversation about something that are more UI UX focused, like what are we exposing to metadata the rest of the stuff. I think we should focus right now on just the things that are contract oriented and get that locked and out the door. We can mess with UI and we're going to mess with it forever. But just getting the ability for users to exercise and get into all the real contract oriented features, in my mind, would be what the MVP should be. Once we're there on reserve rate, once we're there on tiers, rarities, mint limits those kinds of things, it's like get out there and then figure it out.

**jango**: I think this is a frontend thing too. I know like adding even a line of text to an already full frontend experience is delicate. The contracts feel like they're at the point where we're not taking anything away and we're not adding anything else, we're just stabilizing everything that's there. I think frontend is looking at the max mints per tier and then the reserve rate stuff, but I think the reserved rate might be for a future frontend iteration too, although I know you want to mint some for the team off the bat.

**JohnnyD**: Max mints per tier is done. There is no initial mints, which you just mentioned. I wasn't aware @kentbot was interested in that, but if he's, I'll make that the next priority. This last week we've just been bring together some fresh designs from our new designer @Strath. So if anyone's keen they can go checking some of the latest V2 projects on Rinkeby，or the frontend NFT Channel.

**jango**: Or if you want to do a demo, I don't know how packed the agenda is, but maybe some folks would like to get a peek behind the thinking, behind some of the choices. I think with regard to the minting, the initial thought from a while ago was about open mints for the project owner and then we scoped it down to that project owner preconfigures a reserve rate. So that mintors have at least some confidence that project owners are not just gonna mint some arbitrary amount. But it is a slightly more trickier frontend design, so definitely haven't pushed it as a big top-of-mind thing for y'all but might be worth considering this upcoming few days.

*@JohnnyD doing demo sharing screen*

**JohnnyD**: We've added that maximum supply amount for each tier in the create floor, and the next key UI update will be incorporating the amount remaining for each tier onto the project page somehow. Most likely coming from a model after a second click on these.

If you have any comments or feedback So please let me know in the [link](https://discord.com/channels/775859454780244028/990055537615970384)

## Applejuice delegate

**0xBA5ED**: I've been working on applejuice for a bit, but it's been on hold for the past few weeks, since we need the dock migration first. I think we have other things that have higher priority so it's been onhold for a bit. As far as I remember, it does have all the required things and it should be ready for at least testing on the testnet to see if it's working and if anything crazy happens.

**jango**: It's also one of those projects that's gonna benefit from this change in how delegates can receive ETH upon payments. This is kind of a bit slight feature addition to payment terminals amid all this bug fixing stuff that we have been working on. It's for the terminal contract to potentially be able to forward ETH into the pay delegate whereas before the pay delegate would have to have permissions to pull overflow allowance from the treasury to be able to apply it to different strategies upon payments. Obviously, I think you can do that applejuice not via the pay delegate but through other means of allocations so you're not doing it every time someone pays。 But I think that whole design space for delegates and data sources extensions is that somewhat it has been stress tested by the NFT reward stuff, that might be enough to inform a few design edges that will be useful to then do other other stuff later. It's not really worth doing a ton of extension work now, with that upgrade in progress.

The idea of the terminal of that project is to automatically allocate the funds that come in to different yield generating strategies, while still allowing the funds to be redeemable by the original token holders. There's a little bit of an accounting thing going on and it can be complex if you take it to the extreme. They're trying to scope it down to start with one strategy and going from there，it's useful. As far as treasury management is concerned, the biggest thing on my mind, when I think about priorities or things that I would like to see for projects that I have in mind for building stuff, is just a DAI terminal that you can move funds from ETH to a stable and vice versa. Anything of more complexity such as yield generation etc., though it will be very interesting, I think the main utility is to be able to accept funds in a stable currency and be able to move between the two.

**nicholas**: Given the recent scares about USDC and DAI by extension, do you think of that as something that's strictly going to be tied to a specific stable like DAI or by doing it once to enable any stablecoins.

**jango**: It's more of a frontend prioritization problem than a contract problem. Open to whatever, just some stablecoin be it USDC or DAI, I don't know. It depends on what people want ultimately, but as of last week, at least I would say DAI is a good bet and we definitely need to re-evaluate that.

**nicholas**: Just thinking to the future if Maker DAO gets blacklisted or something.

**jango**: That would be very unfortunate.

## Juicebox with on-chain governance by 0xBA5ED

**0xBA5ED**: I've been thinking about having a Juicebox project and bring it entirely on-chain. But I think a big pullback for projects is that it's pretty difficult to set up, in a way that's entirely correct, because you can't make any small mistakes, or you project is pretty much gone because you can't recover it if the governance doesn't work.

So we've been working for, at least this week, on a little helper contract to simplify setting up a project that's entirely run with on-chain governance. I have it running on Rinkeby right now. It says Juicebox, but I just copied the metadata.
This is [a project I created](https://rinkeby.juicebox.money/v2/p/4551) an hour ago. Everything still works here you can just mint as usual and get tokens, but the tokens you get has been changed a bit because it supports onchain governance. This is the [page where you can manage on-chain governance](https://www.tally.xyz/governance/eip155:4:0xCb06eF0B686A306095e2cCFaAF7ee32b9e8744a9).

**jango**: What would submitting a configured transaction look like?

**0xBA5ED**:It pretty complex because you have to fill a lot of fields. But I can show what just doing a proposal looks like.

**jango**: It's kind of like Etherscan I suppose. Or Worse.

**0xBA5ED**:Yeah， it's like Etherscan, Pretty much. So let's see proposal.

We'll need to find some way to make this a bit simpler. It's pretty much like Etherscan and it's a bit too complex, but you'll be able to build transaction that has to happen on-chain. There is a minimum amount of tokens that you have to hold in order to be able to make proposals, which is just to stop spam. Right now, I think it's a hundred tokens. Then you'll be able to configure a proposal which contains some transactions that have to happen on-chain. And you can publish it onchain, once it's published, everyone will be able to vote. This is the voting interface，and we can see the transaction here. So this mints 100,000 tokens to the governor, the governor is the wallet that controls all the assets of the governance. I can vote here, I can say 'for' and submit.


**jango**: Shout out to [Tally](tally.xyz) for this sweet generic UI around the governor. That's very cool. Also, this is an interesting tool on the toolbox alongside @jigglyjam's Nance efforts and @twodam's [Juicetool](juicetool.xyz). I don't know if we've seen an onchain governance Juicebox treasury yet, and we haven't made it easy for people to do it, but we're certainly building up a tool suite of governance possibilities. The whole point of Juiceboxe is that you can start fairly open-ended without much structure and evolve from there and this seems where a lot of projects that want to decentralize in earnest are going to tend towards. This is like a great great starting point.

**0xBA5ED**: Yeah, it's still hard to set up right now, but gives the projects more ways to configure. One of the big downsides of course is that onchain voting is expensive, so it isn't feasible for a lot of projects. But there might be a few of them interested in using onchain governance. The GitHub repo of this project is [here](https://github.com/xBA5ED/juice-kickstart-governance)

**nicholas**: I would love to see a project like this on Mainnet both so that we can point to it and dogfood it. And who knows, maybe even sponsor it as a DAO in some small way like an art project or something?

**0xBA5ED**: Yeah, it'll be cool.

**jango**: Yeah, I support what @nicholas said about maybe deploying a Mainnet project governed by one of these and dogfooding it. The whole point of it is that you can even ask for funds from the Juicebox DAO for further development or whatever. Try to stress test it using it ourselves so we know what the points of friction are.

**nicholas**: Yeah, every time we talked about Juicebox, people would ask who owns the project NFT etc., and our answer is always that no one, to our knowledge, has yet given it to an onchain governance contract. So I would love to have one on-chain to point to and the dogfooding for sure I think would be invaluable. I feel like the natural choice here would be to do some kind of NFT art, something project could be fungible also. But something that would motivate a few people to spend gas to participate in the actual governance would be cool.

**filipv**: I don't know how helpful this will be, but someone submitted another automated governance type thing using ERC-20 votes token. This opens up governance stack for the Scaffold-eth hackathon, so I've dropped [the link to the repo](https://github.com/ecmendenhall/jbx-governor) if you're interested.

**nicholas**: The other thing it makes me think is, in this you're using ERC-20 votes, ERC-721 votes off the back of NFT rewards would be another interesting possibility.

**0xBA5ED**: For sure. We also have the VE tokens of course.

**nicholas**: True, although I guess it would imply that there's already an audience if only you can auto-stake at mint time or more or less?

**0xBA5ED**: Yeah. You could.

**nicholas**: That is interesting. So you're paying into the project to get VE tokens, which are ERC-721 votes in onchain governance. That could be an interesting stack.

**jango**: Yeah, I wonder if auto-stake would be a decent move, it would be interesting to keep the tokens fungible and have a deliberate opt-in for governance.

At the same time we're building all these accounting tools, it will be very nice to run projects that use them, at least experimentally. I think we're building up a really sweet powerful stack of tools now, but I'm very interested to see these be useful for conversations at @0xSTVG's end on doing onboarding calls and whatnot. We're really learning about what the community wants to achieve and now we can serve a few options which may be overwhelming for people. Maybe we can tend towards some standards or some best practices.

## Blunt Finance with @jango

It's another experiment using the protocol that we've been working on for the past couple weeks, @Jacopo and I. And there's been some pretty sweet progress. We want to just share with folks to get some feedback and give you a sense of what's going on.

The idea is called [Blunt Finance](blunt.finance). @Jacopo reached out to me that [Slice](slice.so) is thinking about figuring out how to make a VC round work with Juicebox, as in how do you go to folks who are thinking in terms of term sheets and other formalities in their head but they want to participate in support builders, particular Slice in this case.

In talking to them, @Jacopo found out the most interesting mechanism to leverage here is the reserved rate. Essentially what we want to do is create a system where you can create a blunt round like a funding cycle, let's imagine it's funding cycle 1. So you just launch a project, basically anyone who contribute during funding cycle no.1 is going to get the project tokens as usual, but they're also going to get a piece of this other data structure, in this case is serviced by the Slice protocol. So everyone who contributes in funding cycle 1 and the funds are routed to an address, then in funding cycle two or in subsequent cycles, you can basically stick that address as a reserve rate recipient. So everyone contributed in funding cycle 1 has a slight more privilege apart from just token issuance, but they're also part of the reserve rate in perpetuity or to the extent that the project owner sees fit.

I'll do a little screen share and I'll show you what this looks like, the prototyped form.

*@jango sharing screen*

So essentially this just wraps in a very similar way to how the NFT rewards wraps the deployer. This also wraps the deployer and adds a pay extension. And so we're starting to create these patterns that we'll start getting comfortable with and reusing, which is really exciting.

In this case here, we're going to create something that we're calling a **blunt round**. I'll just use Slice as an example. Similar metadata to juicebox.money. We're going to allocate a percentage of future rounds reserved rate that are going to be allotted to everyone who contributes in this blunt round. Let's just say 15%, if you're pitching a VC or something, you can create an open round for anyone to contribute but a VC can maybe lead it, to some effect. In so doing they will get the project tokens, but they're also going to get a piece of future allocations, in this case 15%. And under the hood, this is a chunk of the reserve rate. It's obscured from the onboarding here since all we care about here is determining how much of the current round are we going to reserve for the participants in future rounds.

If you want to do advanced stuff, you can set more funding cycle parameters, such as a duration of 14 days, a target below which the treasury will automatically become redeemable in the second funding cycle. And you can also do a hard cap which basically means if you contribute, let's say 1 ETH in this case, in the hard cap of 300 ETH you're guaranteed to get 1/300 of 15% in the next round. Otherwise if there's no hard cap then anyone can go in and your percentage of the 15% will be slightly diluted. Although you also be able to get a refund by redeeming your tokens for some of your funds back.


So the project still got its full amount of funds, but every contributor was diluted by every other contributor so they could only participate to the extent that other people in the world chose to not invest in this round. And you can issue token do the token issuance stuff as usual, project logo and links as usual.


Also you can add more reserved participants which you can put right away in the first funding cycle. That way, as people start to funds in, there'll already be funds accumulating for the participants in the funding cycle 1, which is basically just added as extra tokens. But in the following cycles, they'll just get part of that growth.


And then you can add other beneficiaries to fill out the reserve rate. I think the pie chart will update, and we're still playing with some visuals and stuff trying to get this real skinny and real.

The idea being when this prototype is done, we'll deploy this project and fund it via a blunt round. You'll probably see a proposal soon on how Juicebox DAO can participate in the first blunt round of Blunt Finance. We can start forwarding people into that UI, if they want to operate a project in this fashion and participate in the growth of Blunt Finance going forward via the allocation.

There's a lot of future stuff that we can do with reserve rate allocations to groups of token holders via tools like Slice. So this will be a good prototype for that as well.

**@Jacopo**: Another thing that you haven't shown yet is just the review part where you can just review how our round would look. This is something that I got inspired from Juicebox, of course, with the progress bar and everything.


**0xSTVG**: By building this out, do funds go back into the Juicebox DAO, or is there a different treasury that holds any fees associated with this project?

**jango**: There are no currently programmed fees that we even thought about the Blunt Finance project itself. My intuition is that it just routes any participation, whatever that means, back to Slice or Juicebox DAO whoever else participating. I think it's open-ended we could do some other experiment there too, but there's no particular extra value capture just in this onboarding thing off the bat.

You can imagine the project itself maybe keeps half a percent of whatever the round allocation is, to make it worth growing out the ecosystem. If you route it to a Juicebox project, you can basically charge whatever fee you want, and those who pay it have a constant option to redeem and get it back at least in part. I don't think there's any shame in adding a fee here as long as it's run through a system that isn't going to be extractive.

**filipv**: Is there a public repo where we can follow along?

**Jacopo**: [Here](https://github.com/jjranalli/blunt-finance) it is.

**jango**: The contracts are [here](https://github.com/mejango/blunt-finance), it's a pretty simple copy of the NFT rewards but skinned down and added with the hard cap. There's still work to do obviously, but it's been refined enough to put out there so that we can all play together.

**filipv**: Is there any sort of project page yet? And if so, how is the the metadata being handled, is that a portable juicebox.money metadata?

**Jacopo**: Yeah, there are some very working progress around pages. With [this link](https://blunt.finance/round/1), If you change the url to 1 or 2 or 3, you can see three different configuration. But to be honest, this is just a bunch of components that I've put there and they still need to be designed properly. But you probably get the idea of how we were thinking of making it look really simple and blunt.

The other question about the metadata, the metadata is gonna be the same as Juicebox V1, so the same thing that you're gonna see on Slice will also be on Juicebox.

Thanks to @jango for proposition for the tagline, it's perfect.

## GPLAY ARCADE with @Sayid

**Sayid**: Hello everyone, I'm Sayid, I was blessed by 0xSTVG to be introduced to Juicebox. I've done some dev work building something out, but never really joined any. I didn't know the communities would be as strong as this, and it really is vibrant with building talents.

I'm the founder of a player platform called [GPLAY Studios](https://gplaystudios.live/) that I want to show everyone and ultimately contribute to the treasury, find a way to tie back in the players DAO so that the treasury can build up and we can fund projects, or ultimately can get my project funded using the tool that @jango was just showing.

**0xSTVG**: I want to really quickly say that, I met @Sayid on Twitter, saw what he was building, had a call with him on Sunday, played a game and really wanted to just welcome him with open arms because he built this out. I figured he'd be great to be introduced into Juicebox. Thanks for being here.

**Sayid**: Definitely grateful, Steve. Thanks. So much. So I have been building over the past couple months being solo dev, I basically founded a P2E(Play To Earn) arcade platform where I want to have an arena where users can come and stake $Matic in classical games such as tic-tac-toe, checkers, chest and basically wager against one another by playing games.

*@Sayid doing a Demo，by playing a game with @0xSTVG*


All that's happening on-chain is an actual contract going on where we both send one $Matic to the contract, and this is where the Juicebox treasury can come in. The winner is gonna make 85% of the transaction when the game is won, the game master, being my company, makes 10%. I was thinking of giving the Juicebox treasury a 5% stake in the games that are played on the platform so that the juicebox treasury is actively added into capital raises which is great.

**0xSTVG**: Here's the thing that I just was blown away by when I saw this. If you saw in the last screen, it says the NFT holders get a share of the revenue. So what I told @sayid is if you deployed this project on Juicebox and use the NFT rewards, you were offering 5% of all of shared revenue of this game, how much is that NFT worth? It could be 50 ETH, it could be 100 ETH, It could be whatever it is, but it's gonna be a lot, because if you're playing this on your phone if you're playing this at work, if you're doing all these different things, it could be millions of games played. And he's building out other games checkers, chess etc.

It's a perfect opportunity to use the NFT rewards deployed through Juicebox and if he wants to changing the configuration to give a 1/2/3 percent to Juicebox itself to help potentially build out things like deployment on other chains etc.

**Sayid**: Right, having an automatic smart contract pay out the Juicebox treasury to build up other games is definitely a valid price. I am builder in this space and I'm passionate with all the projects that are coming out. So I definitely want to see other games being built or other projects being funded. Literally games could be powered like other projects can be powered by games being played. And that was the best I can think of contributing to the Juicebox ecosystem and the web3 space in general.

**0xSTVG**: I'm really pushing @Sayid to deploy this on Juicebox and get this thing up and funded and going because I think this is what Juicebox is built for, things like this.

**Sayid**: Thanks so much. And that's exactly I'm gonna do. I want to help out anywhere I can. I want to learn more about how to get it set up with Juicebox. My question is about Blunt Finance, is that a project in the works right now? Is that where we'll deploy?

**jango**: The Blunt Finance mechanic is a convenient frontend to help deploy projects on the protocol, but all that stuff is doable via other UX. It's not as linearly driven towards this as everyone who contributes in the first round has a part of any future reserved allocation.

If we want to design that mechanic prior to that site is up for use, the biggest blocker that I see right now, as far as the game revenue being actually accumulating in a community treasury, is getting the Juicebox protocol on Polygon in a way that makes sense. So the discussion has been happening here [multi-chain Juicebox](https://discord.com/channels/775859454780244028/969921228435501076). There's a lot of different strategies being proposed being talked about. I don't think anything is exclusive. I think we're all a big fan of trying stuff and seeing what feels good and learning along the way and eventually converging on wherever people converge.

I think if we forget about technicalities and we just try to solve for a use case, maybe we hyper-focus on this game, or last week I proposed like how might we give [lens accounts](https://twitter.com/LensProtocol) on Polygons superpowers.

So how might we solve the problem directly for the lens ecosystem then it might inform what a first take of running Juicebox on another chain is？ It might just be like: "let's just YOLO and put the protocol there and then figure out how to get all the community aligned by making sure we share tokens in a reasonable way among all the token holders", just to actually put energy behind whatever you're doing without a lot of waiting around for a perfect structure to emerge, which is a little bit more of a delicate strategy than to just try to spin these up without having to keep a big manager duty for Juicebox DAO to keep track of. But the multi-chain will follow along with that thread.

**0xSTVG**: I don't know if this was a conversation that was completed, but I remember @DrGorilla and a couple other people were talking about converting the JBX on-chain. It was something about converting the JBX as if it were minted, basically saying which is the better price. Would it be possible to take the $Matic that's earned? Let's say that if this was something that was contributed to Juicebox, I could took the Matic, converted it to ETH, and then deposited into the Juicebox project?

**Sayid**: Yes, that's what I was thinking, if there's cross-platform ways of converting $Matic. Off the top of my head, I'm not sure if you do automatically, but I'm confident it could be sent to a smart contract that is then swapped for Polygon ETH and then there's bridges that send it over to Polygon. So maybe it's not like directly deposited into the ETH treasury, but there's definitely a way to get it done. That thing is just as valid.

**jango**: Totally. Yeah, there's a couple places in this thread that have outlined a bunch of trade-offs of a few strategies, which I'm sure there's the versions of it that we should add to the list. It might be hard to pick off of just by scrolling through the thread, so we should do a better job of keeping a source of truth with the current thinking. There was quite a bit of activity this past week in that thread, let's just make sure to keep it going because I think we're converging on something interesting, an interesting first experiment to try without necessarily burdening ourselves with the future of Juicebox DAO or something daunting.

Let's continue the discussion there. And hopefully someone, well I say someone because I feel like it's as easy as someone says: "let me like deploy the protocol there and try to create alignment between these communities", but maybe actually labeling it as a deployment sponsored by Juicebox DAO is healthy within the day. So there might be some social considerations alongside the technical ones.

I know we don't have like a formal meeting on Monday at this time, but we could try to get a bunch of thoughts together and then do a brainstorm with a couple leading candidate ideas in the coming week. Maybe shoot for next Monday afternoon or something.

## Thirdweb shoutout with @nicholas

**nicholas**: For how to create NFT drops with [Thirdweb](https://thirdweb.com/) and point their primary and royalty revenues at a Juicebox project, there is a new [video tutorial](https://youtu.be/9LHVt2xgTNg) on Youtube

and here is [a text tutorial on the blog](https://info.juicebox.money/blog/juicebox-thirdweb)

If you know people who want to help fund existing projects, or create new projects and they can't wait on NFT rewards，or they want to do combos of selling an NFT and then maybe if you buy 10 at once and it triggers the first tier NFT rewards, Thirdweb is a really great choice.

Compared to the Zora tutorial from last week, Thirdweb is better because it doesn't charge a 5% fee, in fact the charge is no fee and has a greater variety of contracts that you can use. Their interface is really slick. They have lazy minting built-in. You can do multiple phases of drops with different prices over time for the NFTs. And it's sort of developer-centric, but you don't need to be much of a coder. They'll give you just an embeddable iframe, you can copy paste into a super basic HTML page to create a custom mint page for yourself.

So the Thirdweb piece is really nice integration. I think super lightweight even if around the DAO people want to do little drops here and there for things, super cool. and also helped tease out this logic of "you don't need to be a project creator to send revenues to a project, the NFT mint".

**filipv**: I think more tutorials and guides for simple websites for people who have a little bit of technical know-how but don't want to write a contract from scratch will be super useful. This is super exciting.

**jango**: Yeah, they're incredible. I think we'll see the effect over a long period of time as projects come online and then it enables the whole community to actually participate in an effort to fundraise as opposed to just chitchat on on a Discord server in hope for someone to build the infrastructure to allow them to post whatever the hell. This is awesome. Very useful.

Also shouts the whole web3 space for building the hell out of infrastructure the past year and a half, because all the stuff was not out there last summer when we were trying to figure out what the hell do SharkDAO stuff.

## The Buidl Guidl Hackathon feedback update with @nicholas

The Scaffold-ETH Buidl Guidl Hackathon, all nine teams have filled out the post-hackathon questionnaire. We'll be distributing 50,000 JBX to each of those teams according to the recently approved proposal in the start of next funding cycle.

There'll be some new builders who hopefully will come hang out in the DAO. Maybe we'll even spend the time to try to figure out and track if they liquidate their position or vote in governance, as a gauge on whether it's worth doing this kind of participation based airdrop for hackathons in the future.

## GitHub Governance with @jigglyjams

**jigglyjams**: It's just under my personal account right now in Juicebox governance, but the idea here is I've been pushing proposals to GitHub from Notion.

These all started when we needed a place to store translated proposals. So I started putting them in [GitHub](https://github.com/jigglyjams/juicebox-governance) as created to display things because I don't really want to build front ends right now or anything similiar. So we started putting translations in here under the language. The translations are all done with [DeepL](deepl.com) which @twodam suggested a while ago. Essentially you go into each cycle and you'll have a table of everything in that cycle, have a link to everything similar to Notion. It's also shows total votes and then like the outcome of `for` and `against`. I got to throw in a translation link here still, but it will just take you to the proposal itself in markdown so it shows nicely in GitHub.

There'll be a complete database here, just everything from all the cycles. I haven't imported everything yet, we could do that if you want to see how it'll look over time. When the vote is complete you can see just everything will be updated and added to all the tables. In addition, I'm creating this database JSON file which has everything like metadata for the proposals. And I figure some interface could be built off of this at some point without having to query Notion and Snapshot for result of votes etc., so you could just call from here, download it, and play things however you would like.

My question to the DAO and why I've wanted to get up here is: is this a path people like for playing things in GitHub, do we want to do a pure IPFS approach? Any feedback that you have will be much appreciated.

**jango**: It's definitely a clear place to start. It's very nice having an actual change log in history to go through. This is obviously going to be in demand for a lot of projects spinning up who already progress. So, how can you make this as we build it for Juicebox DAO? How can we make it to just a flip of the project ID to make it accessible for others as well? If they use it on their way to experiment with different things, even better. It's awesome to have on the table for people to use and it'll for sure solve our problems.

**jigglyjams**: The next thing I am gonna look into is just a super simple frontend to push to GitHub so we can knock out Notion, thinking about how Nance integrates with other DAOs. Having a heavy Notion reliance sucks and I don't want to push DAOs to have to do that. So I'm doing this option first with a simple frontend, you would select a type of proposal and the formatting will change depending on what kinds of proposals you're pushing forward.

**jango**: With regard to the frontend stuff, I'm curious how people perceive the legitimacy of these options when starting up Juicebox projects. I feel though interacting with juicebox.money through the onboarding process and through the settings menu in that dashboard, it feels like "Oh, this thing is built for Juicebox." Whereas maybe pursuing or finding it via the docs page or via a word of mouth, even though the functionality is the exact same thing, people might approach it with one grain of skepticism extra. I think this is like an unknown research that we could do at some point about how the general people interacting with the protocol and these tools derive a sense of legitimacy as they choose their tools to solve their governance problem.

**filipv**: Even simple things like styling and domain name could really play a big role in this. You can imagine something that looks like juicebox.money hosted at governor.juicebox.money or something would give a decent sense of legitimacy.

## Two Truths and A lie with @Felixander


The correct answer is ... Jigglyjams

The lie is "I've hiked 43 of the 50 highest points in each state(USA)."

## Updates with @brileigh

Last week, @matthewbrooks and I recorded two Juicecast episodes:

- The first one was with @kentbot, which was awesome. We got the first edit cut for that, so we just got to master it, add in some music. I will have that launching this week.
- And then we also did one with @seanmc from Joke DAO, which I'm really excited about.

We're also in conversation with [Pablo](https://twitter.com/LarrotizPablo) and [Kori](https://twitter.com/korigrogers) from MoonDAO. We're gonna arrange a time to do a call with the [Dude Perfect](https://twitter.com/DudePerfect) guy ([Coby Cotton](https://twitter.com/CobyCotton)) that actually went into orbit last week, we think that would be a really sick interview. Dude Perfect has a huge community behind them, so we want to leverage that community and join it with Juicebox.

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