Warning of Influx of new members.​

filipv: On June 7^th, the Discord server of JuiceboxDAO was faced with a big influx of new members from Indonesia. According to @Zeugh, they came from several big Telegram chat groups that are mainly focused on airdrops. There might be a misintrepretation that if they create a project on rinkeby.juicebox.money and give feedback in the Discord server, they will be entitiled to some kind of Juicebox airdrop. We don't have any airdrop currently.

Zeugh： I think it won't do any substantial harm to JuiceboxDAO, and think it a great opportunity to showcase the functionalities of our protocol to these people, and to onboard some new members who are really interested in our products.

veBanny Front End updates by @Jmill​

Jmill: I have been working pretty extensively on the veBanny front end, trying to get it out the door. Now that the contracts are deployed, we can work to transactions and use real data.

(sharing screen and demonstrating the process of staking tokens for an Locked NFT)

So we're now minting this thing through the website which is cool. The stuff is all working now, and show up pretty cool.

jango: I've also been on the contract side of things that @Viraz has been doing a great job, asking for reviews over the tests. The tests he's writing and adding more fuzzing tests to the suite. So hopefully at this point, it's throwing a lot of use cases at the cocept. And i suppose it'll make way on to the actual final details to complete the workflow.

Jmill: The big thing next is to read the onchain data and get the use of NFT, and then allow them to extend their locked positions on a particular NFT. All of those are related to fetching data, about multiple tokens. We're talking about this in Peel's Discord, and right now it's implemented as ERC-721 Enumerable, but it'll probably be easier if it were structured similiar with Juicebox projects where you have a directory structure and subgraph, to look that information up without recursive calls to open by index. So that's probably what we need to start thinking about how we index these information for the purpose of front end to grab it and work with the data.

jango: Yeah, that makes sense. Also from a juiceboxDAO or Juicebox perspective in Juicebox.money, we'll possibly first have to deploy their staking contract and specify the lock duration they want etc. It isn't going to be there for everyone first, they have to specify those things, so that that initial transaction to deploy a staking contract will go through a contract that somewhat serve as a directory or at least it'll file an event that's indexable to service a directory. If Peel and Juicebox.money feel it a decent thing to offer all projects over time and they should be able to interact with that same depolyer contract to get their own version of this.

filipv:What's the timeline looking like? Is that somehting we can expect deploying in the next month?

jango: We need V1 > V2 migration to do it for JuiceboxDAO. We can deploy this for an arbitrary project though. We can launch a new project and just has it work there, so you can start minting stuff, just as normal treasury and lock it there, at which point there's not much difference between test and rinkeby as we currently are. But to get the JuiceboxDAO version of this and the Bannyverse version at least from a ecosystem perspective, we need to get V1 > V2 migration, and then there might be other technical things along the way.

Jmill: From a front end perspective, there are a couple of things that would be helpful so that there's some kind of indexing data you can easily pull user's NFT statistics. That's a more simple and scalable way to do with subgraph query. It would be really usefull if the ve NFT contract deployer also deploy a single consolidated metadata file. Let's say veBanny has 60 characters and they all have a name and staking ranges, it'll be really nice that the contract generate that as one file that front end could grab and parse to display without going to 60 metadata files individually. That would be a quality-of-life thing from the contract side for the front end.

tankbottoms: We could add another function for that metadata, basically something that will conform with an NFT but also has pointers to all assets you need, because you can pick them through the JSONs however you want.

Jmill: The last item I have here is that we're implementing beneficiary for this, so that users can stake and put someone else as the beneficiary.

jango: That'll be useful for even a DAO to lock its supply, and designate other contributor or some other beneficiary for. It's cool to have flexibility. The core thing being built allows everyone on the peripheral of the project to start to wrap their heads around what situation it's gonna be when this thing is out there.

Product prospective with @Zeugh​

Zeugh: The Juicebox.money is a complex thing to use. I think it will be something to see that front end are more focused on some type of projects. Let's say there's a NFT project wants to launch its treasury on Juicebox, they can have a direct way for easy launch to help set it up ahead of time. You want to launch a NFT project and make the funds through Juicebox so people can co-own the treasury like tileDAO did and issue tokens for people that are minting.

Those are some of the configurations that we think we should do. That could be something like Juicebox.nft instead of Juicebox.money. And if you want to go to the hard mode and be able to configure every single thing, that's still running on the same protocol.

That's what I call the product prospective. We have a very good protocol perspective here that is building something really robust and can do lots of things. In the end looking at product level, maybe not all the users will need all of these things and having an easy way to launch might be something interesting.

jango: I think there's a lot of to keep improving the onboarding stuff and especially we just came out of V2 trying to start with parity where V1 was. The name of the game now is just constant improving based on our own interest with onboarding as well as pulling together other people's perspective. It's hard to be certain that it's one thing or another thing from my point of view, but without question we're going to hinge towards better alternatives to prototypes that are massively useful. Shout out to JohnnyD and Aeolian and all the people in Peel who are eager and quick to make prototypes and start discord threads so that we can discuss the improvements. And then match this with a occasional AHA moment that a few different ideas come together that make sense to a lot of folks and somehow we unlock a lot more fluidity to the onboarding process.

I'm certainly with you that we have a lot of work to do with explaining what people are getting into, like starting with giving everyone all the information upfront and make all risks as clear as possible. Overtime we can start to reel back into some managable shortcuts.

I think now we're definitely buckling for more long term investments both from a building perspective and the relationship perspective with other communities. I'm eager to see how that project chart changes over time. I think from my personal perspective and talking to projects, the recent lows haven't been very encouraging for projects to launch. But now that V2 is out, we're going to see a lot more of that.

nicholas: When I did onboarding with Austin from BuildGuild and he had some feedback about simplifying. It's a little bit difficult for someone on the outside to know exactly which simplifying approach will be successfull on the market aside from just iterating on simplifying the existing one. But I do have some suspicion that there are a larger category of people who are not so inclined to use Juicebox in its current form but might be inclined to do so for this example we're talking couple of times about NFT collections, splitting off a portion of their primary and/or secondary to Juicebox and letting the holders manage it, which doodles, cryptopunks and a bunch of other projects already do. That's a category I'm super interested in getting on the creation flow for that. It could be just like presets on what we've already got, or maybe an entirely separate creation flow where you can imagine entirely different front ends that just make creation really tight for a specific use case and then you can go use Juicebox.money's full advanced front end and subsequently managing those things but make it easier for people to get onboard. It could be pretty integrated at Juicebox.money. There's a lot to explore.

filipv: One thng that we've discussed that might be interesting would be if there's a way to easily import and export project configurations which Austin Griffith originally brought up, for exporting a project that was made on testnet to mainnet. That might be cool because you can use that feature to set up templates that have base project configurations.

Another thing I want to talk about is what we're discussing a lot in the chat about amount of metrics. I'm not sure how useful focusing on any specific North Star metric would be. It's very hard to encapsulate everything in Juicebox, and I think everything is conflating with each other. So I think we can take anything and roll with it, but I don't know if it's worthy going super deep into which is the best North Star metric.

Aeolian: I'm totally with @filipv. I think the goal I originally had with proposing this metric was not so much like "ok! Let's review this number every week!" or "Oh! it's going down, what's happening?" It's more like what we're all in some sense collectively optimizing for everything from a product, website, documentation and content strategy, the whole thing. Our goal right now is to increase the number of active projects. I agree with you that at this stage where traffic is still very low, really trying to hatch out a metric that's instructive right now. It's more to get us all on the same page.

jango: I think the general consensus is that it feels good to have activity. I guess you could put on a chart and optimize for it, but personally I want to think about metrics that make me lean in more in moment's notice seeing activities, and seeing folks I know engaging with other projects making me want to learn more about them.

Govenance discussion​

@filipv: I want to open up some discussion on the recent governance cycle, both in itself and some of the proposals.

One thing I want to bring up first is the possibility of changing the governance cycle in order to allow for longer temperature checks because I definitely feel the temp check are too short. But there's also balance if you lengthen the temp check, it makes it harder to get things through the governance process and it takes longer to get things done. We did a poll and people are really into the weekday idea.

nicholas: Since people prefer temp check ends during the week, I'd particularly like the proposal edit freeze to happen during the week, because I had to spend a lot of Sundays modifying proposals because people obviously just give comments leading up to the freeze and I prefer it end in the week. I understand people have jobs and I am certain that might not be convenient, but people from the poll seem to be happy with that idea.

jango: For me personally, it's nice to end on weekend because I can do a lot more meeting oriented and dev oriented stuff during the week, and in the weekend, I can read the proposals and think about those. There's not much weekend breaktime.

nicholas: How specified should proposals be? I made a suggestion that is three points if you add them to the proposals, maybe they will enable more delegation, because a lot of the burden getting the proposal through can be like knowing exactly what steps should be taken, when it's not always necessary DAO knows every single steps if DAO is willing to accept the risks, the implementation risk of someone delegating it to the person who's the author or someone specified in the proposal. I think it's a decent choice if it's a better financial allocation and also adding a risk in risk section which is like "Look, we're not specifying the address the money got set to, we don't think that's a super important detail for the DAO to be voting on", but that's a risk we can screw up sending it to a wrong address because it wasn't specified in the proposal. It allow the proposal to move forward before all those details are sorted out. Some proposal do deserve to have hyper detailed specifications and it's important for the DAO to vote on it, others delegation will be more appropriate. I think that might be a interesting format for making governance more manageable.

filipv: I'm definitely onboard with that. I think that thing need to be weighted very carefully just because it's not like we are going through a hierachy and people are revising it in every step. It's kind of like every proposal goest to the multisig like the one source of truth. It's like something running close to the middel very powerful and very dangerous. I think we need to be careful about specifications and and we don't want to lead to some DAO crisis when people are disagreeing on an interpretation of the proposal after the fact.

First of all it waste a bunch of time, also people are gonna get upset and may lead to conflicts. So I am generally more of a stickler that we should have very specific proposals just because how dangerous it is. I wonder if there is a way to incentivize people to submit a bunch of proposals earlier so they can be spread out ever a greater period of time. We really see most proposal submitted close to the end of temp check. It's not an easy question to solve.

nicholas: Part of the challenge is the 14days cycle, if you would like to submit a proposal for something and temp check submission just opened, that means you can no longer submit a proposal and you could be waiting for 20+ days till the next opportunity to vote. It may be worthwhile, for instance the bug bounty, I can see both sides on it, maybe a longer process allow us to consider, but at the same time, the protocol needs the bounty pretty badly.

I think it would be of some value not entirely in the direction of everything being specified because the reality is that just making through all of that governance and having opinions on it is stretching the limits of the bandwidth of even the most dedicated members of the DAO. It also becomes less decentralized the more because people are just voting along with other people who have already voted. There's also some needs to us to recognize that actually the DAO doesn't need to vote on every single details of everything, and some amount of delegation is probably gonna be necessary over the medium term.

filipv: Two thoughts on that.

One is that I don't see why we couldn't do it right now like approving a budget in advance to reduce future governance overhead and go through that process. I think that's very achievable and I'm interested in pursuing that.

Second thought is that jango has be mentioning lately the idea of possibly pursuing funding for projects and budgets for projects rather that fuding budgets for individuals or groups, which I think compelling because the structure of what we are doing shifts a lot and it's the post V2 transitory period. So I wonder maybe a shift towards budgeting for things get done rather than having all these smaller individual small group proposals may accomplish what you are talking about being able to improve things in advance and delegates to someone who's leading the project.

jango: Some of the treasury allocations have also been tricky in the past weeks because we've been tuning the treasury create stuff on and off while we address some protocol problem. Those should be made well in advance in proposals being specified to be directed towards them. I am definitely in the camp of more hyper specificity upfront and throughout the temp check process.

filipv: Would you want to work with Juicebox if you didn't get funding through an individual basis, but rather as a part of multiple projects?

jango: The end of payment routing is still individual payout, either from a project that you control like what JohnnyD has, or through a direct payment from a project. The idea is that it's just not managed by a conglomerate governance system.

felixander: I want to talk with JohnnyD and Aeolian about this. What happens when you bring a human on for a projects and the project is solved? It doesn't make sense for the system now because we've committed a budget to something that only took 2-3 months, but now somebody is there, but they're taking on another work that might be totally separating them from what they're doing. I think it's something a little bit messy in terms of how the payment structure works presently.

jango: I feel that kind of work is really important when a project is starting out, that's still the case now and will likely still be months into the future. There's a lot happening and everyone is contributing to whatever the next person needs. So people are just shouting "hey I got this dope thing in progress, it'd be sweet if I could have this ounce of help" and luckily there's a lot of people around who are eager and feeling supportive to do that work. So the individual payouts feel appropriate in that world.

I think that would set the expectation that there's a lot of stuff that we've building isn't just onging forever, we're not hired by JuiceboxDAO to be here comfortably and feel valued imbued and viewed by our relationship to one another and to the concept of the projects. Once those projects play themselves out, I think it's healthy to reassess what our purpose is amongst current state of the projects and how we can prepare ourselves for future state of uncertainty which are always upon us. That's the thing we can almost guarantee.

felixander: Would that be the same way like Peel, WAGMI and Canu, the idea that people would branch off like Peel now is under a budget to do front end? You could imagine people who are doing docs would branch out and have a budget, and people who are doing translation would also branch off and have a budget.

jango: I think that's in a creative part and I'm sure everyone will bring their own taste of how to frame these things. It's effective to pay Peel to work on the Juicebox.money project, front end developers can assess each other's contributions and payouts better than any multidisciplinary group would.

These things will inevitably shift and change over time, as people come and go, as well as the projects changing. It's tougher for the community to rationalize consistent budgeting for an abtract group of people with an abtract but pointed mission, the individuals are liquid between all these project organizaitons and we hve to respect that. People are going to find their leverage over time and they don't owe anything to any organizations. We're all just building ourselves out and learning from each other in this whole process. I think we're going to see a lot of different ways to organize it.

Shout out to Zom_Bae creating the Juicebox events version for the upcoming ice cream event and it's in a potential to add more longevity to that concept. What if we're to actually trying to fund events consistently and have a pool of resources that we can make this up every single time. We can just re-reference something that we know to be true already.

I think we're on the same page eventually. We've got to create the right incentive model to shift away from building up the Juicebox foundation to supporting one in any numbers of projects and then servie it to the world and make it the gateway. But as the protocol tends towards stability, it'll be great to have tighter articulation of what it means for a project to succeed over time.

Aeolian: I do like what @casstoshi brought up about the idea of each group having a budget and individual contributors are paid from that budget. I think Peel has done this. At a time all the front end people were doing individual proposals to JuiceboxDAO and the sentiment was that it's hard to evaluate these proposals. So intead JuiceboxDAO votes on a single budget for front end and that team can handle that budget as they see fit.

I'll post a link that Drgorilla posted earlier about how makerDAO manages this process where there's a clear budget for each abstract collecton of people. It definitely breaks down as we've seen with some proposals over the last couple of weeks. It's hard to pinpoint someone into one of those particular groups, people can work ver much across thses groups.

I still think it's instrutive not only from accounting perspective but also from an organizational perspective, it just makes it easy to reason about someone's payout if they're clearly contributing to a specific area.

Project highlights​

gogo: I'm very glad to be able to discover the future of ComicsDAO and strategy of what we're gonna do there. We had a super contribution from JuiceboxDAO from the beginning which is pretty amazing.

I would like to share what we just thought. So we basically are doing a full story and the beginning starts with this post here. What I would like to propose is that this is our heroes Banny and they're travelling throught the DAO galaxy to DAOs. We would like to know where JuiceboxDAO would like the ship to go to the next DAO, so that we can keep on building covers to next DAO. Let's create a poll here and vote on the DAO that JuiceboxDAO decides what ComicsDAO is gonna do next.

Another thing is that, we had a big player, this guy is amazing and helps us a lot.

We are having fun creating next cover for other DAO, and we are going to make some jokes for JokeDAO and get partnership to work with them.

jango: That's the coolest part of ComicsDAO. I love the treasury management, a part of which is to buy rare comics and hold thme, but the day to day potential of being the storytelling branch of differnt DAOs, which is immensely powerful. And so far you are all playing really well, well done.

nicholas: There're a bunch of really cool projects this week. JokeDAO just launched a super sick governance experimentation project.

Austin Griffith's BuildGuild got launched this week and there's a proposal to fund a hackathon for them to transform scaffold-eth into something compatible with Juicebox or to build the hackathon projects using scaffold-eth with juicebox involved in the picture. And as jango mentioned in his twitter that Juicebox front end is based on scaffold-eth.

So it's very cool to see comfort circle, and hopefully we will be able to fund a modest hackathon to get the treasury kickstarted with funds, hopefully getting that brew of hackers into the ecosystem.

@twodam's has posted a twitter about this week's projects here.

jango: Super exciting. Thank you @nicholas for doing a lot. Most excited once we get the V1 V2 token stuff, situated to start talking to the SharkDAO, or a lot of folks operating on V1 still doing ongoing work and fundraising, to see if they want to move over and leverage some of the new tools to make their projects more successful, whatever that means to them these days. But I think we're still a little ways away, so getting new projects on is still the name of the game for sure.

Quizz time:​

Oh man, this episode definitely needs a PG rating for sure. I won't compile it so if you are interested, check out recording and jump in to 1h25'00", you're welcome!

And the answer is........

Sage

1. Bug updates by @jango​

@Jango: The same bug update that I presented about last week that we caught about a week ago. As of a few mins ago about 95% got resolved to just the final step of re-issuing the tokens for those who contributed to projects before we re-deployed things.

Everything is being tracked in the postmortem that is the V2 contract repository. I’m very excited to tie that off and make progress on all other stuff coming up. Also project creation is back up.

filipv: I am gonna ask about litDAO specifically. Are they holding back token narration for all projects right now?

jango: We’re gonna run a script to help go through play by play of what we’re doing. We re-deployed basically all the contracts except for Juicebox projects(so they can keep their NFT i.e. the ownership to the projects) and a few auxiliary contracts that don’t have dependency. We re-deployed the token contract, funding cycle store, the terminals, etc. Once projects re-launch their funding cycles, everyone starts from Funding cycle #1 again. The front end made it very easy to use the same configurations as their previous funding cycle in the old contract had. Once they make that, they also have 0 token supply in the new token contract. But several projects have already received funds and started distributing tokens.

The original plan was to have project owners initiate a few transactions to airdrop tokens to their token holders, which is super doable but requires 3-4 transactions and it’s a bit complicated. In general, the scope of the problem is very small, given where we are in the protocol deployed a few weeks ago. So instead, I’m gonna send a few transactions that we scripted after this Town Hall that’s gonna deposit and basically re-created the activities for each project. Let’s say moonmars have received 10 payments each with its memo and it beneficiary of token. We’ll just send those out again. And from the deployer wallet as we run the script, we will pay in some ETH and set the original beneficiary of tokens as a beneficiary. So once all the activities are up again, then the token balance of each project should reflect their old token balance. I’ll open a proposal to refund the deployer.

@filipv: So are we repaying all the balance that all the V2 projects have received so far?

@jango: I think the total will be 11ETH if all projects are to relaunch funding cycles, which is a prerequisite, and then we’ll drop the funds in both as a bonus for everybody for the hiccup, and also thanks for the patience throughout this process. I think it’s better to solve this problem with money, than to cause poor UX, and I think it’s worthy given its scale. But this also taught us a lot about how to solve this problem given a larger scope. That loss is in lieu of communication headaches that cause us to make sure that the projects are clicking the right button and not getting themselves into other nuts.

@filipv: Are we doing reimbursement for gas fees associated with redeployment and project updates?

@jango: Yes. The big one is projects that have deployed ERC-20, which is the most expensive transaction. We have a list of projects that have that before, and we’ll drop in 0.2ETH in their treasury, which is part of the number I quoted before. After this call, I’ll run it and we’ll be super in the clear and make moves towards the stuff we were working on before.

@filipv: Last question, what’s going on with the ETH in the V2 projects right now on the old version of the contract? Can project creators just distribute it if they’d like to, or figure out what they’re gonna do with it?

@jango: For the most part those have been distributed. I went through to empty those out as the UI no longer interacts with them. You can always go to etherscan.io to pull them out. I think litDAO has a 100% overflow, so any funds in there can be redeemed by token holders. So if you did contribute to the DAO before, it’s now a fine time to go and redeem, or they can submit a reconfiguration on the old funding cycle to raise and pull funds out. It’s the bonus we’re going to give them if they want to go to the trouble to get those, which is for them to choose.

Once we found this bug, it was tempting for us to just keep our heads down, mitigate it and try to fix it. But communicating with projects and making sure everyone understands what’s going on is important, so it’s certainly cool to do stuff and prod.

It’s still pretty incredible that we found this bizarrely niche bug this early on. I’m pretty confident here going forward. It’s kind of weird to start and then already have a bug. I definitely understand if there’s a sense of hesitancy. I’ll have to work through that, give it time and put weight on it incrementally and regain trust in ourselves. I feel pretty good about it.

2. Morgenstern’s Ice Cream event by @Zom_Bae and @Kenbot:​

@Zom_Bae: If you haven’t been keeping up, Morgenstern’s Finest Ice Cream is hosting a JuiceboxDAO event for three days over NFT NYC. We, as a DAO, got to vote on 6 custom unique ice cream flavors, which is pretty cool. Check out this link, and submit your crazy wacky creations by June 2. On that day we’ll get a list compiled and vote on Discord for the top 6, which are going to be tweaked and refined by Nicholas Morgenstern himself and then be served at our event over the 3 days.

Kenbot and I over the last week have been really digging into this and finding a way to make it more than just an ice cream social. And I think we’ve got a really unique opportunity here to bring some really cool projects into Juicebox and get them building in the protocol, and also really get the word out for Juicebox.

We’ve been talking for a long time that Juicebox hasn’t really done a whole lot of marketing other than our twitter, word of mouth, and the big one-off projects like ConstitutionDAO and AssangeDAO. We are still in early phases for that, but the ice cream social the way it’s building up is gonna be an event inside an event of NFT NYC. We’re going to have a schedule of things going on each day. We’d love to do some twitter space, AMA and podcast if we can.

Lexicon Devils are making a replica of this event in cryptovoxels.com , which is pretty cool.

So any of you is gonna be in NY for this event and is willing and able and down to be a part of that, I really want you to be.

@kenbot: What we’re thinking about is we can have their windows as soon as we can get going. So we can have a week running up before the event to promote right in the space what we are gonna be doing there. The thought is who do we want to reach out to, who’s walking by that place, who’s in downtown NY at that time, and we want to capture and have them come back.

So that’s going to be ideas that we can have a theme of bringing creatives together, to open their Juicebox projects and fund their dream projects.

3. Stories about BlockSpilt and NFT Berlin by @Zeugh:​

@Zeugh: Me and JohnnyD have been going around for the last week. We’ve started the idea of testing the gorilla marketing tactics, by going to some blockchain, Ethereum or NFT conferences. This time we went to BlockSplits in Croatia and NFT Berlin so far.

1) BlockSplits​

We got to BlockSplit on Tuesday last week. First thing we swa was a panel of legal side of things about new regulations in the EU and it felt like this was the wrong place to be. We came to this event for 2 main goals. The first one was to do some user research, try to listen to people that are creating projects, and try to understand how they currently manage their treasury. And the other idea was to onboard some of them. The event ended up evolving into something we understand as Web2.5. BlockSplit Croatia was more of using blockchain technologies on traditional startups.

Interesting insights from BlockSplit were, there were some L2 builders from Boba network and they were interested in how we can bring Juicebox to their L2. I found it unusual that there will actually be people building L2 looking for people to go into their chains. I talked to them and onboarded them to our server. They want to come on and discuss how they could help a process like this to happen.

Also from BlockSplit, there was a very interesting group called Resolute that focuses on web3 marketing. They got very interested in how we’re doing things and how they can help with that. I am bringing them to our server this week for them to take a look at our strategy discussion and the marketing part.

Everyone got interested in how we are doing things actually, no one has ever seen a DAO actually run and work with a profitable and functional business model.

2) NFT Berlin​

From BlockSplit we flew to Berlin, and NFT Berlin was the opposite of BlockSplit, where most people were not directly involved with a project, they were mostly collectors and fans of the whole NFT fever.

In there we got in depth looks at what NFT creation could use Juicebox for. JohnnyD was amazing in focusing in how we can create better models using Juicebox, some templates or preset configurations that could be useful for NFT creators, to give their buyers or investors more confidence in investing, to make sure that if a rug pull happens everyone has time to pull back. Those features made everyone’s eyes shine.

We got in touch with NFT Club Berlin. They are a big local group of NFT investors and collectors. We have follow-up calls this week to show them how to use the templates so that they can start referencing that in their community.

The experience as a whole was great beyond the event itself. We stayed for the hackathon, helped people on the hackathon deploy or understand something about our products. We got invited for the ETH Barcelona to be part of the hackathon there to help them get DAO hackathon. They are interested in having us as the main DAO on that, because we were one of those that does have an actual toolkit and a workshop and content to provide for a hackathon.

And we faced the problem of gas fee in NFT Berlin again and again, for the fact that we only run on Ethereum was definitely a barrier for some project creators that we talked to.

3) Discussion​

@filip: Do you feel like what you learned from those events changed your strategy? Do you still feel the same way about the strategy?

@Zeugh: I don’t know. I really don’t know, because the strategy has been going back and forth from different talks, so I’m not sure if I have a clear feeling before saying it has changed.

I definitely feel more confident on going projects to projects in an event, just talking about Juicebox, asking what people are doing and how they are doing. I learned better the right questions to ask to understand if we can provide value to them or not, and to learn why we can why we can’t.

I think the most beneficial part was the user research part beyond the few projects we onboarded. I think it was the biggest gain.

4. Quizz time:​

The answer is…… Casstoshi!

5. Hello from ComicsDAO by @gogo:​

@gogo: I’m really excited about the V2 release, and ComicsDAO will be dropping really soon. I have just to create the Gnosis and the multisig, and we’ll be dropping soon. You guys should know what we are doing. We do some cool things already with covers of ComicsDAO. You are all welcome to join.

1. A bug saga by @jango​

Jango: This morning STVG posted at the loose_thoughts channel: What if we could pause a project mid-Funding cycle? He was trying to play with the Marine County Swim Association project(this is a sweet event pulled off by STVG) to pause it since the event was finished. And through a series of botched configurations, the project ended up in a really weird state. The project’s current funding cycle is set to start on May 28th which makes no sense as the current funding cycle should always be active.

So at this point, something is for sure up or at least not served correctly or the front end isn’t interpreting correctly. That’s quick to check. The etherscan.io confirmed that the current funding cycle starts at a later day. I went to check the unit tests and there were a bunch of cases that I felt this was trying to cover and still passing. So I tried to create the situation exactly and was still struggling to do so. What ended up being the exact step to follow to recreate the bug which I eventually found was: if you create a funding cycle or configure a funding cycle with a duration and then let it roll over to the next funding cycle without reconfiguring, now you’re in the 2nd funding cycle, now you’re in the 2nd funding cycle of the 1st configuration. Then you configure the subsequent one, and before the current cycle is over, you reconfigure the subsequent one again to override the previous configuration. If you’re in this exact state, the 2nd reconfiguration, instead of being based on the 1st FC which you kinda rolling over onto, will be based on the funding cycle you are going to override.

That puts us in a weird state. The edge case was not covered in the tests. So I quickly wrote a test and confirmed it, before I found the one line to add to the contract to fix the problem to make the test pass, which I’ll post here:

So once we identified the problem, sorry I'm kind of doing a realtime postmortem here and I’ll write this up later, then we can start to think about the solutions and consequences. Luckily V2 was deployed only recently and there are only 27 projects at the time. And most projects don’t have large volumes in their treasury either, the bug doesn’t affect the treasuries so funds are all safe, too.

All we are gonna do is letting these projects know that this condition exists, and from our point of view, we should probably make the adjustment in the funding cycle store which is a dependency like all other contracts or the core contracts in the ecosystem which is gonna nudge us towards republishing and redeploying the V2 contacts.

It’s not 100% sure that we need to redeploy the project contract, which will be nice with all the NFT stays. Even if we do, we can get in touch with all these projects, make sure they can redeploy on the new version, make sure funds get moved over and make sure token holders get airdropped the new supply of the token.

This comes in the name of diverse conversion stuff we have been talking about. We know we are working with fragile and delicate infrastructure. I am happy to catch this very early on in the process, as this V2 stuff just gets trickier over time. And then obviously if you were to know about it and think about it maliciously, it’s an exploit if you want to use it in that way.

A big shout out to folks involved to kinda come through and help once we wrapped our heads around the issue. Peri came in right away and adjusted some of the front end to make sure new projects can not be created on juicebox.money. And shout out to STVG for clicking a button which you described as chaotic and you weren’t really sure if you miss-clicked a few things, or you did a couple of things twice because you forgot to do it. That ended up showing us the way.

It’s pretty mind-blowing that that was a test case we have yet to cover. And it’s hard to believe there are any more of these lingering. The scope of these contracts is pretty tight. I think V2 actually removed bits and pieces of funding cycles, so the V2 funding cycle store is way leaner than the V1 one. I haven’t checked if the contracts of V1 have the same vulnerability in it, but I actually don’t think they do because that piece of logic got reassessed.

@filipv: Huge shout out to everybody esp. STVG. This is so good that this was found now instead of 3 months from now.

@0xSTVG: I’ll ask my original question. Is there a way to pause? I’m in a 5-day funding cycle, I reached my goal so I wanted to just pause payment even though I am in the middle of the funding cycle. I can’t do that, I can pause it but it’s going to take effect only when the current funding cycle is over. @jango: yeah, you can set up a pay delegate to revert the transaction if you’ve met a goal, you could write an extension that just does that if you want. But by default you can’t. Once we put it on the shelf then you’ll be able to pull it off the shelf and use it, but we have to build it out first.

It feels like it’s at a lighter moment now. Most of the morning was pretty tense on my end at least, and obviously we take these things very seriously, make sure we’re articulating this stuff correctly and documenting that correctly. I think we are still all gonna make it.

All V2 projects on the site currently have a sweet alert on them. Hopefully all the communities running on it, not just project owners we reached out, see this warning and get a heads up for what’s going on. Thank you Peri, for coming through.

2. Demo of veBanny by @0xBA5ED:​

I’ll give a quick refresher on what veBanny is for, as I don’t know if everyone here has heard about or seen it before. So, veBanny is a way to make sure everyone who’s voting in the governance is focused on the long term instead of the short term. It’s a way to lock your tokens, the longer duration you lock for, the more voting power you’ll get. When you do that, you’ll get veBanny NFT to represent your locked tokens.

(Screen sharing of demo starts)

In the future you don’t have to receive the ERC-20 to lock your position. And it allows the public to extend the lock.

@filipv: Can you explain very quickly what a public extension is?

@jango: By default, once you’ve created a lock, then it’ll linearly decrease when time ticks on. Let’s say you lock it for 100 days, tomorrow the lock will be 99 days. So to get the full voting power, which is a function of how many days between now and the end of the lock, you’ll want to extend the lock back to 100 days, which is a transaction that needs gas. But sometimes if you have someone to be able to go in and send that transaction to extend your lock, you can set that flag to True.

If you intend to keep a locked position, maybe you have a voting habit, or someone who can easily afford that transaction can go in and extend it for you. Or if you don’t choose that, we’ll have control over it so you can inch toward liquidity of your position at the rate that you choose. That thing was added as a result of discussion when this was being designed, that a lot of people want to keep their voting power full, but they might not want to be sending transactions regularly and this is precautionary. I don’t know at what frequency people will want to send that extension transaction on their own, but it was a quick flag to add that didn’t open up a lot of weird complexity, so we put it there.

@filipv: Is that something that can be reconfigured? Can I send a transaction to turn off the public extension on a position that I already have?

@jango: The owner can change that whenever.

@0xBA5ED: So here it is, I own it(finished locking position). So I’m going to take a pretty big risk right now because I haven’t tested this on the testnet yet. Because the minimum duration is a week to lock, so I made one veBanny a week ago. Just one, so I haven’t tested it yet. We’re going to redeem it, we’re going to unlock our tokens and redeem them for ETH from the overflow in one transaction. So let’s see.

@jango: This is another cool feature of the ve mechanism that is different from the traditional Curve ve mechanism on which this is based. Since Juicebox has redeem functionality, you can redeem your treasury tokens for the underlying treasury asset. At any point you can still redeem your locked position for the underlying treasury assets, independent of whether it's locked or not. So you can have your tokens locked for a year, you’ll be able to get your JBX back until the year’s up. But you can burn your NFT to get your JBX to get the underlying treasury asset whenever.

@0xBA5ED: Exactly. So before I burn it, I thought that we just show the voting power actually decreasing. So this is my current voting power and every block that passes it’ll decrease. So this decreases linearly until all my NFTs expire, then I won’t have any voting power left.

@filipv: So is voting a function of block number, or a function of time and it’s just updating on block numbers?

@0xBA5ED: It’s a function of time operating on block numbers. (redeeming…) So here it’s gone already. As you can see I burned the NFT which also burned the JBX that was locked and I got the ETH from the overflow. I’m very happy that it works, actually I haven’t tested it yet. I know it was going to work, but still it’s a bit scary to do a demo live for the 1st time.

@Felixander: A quick question in what jango was talking about, but let’s say somebody buys an NFT and they lock 100 days, and on day 75 they want to get out and they burn everything. So you can burn the NFT and the JBX. If they went in let’s say for 100 dollars, then on day 75 if they burn everything they are not gonna get 100 dollars back right? Is that gonna depend on the value of JBX or how does that work?

@jango: They’ll be able to, all the underlying JBX are gonna be redeemed with the exact same function that the treasury normally redeems at. That doesn’t decrease linearly. The idea is probably the value of the JBX or the NFT, it’s literally the floor, so you might find more value in NFY by selling it on the market.

But the point of doing this is because they were functionalities actually fairly meaningful in the Juicebox ecosystem since we’re minting JBX open-endedly. So someone can come in right now and put in like 6m dollars worth of ETH and they basically get 50% of the JBX supply or whatever. If they weren’t trying to coordinate with the rest of us, they could take everyone’s assets then basically use that big pool of JBX to control whatever was there before. The point of redeeming is that if somebody does that in a way that’s not trying to integrate with the current system, then anyone who currently has JBX is basically getting a shit ton of money from this person who comes in, so anyone who doesn’t want to be a part of that ecosystem can redeem basically and leave with a big chunk of what was just poured in. So this is in a way to disincentivize this takeover thing. So we need to keep that mechanism in place regardless of if JBX is locked because if we lock it and don’t keep that mechanism in place, that vulnerability becomes larger.

@Felixander: One more question for the NFT profile page. Are we making a difference between different Bannies, obviously they have different histories and stats, or are we putting that in the NFT profile page or is it gonna be the same page and the info exists somewhere else on a website or something?

@tankbottoms: The thinking was just keep the metadata inside the veBanny strictly about Juicebox with the exception of the name of the character, the model and the description will be added as well as these characteristics, shadowness etc. Everything in the metadata for the token will be related to Juicebox and will speak about Juicebox. There’s a location where we could put a URL in the description in the external URL so that in the opensea UI when you go to a detail page you can jump to it. The thinking was to keep it specified to Juicebox. With that said, there’s something you can do when you load up a web page with CSS and Javascript. I am trying to do some animation with the token, so when you go to a detail page, we could put a hidden link in that people can click to jump to Bannyverse.

@Felixander: So the metadata will be the same except for the name? Or will the description model also be different?

@tankbottoms: All tokens will be unique to the lock duration. There’s 300 tokens of each range, e.g. 0-99, 100-199, up until 100m and there are five locked positions for each token. Those 300 will have metadata that says who the character is, what the duration lock is, their motto and their history. The name of the token will be the name of the character.

3. veBanny Front End by @Jmill:​

(demo undergoing……)

We have a deployment of this to Rinkeby now. I’m working on a contract reader actually populating those with real user data and then working on the transactions after that. The goal right now is to spend the next few days working on the contract reader transactions populating with real data and just moving the component around to where they need to go in the application and getting the front end of this at the door.

@mieos: I think this looks pretty great in this little side panel. I was skeptical about it, if we’re thinking how projects could launch a toggle over to set a locked voting token option and this sort of pops up in the UI of their project. Maybe it’s a lot of info and there’ll need to be a lot of education that goes with their community, but it’s great that it can all happen right here. For what it’s worth, I think it looks pretty good. Maybe it’s because I understand it, but it looks nice to see it in action.

@Jmill: I do agree with that because the flow for almost everything project management related is that it never takes you to a new screen entirely. Any other configuration you’re doing is out of the drawer or model, so you know that we can keep that paradigm for this also. I think it’s good that the actual controls of it are quite simple. If the user has 10 positions, there’s a good way to show that here without making them scroll forever.

@jango: We’re also getting rid of the delegates onchain in this contract, which might allow us to really get rid of it from the UI as well and we’re managing the delegates via other means like Snapshot and potentially to other stuff.

@mieos: I guess I missed that bit. I think that’s great, certainly simplifies the experience of a person who doesn't need to learn what it means to delegate or take part in that same moment.

@jango: At this point, I think there’s still some research work for filipv on the best means. The Snapshot delegation strategy seems compelling, and there’s other schemas we’re thinking about. I think the goal of all this stuff long term is to get rid of the multisig. To get rid of the multisig we have to do some kind of on chain voting, and on chain voting can be expensive, so we have this delegation. I think there’s some creative ways we’ve been bubbling up in several veBanny related threads that seem really promising. The delegate stuff was a blocker for this to the voting weight stuff. I’m pretty confident that we can get rid of it from the design scope for the front end for the time being, we’ll work it back in later.

@Jmill: Just from a user’s standpoint, it’s a really touchy issue of how you open up this delegate picker and how do you decide what to show, which delegate option to show to the user. There wasn’t a really great answer there as far as implementing that in the rest of the UI. I’m just working from the mocks but it’s pretty easy to remove the delegate stuff.

@filipv: ENS sorted alphabetically and free delegate. One thing I should add about Snapshot delegation. There’re hybrid solutions you can do using safe snap to have on chain execution, but you still need off chain queuing, so I’m not confident in Snapshot delegation as a strategy long term on chain governance. It’s good for hybridized stuff and getting close to there, but ultimately there does need to be some form of delegation if we want to be fully on chain. But I imagine there’s other layers we can think about.

@jango: Yeah, the disposable token strategy (see here) is very compelling to me. For now this project has a lot of merit and we still can lean on the same points of vulnerabilities that currently we are at. We’re having a multisig, having an on chain voting which seem fine tradeoffs for the time being as we work towards to study our future.

If we can eventually have these as soon as people start having these Banny characters representing their position in governance then we’re going to see these characters everywhere because it’s kind of like an identity in the community. So as you start voting on Snapshot, we can also roll out interfaces and take inspiration for the work that folks at NounsDAO are doing to kind of participate with your Banny and lean in to the stuff WAGMI is doing to extend that even further.

@mieos: I just love the idea of getting the Bannyverse and these veBanny off the ground, but I can’t wait till the next DAO actually just uses the same implementation of voting and either uses WAGMI or somebody else to create these stake tokens. I’m excited about this rolling out to other Juicebox projects and creating value from.

4. Product Roadmap by @aeolian:​

@jango: The veBanny stuff is great but we can’t ship it yet because we don’t have V2 tokens up yet. And all the stuff that’s up depends on the V2 JBX being out. So we’re in a transition period of V1-V2. We’ve got to transition the V1 JBX to V2 JBX, and we’re currently talking about a few designs to do it. Coming off product roadmap discussion we’ve been having in the strategy channel, we are gonna focus on making sure folks have an easy way to pay their V1 JBX to the treasury and get their V2 tokens in return, and making it easy for other projects like SharkDAO for instance, to do the same. That way we can get a lot of V1 projects who are still using their treasuries in earnest onto V2 and then build these new features on there their folks can use. So I think that’s the area of focus for the time being and there's a couple of ways to go about it. Aeolian do you want to hit up the current thought process?

@Aeolian: Totally. Quickly from Peel’s perspective and the front end perspective, as jango has said, the immediate focus is getting this V1-V2 migration flow done, designed and implemented. There’s a few different ways to go about it and jango said some good ideas in the strategy channel which everyone can check out. That’s our immediate priority. So Peel is going to return to development life cycle which is going to basically in line with Juicebox funding cycle, we're currently on FC#22, and the work we get loosely scheduled, everyone can check out here on our Github project.

There are 3 main things we’ve been working on: V1-V2 migration flow, coming up with solution for handles for V2 projects which includes cool crossover with ENS names, some iterations on payout splits UX that making that a little more intuitive which is pretty exciting as well.

We will be focused on these for the next 2 weeks to one month, ironing out little bugs that have come up in V2 and refining experience alongside these big features.

And beyond that, we had really good discussions in the strategy channel. Definitely encourage everyone to come hang out there and drop ideas.

I think the overarching alignment is to figure out how to get more activities on the network and more long term oriented activities. I still think there’s a few obvious things that we can build initially that have surfaced, and one of those is the multi token payment terminal stuff.

“Roadmap is coming together in a loose way”.

@jango: Everything is great. It’s occurring to me that finding the transition between projects is fairly meaningful to right patterns or timeing or whatnot. It’s sometimes not just a matter of feature itself but where it fits compared to other things.

So all these little motivations can all play into the roadmap in an interesting way that certainly takes the high level metrics we care about into account. So it’s absolutely a luxury to have 4 or 5 really delicious projects on the finish line right now. But figuring out a way to actually take them through the finish line in a way that makes cohesive sense is gonna be a lot of fun and can take a lot of patience from a lot of folks who have been working on each of these projects. But I think many of them don’t really have and might find themselve wanting something if we don’t do another piece beforehand. If we try to do them all at the same time, it’s probably gonna be like everything somewhat half baked. We’ll revisit this discussion probably for 15-20mins in every Town Hall to give updates on where we are at.

I think this line of thinking at least makes cohesive sense from our current standpoint, but can always change over time.

5. NFT Framework by @tankbottoms.eth:​

(demo undergoing……)

I’m thinking maybe anybody can make the NFT and associate it with a project. But in the recent discussions, originally any NFT that came out of this system is tied to a project, but there’s a bunch of feedback with a basic point that lets people do just whatever they want to do. I’m really looking forward to Aeolian's splits. The idea is making an NFT as a project owner or as a project contributor for a project to sell on the market place of Juicebox. There are everyone’s ideas to roll into advanced mode or simple mode. There can be instructions on image NFT, music/video NFT, and p5.js.

As you can see, it’s just a lot of stuff. If you want to learn what to do, you can go to the create mode, and basically go through a PFP, or p5js or music, then create your collection to redefine your asset, review and deploy it and then price it and attach it to a project.

@mieos: Where would a Juicebox project contributor who wants to send some money to a project go? Where would they go to purchase this NFT? How would that look?

@tankbottoms: For things that need to be minted, this area where you can contribute could be a tab where you can mint an NFT. There’s also the idea that makes a kind of landing page for a mint, then there’s also the idea to have a Juicebox marketplace like Jango did. There’s definitely more experimentation where it’s gonna leave. The core ideas are making this tool pretty fancy and giving projects the continuous reasons to get ETH going into the treasury. They don’t have to worry about the whole split thing at some point after they do their NFT thing, like how much you want to go to the treasury or go to your wallet. I think that would be super useful.

@mieos: I think the NFT capacity inside juicebox is gonna add a lot of functionalities for projects and sort of just simplify this heady shit for staking projects. And it’s just a lot and I think it just helps democratize getting contributors in the door and checking the boxes that make sure their project is strong and has all the utility.

@tankbottoms: I hope so. I mean I don’t wanna work on stuff after this ever again, just put in everything I know how that you can milk out of an NFT and the tool to simplify it. I think in advanced mode or simple mode, everything will have a lot of feedback in terms of how it actually gets implemented.

@mieos: I’m curious, Nicholas, do you have thoughts about this? You’ve seen a lot of projects roll out with NFT. Does this strike any chords inside you?

@jango: This is definitely a big thesis on how the community can derive more cash flow. But it’s kind of a self-contained project for the time being, for sure it will make its way to product, once a lot of these granular things get knocked out in the next several months. I think this project could certainly have life on its own, maybe on its own site for experimentation to start. I feel very confident about the product per se and it’ll be unfolded in due time.

@nicholas: That was really what I wanted to say. It’s so powerful and has so many tools in what you build. You’ve created all-in-the-best class creation tools in one tool. I know you’ve got ideas about on chain also, so it’s even like tools that barely exist and are separated from multiple products. If you are a generative artist, there’s a couple of things out there that you can use. There’s a few artblock clones, then there’s a manifold that has something, there are private companies that can work with you, is it good enough to be in direct competition with those things like a choice on people’s mind? Or is it like I want to do a Juicebox project and I want to fund it with NFT? I think the truth is probably it can do all of those things. I think probably just have it on its own site, as it’s going to be difficult to integrate elegantly. I want to think more about what interfaces make sense for it.

@filipv: I wonder, looking at this demo and the demo by Jmill earlier, if it makes sense to start implementing some form of project page customization for project creators where project creators say if they want to put NFT market interface on their project page can switch on something in the metadata and then can configure what they want to show on their pages?

@jango: If you look at the screenshots shared(below), I am very interested in the same idea. And I wonder if it’s gonna be self-contained in the idea of a payment terminal, so maybe instead of imaging the whole site as what you can bring your payment terminal which is basically a functionality to move funds into the treasury according to some means. The customization is at least scoped to that box, this is a mock that we’re still playing with ideas here.

@filipv: I think this is so exciting for existing projects, I know so many projects, like SharkDAO, have spoken about doing NFT issuance on Juicebox. This is pretty crazy. I don’t think anything like this exists in general and something like this could really draw people into the Juicebox ecosystem. Like Nichola said, this is a combination of all of the best. And the fact that this is in Juicebox potentially is super super crazy.

6. Dune dashboard of Juicebox logbook share by @twodam:​

New dashboard: Juicebox Logbook
Display actions across Juicebox protocol with details, support search, sort and filter. Check use-cases below:

• default view, actions sort by time
• payments with note
• filter by ENS/address
• filter by project handle

7. Quizz time:​

And the answer is…… @Zom_Bae!!!!

On Tuesday, May 17th, JBers got together for a fun and productive Town Hall session. Read on to learn a bit about what was discussed!

Product Perspective Discussion Kicks Off​

On the heels of debuting V2, the DAO has pivoted to look forward toward future trajectories. The question of “What’s next?” was an ongoing discussion to kick off the town hall, and the overarching question of how JB will orient itself was bounced back and forth between members. One current effort is around finding and fixing all the bugs one would expect when you roll out something as wide in scope and breadth as V2, which is an ongoing endeavor the devs are focusing on, particularly as they work to build out extensions that were previously not possible with V1.

Safe to say where JB finds itself today is quite incredible, and has etched out a presence and community known for providing an excellent tool that works and is powerfully scalable. The use cases solved for already have proven successful and powerful, and the discussion of what other future use-cases exist is ongoing. Head over to the #strategy channel to learn more.

Delegating JBX Now Possible​

We now have delegation on snapshot, so you can delegate your JBX to other addresses for snapshot voting. A major thank-you to DrGorilla for making this possible and putting so much effort into the cause!

The way it works is, for example, if you have 1 million JBX, you can delegate it to someone with 3 million JBX, and that person will have 4 million JBX voting power. But if you do choose to vote later, their vote will decrease by that same 1 million, and your vote will be as strong as your own JBX (1 million). This is a flexible way that people can share voting power without sacrificing JBX or transferring it directly to one another. To learn more check out this link.

Twodam Joins and Rocks With Data Displays​

The absolutely awesome twodam was able to come join us today at our town hall, and gave an awesome presentation on his new dashboard for JB. It’s a powerful new dashboard with some absolutely awesome data displays, check it out here!

Taking Canu to New Heights​

Zeugh spoke about the role of CanuDAO to help other DAOs with marketing and community needs, and underscored the need to grow CanuDAO on par with the growth JB has seen over the past several months. The goal is for CanuDAO to provide high quality marketing and community-building services to JB, and also to affiliated and new DAOs that enter the JB space over the coming weeks.

Snapshot of JB in a Bear Market​

While the bear market has dropped the value of ETH, with continued careful treasury management the DAO has a healthy runway. There are core functions that JBers will continue to take part in and carry out, and proposals for these core areas will continue forge on. Furthermore, an excellent opportunity is within the recognition that during any downturn of the market, yield and liquidity tends to dry up in places where it was accessible before. The can serve as as silver lining for JBers. Also, a proposal to review the DAO foundation is on the books, so all members please take a look at that proposal and discuss it ahead of its snapshot vote next week.

Ice Cream And Banana Costumes in NYC!​

JB is considering a partnership with Morgenstern’s Ice Cream parlor in NYC. The goal is that JB would deck out the ice cream shop for four days with Banny art and posters and custom ice-cream flavors and creations. JBers who network in NY ahead of the major cypto conference can point people toward the ice cream shop, meet them there to conference, and spread the good word about Juicebox. Contributor filipv will be greeting new and old members in a full-sized banana costume, and tank_bottoms is permanently banned from the event. Come enjoy the scene, more info the come!

(For a full recording of the town hall, including the legally binding declaration filipv made to wear a banana costume for the entire 4 days, click here.)

1.Product prioritization discussion @jango:​

@jango:

We are to some extent acknowledging the moment we find ourselves in from a product perspective, specifically juicebox.money essentially. We just got to the V2 milestone which is massive and there is natural inclination to add to what’s next. We have a bunch of projects in flight, as we discussed in last Town Hall.

There’s a lot of work going on and a lot of them are closing the finish line. They are probably not going to be in production at the same time, so we’ve got to figure out what our priority is and the way we think about prioritization going forward. Maybe we could just say we’ll do it next week once we get it more put-together, although it is solid as it is.

@aeolian:

I think we can refine it a little bit. By next week, we probably will have a more solid plan before we actually gonna build. Yeah, we can leave it until next week.

@jango:

I think the main thing is that there’s a lot of fun, powerful, shiny things in a lot of people’s work, which is about to have the possibility to come into fruition. For the time being, it’s quite clear what the priority is, that’s risk mitigation and making sure these small bugs that naturally have found themselves in a little bit to the product via this long stretch. There’s a couple of blaringly obvious pieces that the V2 has.

So in the short term, maybe a week or a few weeks, it’s really coming to terms with what those are and making those as clear as possible in the UI and then giving us an avenue to peel those back as we have known extensions, because almost all of the stuff is extension related. We can create the system to disclose one at a time appropriately. And it’s not a big shiny future but it’s pretty important. I think top priority with these things is to keep things from going to zero, kind of our job.

The 2nd priority is currently straight in the dark to increase the number of projects and the volume of payments. The good news is there is plenty of work we can do right now to stitch up the risk stuff and the bug stuff as we deliberate strategy. But as that gets wrapped up, then we’ll want to all be on the same page about what we're trying to deliver next together.

@aeolian:

I think it’s worth calling attention to the fact that it’s quite amazing Juicebox gets where it is. We should all have confidence at least from the UI perspective. When projects come along that kinda have the fire power, it’s able to really facilitate the payments. So it’s like, do we take this to the next level? What’s the next level? That’s really the point of the strategy channel and that document(here)and these discussions.

2.Brief explanation about JBX delegation by @filipv:​

We now have delegation on snapshot, so if you go to this link, you can delegate your JBX to other addresses for the snapshot voting. Tks for the amazing help from @drgorilla btw. Let’s say you have 1m JBX and you’re delegating to someone with 3m JBX, when they vote, they're gonna have 4m JBX. But then if you vote after they voted, their vote will go down to their original 3m JBX, which means you still can vote on any proposal you want and they will lose your delegation, specifically on that vote. Right now this is working with both claimed and unclaimed JBX and then we’ll be moving over to the veBanny when it happens.

3.Work report by @twodam on new dashboards and protocol research:​

There is a new Dune dashboard made by twodam in this link, in which you can find gas fee specification about setting up and managing a project in the protocol, as well as some fun facts such as “projects created per address”, or “ how many has an ENS” and so on. And he is going to do some Protocol research and comparison, current list: Mirror Parcel Superfluid Coordinape Utopia Aragon

@jango: Just shout out for these incredibly useful analytics and there’s a lot of them. Sometimes I try to find signals in these numbers. So I appreciate the readiness to take on new requests and make dashboards for things over time. It’s damn helpful.

@twodam: I have made some dashboards and maybe I need to write some reports based on these data.

@jango: I don’t know if VJ or Goldstein have worked using these dashboards but they created reports that might be based on your number, which I am actually almost certain they are. Like coming together and understanding how to distill these facts into narrative and we can use several people taking the steps like that. So yes please, I think VJ and Goldstein will keep doing that.

4.Community and market cohesion by @Zeugh:​

It’s more of informing and getting opinions here. Since last time we decided collectively how we would be improving our community through the way we manage the server and things like documentation and onboarding, we have grown a lot. It has been a good while and now we have more than 3,000 new members and lots of new contributors. For those that maybe don’t know, CanuDAO, the DAO that I am paid through, is a working community here in Juicebox.

Lately I noticed and more people also have the feeling that in our whole marketing community, the way we communicated as a whole has not been as efficient as it could be because we don’t actually have coordination between ourselves. Last week, I talked to Felixander and Casstoshi to invite them into CanuDAO too. We have this model of having a separate DAO, like WAGMI and Canu, to make decisions and work things around to actually develop it as a service to Juicebox. But as it’s growing , it’s getting hard to get the cohesion, so I’m trying to get more people working on the community side here in Juicebox to get inside Canu too, so that we can have more specific time to talk about the Juicebox community together.

So this is to inform all of you that Felixander and Casstoshi have come in, in a way that we can communicate better like in SEO(Search Engine Optimization), pulp writing, community management. It’s also an invitation for anyone that is dedicating their time in Juicebox to work community part to also join Canu, to come to our meetings where we can have more time to discuss perspectives, to discuss what we’ve been seeing and ideas we’ve been having in Juicebox so that we can go back and deliver better community management. I feel as the community grows and the roles for keeping the community healthy get bigger, but Canu didn’t get bigger at the same speed. The tasks and everything expanded and Canu kept at the same size.

We’re about to renew our payout proposal in the next cycle, so this would be a good moment for people doing community stuff and wanting to get paid through Canu. It’s more of an invitation and explanation of the reason for this invitation.

@filipv: For someone like Matthew and Briley who have recurring payout and work directly for Juicebox, what advantages are there to work for Canu? Or are you talking more about coordination？

@Zeugh: Not necessarily I am moving payouts to Canu, for some it makes sense, for others it doesn’t. It’s okay to join Canu no matter if you get paid through it or not. I think it’s gonna be important now that the V2 is out, and efforts in my perspective are to onboard new people and new projects, to help people coordinate and cohesion can be of great value here.

5.Macro environment and MorganStern’s Ice Cream shop event by @jango:​

Macro:​

As we’re all aware, the treasury has decreased in dollar value quite a bit with Ethereum events in the market. It doesn’t affect our day to day activity, just in a sense affects our horizon. I think what we can expect going forward, obviously we can’t control what happens on a big picture scale, but running a fundraising platform does encourage us to continue to bring insights to each other over time from the perspective of how capital is being managed in macro. Looking at the runway we have, it’s a good opportunity to reflect on our mission and really focus on it. I think we’re at a comfortable place and we can certainly keep on for a while longer even if the access to capital affects us, which will affect all the projects on the platform and subsequently our revenue stream. Even if things were to slow down in a couple of years, we will still be comfortable in the runway's perspective if we manage the treasury appropriately. These are the things to keep in mind when we’re thinking about prioritizing the initiative that we’re trying to further.

There are a lot of things that are very fundamental and core to our commission statement that I think we’ll have no problem continuing to further for the next long while. During any downturn of the market, it’s yield and liquidity that tend to dry up while they were pretty accessible before, so we have an opportunity to recognize that we are a funding platform, there’re a lot of people now that are maybe venturing somewhat into the unknown, into new opportunities and having to retreat into their fundamental convictions of what they want to do in the projects they think are important in the moment. I think really understanding the powerful projects that we can fund are not only going to be sustainable through whatever macro environment we find ourselves in, but also maybe these kinds of projects are gonna define the future market cycles or future building cycles.

I’ve put up a proposal to revisit the DAO Foundation document, reading through it and what we verified in the past still feels honest and great. It’ll be nice to go in the upcoming governance cycle. I want to make sure we’re committing ourselves and that we’re willing to spend sources on that. We feel very serious about these things and that mission statement feels very sincere. We are indeed willing to work through whatever resources we have available to accomplish these things but realizing that things could be worse and there’s sacrifice that have to be made. But we also have to be in tune with the fact that this isn’t a project that reads similarly to other web2 related startups.

I think a lot of ways in which we use the treasury funds can be used to help projects start up and build during this time. I think these can be among the more powerful projects to emerge. Whether we do it collectively through DAO funds or we do that through individuals who are getting payout from the DAO in recognition of their work, is still up in the air. It’s way easier to support individuals as we have been doing it in the unit of ETH sent out per unit of dollar denominated payout, which is greater now for theoretically each of us are getting payout have more ETH overtime. It’s totally up to you what you’ll do with that, but it’s an opportunity to recognize here our job isn’t necessarily cut. It is just to recognize what our roles here are, looking for one building and we’re the ones helping (recording lost for a while)

@mieos: Do you think it’s worth revisiting the redemption rate? If capital preservation is the thing the DAO is interested in, maybe retching that up just to touch might be useful and disincentivizing. We’ve probably gone through a bulk of the redemption, and I think it might be worth revisiting it but curious what other people think.

@jango: That’s the obvious one. Thanks for bringing that up. That’s an easy one to do on the surface to help protect funds, though it kinda lowers the floor price which is held up great. That mechanism is one of the standouts of the current JBX implementations and we can definitely use it here.

@mieos: I think it’s also worth mentioning just as a bit of anti-fud that the general theme during bear market cycles that if we’re going to see one like the rest of crypto history has laid out, which I am skeptical of, is a great time to build and thankfully we’re building a piece of software as a tool for people who are trying to build.

@jango: I wouldn’t be surprised. I think it’s probable that the next while the market is continuing its current trend, we’ll see a lot less campaigns to purchase things at very high valuations, like a 50m constitution. But we’ll also see a lot of projects that are building long-term concepts, and I think that has been our thesis for a while now that the spotlight has been on the high raisers which make the project that’s earning 5ETH or 10ETH seem insignificant. But I think it’s those projects building things that last in business model that are going to shine through, and I don’t think there’s going to be thousands of ETH for these projects either. I wrote somewhere in the chat today, I think it makes a lot of sense that I bring it up here again. I encourage each of us to find 1, 2, 3, 4 projects around over time, led by people you particularly believe in or come to believe in, and add yourself in that project, and really figure out what they need to be successful. They probably come out from one perspective and maybe lack the resources, information or technology to do other parts of the project. We don’t need to do all in the same project, and I’m sure we’ll see each other around in all kinds of Discords helping things come into fruition. I think being hands-on and patient is going to pay off.

@filipv: I think, if anything, this could galvanize us further into building out both tooling, storytelling and communication in such a way that really emphasizes Juicebox’s capability for long term treasury management for treasuries that evolve.

@mieos: I think it’s probably the best time in history for the best part of crypto to grow and become valuable, and the worst part of crypto to kinda slowly back into the shadows a little bit. That was a really loud bull market with a lot of madness, which certainly is not the reason why I’m here. I’m excited to build out some of the promises that the Ethereum has to offer.

Morganstern’s Ice Cream shop event during NFT NYC:​

@kenbot-studiodao: Morganstern’s Ice cream is in downtown on the low east side. It’s always featured in all kinds of TV series, like Billions, and a totally iconic destination in downtown NY. He makes all kinds of flavors of ice creams, and he wants to make some custom flavors for the promotion so there would be some Juicebox oriented banana flavor that we can have some conversation with. At the same time last year, it was something like a prototype that if you have a token, you can get access to secret sandwiches not on the menu. This year, he’s going to do a burger pop-up with an incredible burger chef who’s nationally famous. So this would be like tagging along and building something for Juicebox where we can onboard people in real time in a special session of the shop he would hold for us.

@jango:

NFT NYC is a Monday - Thursday event, so we’ll block off a chunk of time from around noon till 6pm, which is the prime time for people in NYC to stop by and have ice creams and burgers. We could basically deck out the place in Banny, like you got Banny plastered in different places, you got ice cream flavors that Juicebox and Banny related. We can invite and meet up with folks whoever is in town. Folks can stop by, and like Kenny said they have some criteria like onchain criteria of contributing to JuiceboxDAO or having JBX or being part of the project or whatever we decide, if we ship the veBanny in time, it should be veBanny locked position or whatever. You can get your ice cream on the house and we essentially have conversations like explaining what Juicebox is or talking to project owners. Eventually we can go through the onboarding thing. We can invite project creators to talk throughout the week who may have expressed interest in starting a Juicebox project, or transitioning an ongoing project onto Juicebox.

It’s like piggybacking what Morganstern’s is already doing as well as the NFTNYC and trying to flex our capability for Banny and Juicebox material into a hyper specific location, and meanwhile make it all about project creators. The approximate budget would be around 10k for the week perhaps including free ice creams. The DAONYC event by DAOplanet is on June 24 -25, right after the NFTNYC, so we might try to make the two events work together in some way.

7.Quizz time:​

In the statements below, two are true, one is a lie. Guess who it is?

The answer is…… @filipv, and he is not banned from any Starbucks.

1. Intro​

2. Front end update from @aeolian:​

We had another good week, and pretty much on track for a Mainnet launch in the next 3-4days. We started a feature freeze 36h ago, which means not merging anything unless it’s a critical bug, none of which is found, to allow us to merge a big PR that supports a new subgraph. New subgraph is currently indexing the mainnet, now it’s a waiting game that needs logical coordination to get things to happen. Once that’s in, we are basically ready to launch V2 on mainnet. The good thing is, that the launch is not a one-way door, if we have major issues, we can always switch back to V1 to fix the issues and switch back to V2 after that. It has been a much bigger effort than we all imagined, but it is now coming to a close here.

3. Quick inventory check by @jango:​

Not sure if it’s useful but I think the past few days after V2 has been up, folks have been more future and forward looking. There’s been a lot of ideas coming up that people are prototyping and playing with. Sometimes people are in tune with things happening while sometimes not. I just want to make sure that we all somewhere are aware of what’s on our mind and where different projects are at.

1. V2 contracts (deployed) : V2 contracts have been shared quite a few times in Town Hall. These have been deployed in the 4th iteration which is feeling great. So, our products are basically done in their initial capacity and in the needs of contracts. I just want to make sure it’s communicated out enough so folks know how to use it.

2. Docs (deployed, iterating): The docs are started by @filipv and a bunch of stuff has been added from a technical perspective. Those are done as well and constantly iterated on. @filipv: I am very excited to help centralize a lot of resources to build extensions to the protocol, and it is like a repository of information about everything related to Juicebox). @jango: Big shouts for helps in setting that up in the beginning and shouts for WAGMI studio, @sage and @mieos for starting to create a whole-worldly vibe for what a repository of higher knowledge could look like.

3. Fee extension (formalizing): This is a solution to use V2 tooling to route incoming payments to JuiceboxDAO to best yielding places for JBX, on AMM or first party issuance mechanical. It is looking great and we are wrapping up tests and playing with optimization, kind of in a formalizing stage.

4. veBanny contracts (formalizing): This is a way of staking JBX for an NFT ve position, which is locking your JBX over time to have a new kind of accounting primitive to use for governance. I hope we can align decision-making with a longer term community interest in this way. Alongside it, a lot of art is being experimented by the WAGMI team, tankbottoms and natasha. This job is also being formalized, we are trying to piece together, according to CURVE ve contracts, how we might do delegation in this scheme. It’s very promising.

5. V1→V2 migration terminal (prototyped, formalizable): Once V2 is up, projects can have a V2 token issued if they choose to operate on V2 as well as V1, which is what JuiceboxDAO will do. We are going to prototype a terminal where the V2 treasury will accept the V1 treasury token as payment and issue its V2 version one for one (1:1). It, to some extent, works within the mental model of how Juicebox treasuries are working, and we are trying to manage the migration in that way.

6. NFT market (prototyped): It is a topic that has been lingering for a while and happened in conversations quite many times and might be on the horizon. It’s a set of contracts that allow folks to list NFT with the sales routed through a particular Juicebox treasury or a set of treasuries. The goal of this project is, instead of having the pay button as the way to pay projects, anyone could upload an NFT that could basically serve as the pay button. Someone could just buy the NFT and the funds would be routed to the treasury. This is in effect a more engaging pay button that is extended to do the NFT related treasury things. This is also prototyped, and it seems we also have a few prototypes from @tankbottoms as well. It still need some design iterations.

7. V2 versioning fire drill (prototyping): There’s an idea floating around once we get V2 up to sooner rather than later organize how versioning might work on V2, like we might deploy subsequent version of the payment terminal V2, which is a feature of V2 as hyperforkability. People can roll their treasuries and migrate between terminals. Might be interesting to be right off the bat, before some happenings or pressure, to migrate from one terminal to another slightly optimized one. This is not really a big deal but more so to get the cadence of feeling confident in how we might organize files. It’s not an urgent matter, but we should think of doing it instead of waiting till things get chaotic and we’re driven by necessity to migrate, by then things tend to be more delicate.

8. 1:1 terminals for L2 strategy (pre-prototyping): The L2 strategy allows projects to manage treasuries on not just mainnet but any other L2, then to have their tokens organized across chains, taking redemption into account, etc. There is a good design for it, it just needs to be prototyped.

9. Subscription terminal (pre-prototyping): It’s not really worth touching on but @jigglyjam brought up a cool use case that might be fun to sail for.

10. Juicebox reverse ENS registry (pre-prototyping):With the V2 tool box available, front end brought up a good point regarding Juicebox reverse ENS registry. In V1 we had handles for projects which is great in the short term, but it has a whole lot we need to think about for a long-term perspective. In V2, we just started with project IDs, so that people can build things on top of it. Front end has already accommodated ENS support for projects to use as URLs to access their treasury, but there’s couple of things in the UI that need to be nicer if there's an additional Juicebox reverse ENS registry.

11. Treasure hunt: @mieos has been working on a treasure hunt on cryptovoxels.com which is pretty exciting. updates on treasure hunt by @wackozacco: We are trying to experiment to coordinate something special with V2 promotion. Please go to the 3rd floor of the parcel, where there are clues for seed phrases of the treasure chest. There is already 150k JBX inside the wallet. After V2, @mieos will set up another discord to give clues for the decoder. We try to plan some more scavenger hunt type of things.

4. Nance bot by @jigglyjams:​

Nance bot has been up and running since the last Funding Cycle, and I am working on scheduling it now. I am definitely interested in how subscription payments tied into it for future DAOs. Nance is like automating the governance pipeline, e.g. Juicebox has a notion-discord-snapshot pipeline, this feels like their valves, and also works for other Juicebox projects using similar structure. The notion page by @filipv and @jigglyjams is here

Utilizing nance bot is currently through CanuDAO, I am planning to use the subscription contract for future DAOs to pay for the use of nance bot.

@jango: I am interested in taking a step in the subscription terminal, it could be an interesting project and a decent entry in building Juicebox extensions too.

5. Podcast updates by @matthewbrooks and @brileigh​

We have just posted the 1st podcast with @dropnerd from SharkDAO, currently we are editing the 2nd episode which was recorded with @drgorilla and @zhape about Moody’sDAO, and working on finishing that up. I think the results are good so far, and we are open to constructive feedback. @jango: I suppose Moody’sDAO should be another project worth mentioning here. We are trying to make everyone aware of what’s happening, say it out loud the priorities, and see how to nudge each other towards bringing things over the finish line one at a time. Surely everything is making an impressive progress over the past months, some of them are really hefty projects that are not easy to spec out let alone bring it to the finish line.

6. Presentation by @tankbottoms and @filipv​

In general, this presentation talks about different objectives based on the foundation which is helping people confidently run programmable and community fund treasuries, from start to scale openly on Ethereum.

A lot of people are using Juicebox so far because these are short term project instances which Juicebox is amazing for. You go to the website and in a minute you can have a treasury set up with the project’s page. But a lot of projects are more oriented towards longer term development, and would want to have their own website and an interface custom suited to what they need to do. Something @aeolian brought up today is super valuable in building out different libraries of components which makes it super easy for projects like Flamingo or Muse0 to interface with the Juicebox protocol.

Part of enabling people to build longer term oriented projects is to help approach legal things in a way that makes people more confident. We can add terms of use and a privacy policy for juicebox.money and other front end. And we are also working with dao-lawfirm.eth, the one @tankbottoms is working with, to set up some accessible packages for Juicebox projects and potential templates and generic policies which will hopefully help people build on Juicebox with more legal peace of mind.

Another idea is to bring in some DEFI capability by using some of the functionalities that V2 provides and we can start by doing stablecoin, overtime we can work with different services providers to set up bot terminals which people can add as a payout and then be able to interface with different DEFI protocols. If JuiceboxDAO is focused on treasury management for DAOs with long term orientation, being able to diversify and split ETH into a bunch of stuff is probably more attractive than just keeping ETH in the treasury in terms of minimizing risk.

Another part will be genesis NFT creation. I just did the pull request for the NFT delegate. The first 100 people that contribute to your project should get an commemorative NFT or people who contribute more can get the NFT. The delegate is a new function or a feature in V2 that executes an arbitrary smart contract or basically does whatever you want whenever someone pays or redeems with a Juicebox treasury.

Q: When this stuff is implemented, how much longer is it to launch a project? Are you going to have the option to not use these things by bypassing them, like, if i don’t want them but just something simple, can I click a button to bypass?

@filipv: I wonder if it makes sense to implement these things as an optional library or even on a separate website from the main juicebox.money interface. If you want to do NFT, you can go to the other website.

There are a ton of functionalities tank has been working on. Like this NFT market is to some extent extending the functionality of minting NFT which projects can use, and contributions on the market place can be sent to the DAO treasury.

The bot terminal basically creates treasuries which will interface with different DEFI protocols and we can create custom strategies to diversify assets and to manage treasury as easy as adding another payout. What’s great is that there is no fee in between projects in V2. The idea is to make it sticky and make people want to build in Juicebox because it’ll give them access to these tools such as NFT and DEFI stuff like that. First these are built for JuiceboxDAO, but eventually hopefully will be accessible to the entire ecosystem.

@jango: We should continue to go out and prioritize and try to refactor until the right way to present it to folks, in a way that preserves the users’ focus as they are trying to find out how to set up projects and achieve certain things. I am curious how you see a lot of these new features playing in one place because a lot of mocks belong to juicebox.money or navigatable from the same UI. Maybe this is a question that we should keep in mind as a group going forward. There are going to be some competing for space in the interface, or competing for attention.

@filipv: In my opinion, one super valuable work flow would be to compartmentalize all of these into APPs. we can build this library of extensions in the Juicebox protocol. If you want to use it for your project, you can click “add”, and people can put in their custom contract.

7. On Gorilla Marketing:​

@filipv: I want to mention the Gorilla marketing that @Zeugh is up to. There’s a lot of discussion of physical presence at conferences. I think it has a lot of potential. Anyone interested can reach out to us.

@Zeugh: That’s something I am excited for. I’ve been talking a little more this week with @felixander and @casstoshi about joining some forces to make it better by integrating gorilla marketing, pulp writing and search optimization. I believe we are going to have some nice news soon on getting better visibility. I was reading about treasure management, talked with @twodam, @jango and @drgorilla about the runway we have in ETH. And one of the solutions I believe is to get more projects inside and make that treasury grow. So ETH goes down, treasury goes up. It makes a whole lot of sense to me that marketing, writing and visibility can play a good part in that.

8. On user flow.​

@filipv: Does anybody have any thoughts on user flow, and what that would look like as these extensions are built out?

@jango: I am gonna say these are gonna come together over several weeks. This will continue to be a topic in subsequent town halls. We will keep revisiting.

@nicholas: I think maybe it’s interesting to think the creation flow could be people coming from very different points of view. We may be having an easier time building a treasury set up for their use cases. Then maybe those are rolled into this modular interface content.

9. Quizz time:​

The answer is……..@mieos