Skip to main content

12 posts tagged with "town hall"

View All Tags

· 9 min read
Zhape

Town Hall banner by Sage Kellyn
Art by Sage Kellyn

Capsules project with peri

The Capsules is peri's latest project of on-chain typeface that he launched just one day before this town hall.

This project of on-chain typeface introduces a standard to make it easy to store fonts on-chain. There're a lot of projects that use text in on-chain rendered SVGs these days, but if they want to use a custom font in an on-chain rendered SVG, they need to find a way to store that font on-chain. Also storing fonts on-chain is expensive and complicated, and there isn't a standard way to do it. For this reason, Capsules project introduces a new typeface contract interface in order to standardize storing fonts and make it easier to access.

Together with the launch of this project, peri also put out some NFTs as a Proof of Concept experiment for fonts, by which he tried to educate users how to load fonts from a typeface using this contract and throw them into an SVG which in turn gets rendered on-chain. There're altogether 7,957 Capsules NFTs with each one of them having a unique color, while users can only mint each color once. Users can edit the text of the NFTs and it gets rendered in the Capsules typeface.

People can also download the typeface here for free if they want, together with its variable fonts, which is pretty cool.

The typeface contract allows you to define the typefaces even when you deploy a contract without storing all the data for them, which means anybody else can just come and store the data, provided it matches what you define in the first place.

For this project, there are 7 special pure color NFTs that goes to people who store the 7 fonts 100 to 700. Folks from around the Juicebox ecosystem got news of this launch and stored all of them in just couple of minutes, which is a very decentralized effort to get some new infrasturcture onto the blockchain.

Definitely follow peri on Twitter to get more first hand info and all his genius ideas!

Nicholas also managed to make a prototype using the Capsules typeface to render some active data of a Juicebox project.

And filipv downloaded the Capsules fonts and set his terminal font to them, which is super super cool.

Versioning update with jango

Jango and his team launched the V3 contracts in the morning of this town hall.

In the past week, we had another Code4rena audit contest of mitigation review over the updated V3 contracts. After this contest, the team deployed all the contracts again except for the JBProjects and JBOperatorStotre, which means projects currently have their project NFTs will keep their project IDs and they can choose whether or not to deploy a V3 funding cycle and token that syncs to their V2 versions, while all new projects will be built on V3 contracts.

Dr.Gorilla and 0xBA5ED have done a lot of work for testing and solving some very complicated problems along the way.

V3 contracts are essentially a mitigation of a few bugs discovered in the previous Code4rena audit contest in V2 contracts. The most impactful one of these bugs was that project owners can set a start time of their funding cycle in a certain way to overflow the storage of that piece of data, essentially allowing them to create a funding cycle at arbitrary points of time and mess up the schedule of things. With the assumption that community relies on project owner to be honest, we try to create as many levers as possible to at least give project owners the ability to lock themselves into things, but this bug would in a sense allow some unforseen reconfigurations if for some reason project owner and the community were no longer aligned in interest.

It is just a fringe case, either it could have been patched with a new payment terminal controller, or contract crew could have made edit in the JBFundingCycleStore to fix it. But it makes a lot more sense that people about to build projects on Juicebox want to be building on the best version of contracts possible, so the team did the V3 contracts and made changes in the JBFundingCycleStore.

The next move is to extend what was previously a V1 to V2 token migration terminal to be more generalized, so that projects can deploy a new funding cycle and toke if needed and make the move across as they wish. But the V2 contract will keep working and all the stuff there is solid.

It's really nice to have a versioning pattern ahead of time when things are still pretty slow these days. Both contract and frontend teams were taking this opportunity to create decent standards for projects to use to implement major-version migration in the future if any problem arises.

nicholas: If people have their V2 projects right now, should they be worried about it sitting on V2?

jango: No. We've talked to all projects willing to communicate about it and make them aware that the audit contest has been wrapping up, and the broad base of projects has already had trust vectors established between project owners and the communities, so it should be fine.

nicholas: Is there a timeline for the feature of token swap?

jango: We current have this mental model that people paying ETH and they will receive project tokens, so projects might also use it to receive the old version of their project tokens and then issue a current version of token back out at a rate of 1:1. Under the hood, it looks like a payment terminal, and also in the frontend there's going to be a settings module to make the process easier for projects to do it.

Stay tuned for updates on all the work of the versioning stuff. The next thing for us will be to figure out how to deliver effectively. We have a lot of prototypes of this at the finish line, but given this V3 deployment, we want to make it work from V1 to V3, and from V2 to V3.

And there's some cool stuff we can do with extensions in V3. You can make pay delegates that receive part of the funds before they go into the treasury. This is a new feature that no one has used yet, and we're building the first one with the NFT Rewards, because we found that it would be really useful if some of the payment could be routed directly to a delegate. You can run arbitrary contracts that actually receive parts of the funds paid in, and the same with redemption, in which you can run delegates that receive part of the reclaimed funds automatically.

The GitHub repository of V3 contracts can be found here

Visibility updates with brileigh and matthewbrooks

Juicenews newsletter

The new release of Juicebox newsletter can be found here

Config articles

The config articles are going to run through how a project is configured and some of reasons for those decisions made, to help new project creators understand why certain projects are using a different configurations and why they're making those decisions. So if new project creators want to build a similar project, they can look to that article as a reference point for their own project.

Brileigh and Matthew just launched their first config article here.

Juicecast (Juicebox Podcast)

They recorded a new Juicecast episode with 0xSTVG about his project Marin Swim County Association, this episode will be released later this week.

They also made a video interview with David Phelps, the founder of JokeDAO, which they plan to upload to Juicebox Youtube channel later.

Work Plans

  • Another video interview with Robin from Defiant about creator economy.
  • A retrospective deepdive on ConstitutionDAO.

They also have the plan of making a series of podcast featuring some famous/symbolic projects of Juicebox such as ConstitutionDAO or MoonDAO, coupled with some long articles that go through the history of them, as well as some config articles about how these projects were set up which will certainly be reference points for new project creators.

Interface with sunnndayyy

Interface is a mobile APP that allows you to follow your friend's wallet, lays out all the information in the feed like a social Etherscan and lets you surf Web3 with a better UI.

Interface community has recently transitioned to a DAO, with a hybrid model between the Labs and the DAO. And they want to start doing some interviews and learning about progressive decentralization publicly. So they're looking to hold a series of Twitter Space on the challenges of decentralized coordination and stuff like that over the next few month.

They feel there will be no better community to talk to about these topics than Juicebox, so they want to invite the core contributors of JuiceboxDAO as their first guests to discuss on how to activate participation in governance in the early stage in a project's lifespan.

sunnndayyy also introduced that this APP is still in a closed beta version, so if people want to download it to try using it, they have to go to their website to sign up for early access.

G-Play updates with Sayid

G-Play is a Juicebox project of P2E gaming platform where users can stake $Matics to play with each other on Polygon.

Recently they started their beta testing and onboarded their first users to the platform.

One of the new features they have, is a statistics page that shows how much the users have unclaimed $Matic they can withdraw.

Sayid and Mieos played a game to demostrate how the game goes on the town hall.

As now it seems a little troublesome to buy $Matic on exchanges and bridge it to the Polygon Mainnet, Sayid also announced a 500 $Matic scholarship so that users can use the built-in request function to ask for $Matic from them.

Two Truths And A Lie with Felixander

The correct answer is ... Viraz.

Forming event Vol III with darbytrash

Lexicon Devils are going to host a new Forming Vol. III event, FLOPPY x FORMING, on Sept. 24th 3pm PST, which will have 3 musical performaces and a FLOPPY walkthrough, at the Juicebox HQ in VOXELS.

The stage is set, welcome to join us then!

· 14 min read
Zhape

Town Hall banner by Sage Kellyn
Art by Sage Kellyn

versioning with jango

Contract crew has finished the versioning project, created the Juicebox contracts V3 repository and merged everying inside, before the repo was passed onto some wardens in Code4rena to implement a mitigation review for updates made with findings from last Code4rena audit contest.

Jango said the mitigation review will probably last for a week, and encouraged our community to stay tuned and help out with any questions or feedback that externat auditors might have.

A big work now will be working together with Peel to finalized what UX we should use to get new projects to use the V3 conract.

Projects that are currently operating under V2 will have the choice of deploying a V3 funding cycle and synchronizing, then deprecating their v2 version funding cycle. We will provide instructions for that process. But in this case, the communities of these projects will have to go through a token swap transaction, which isn't entirely ideal. If there are projects that don't want to go through this trouble, we'll deploy an ETH payment terminal and a JBController for them to migrate their current payment terminal and controller to.

For those who want to stay on V2, they're welcome to do so, it'll just be a little bit more follow-on work from contract crew.

Huge shoutout to Dr.Gorilla and 0xBA5ED for coming through and helping out in the last serveral weeks, and big shoutout to 0xBA5ED for a really intuitive solution to a little rounding error that we were dealing with last week.

juicebox.money Next Gen UI with Strath

The frontend team found out that the biggest pain point for our users, which impacts Juicebox most and make it suffer from a very high dropoff rate, is the project creation flow. After some user testing and behavior analytics, our team finally went through the way to simplify this process and make it a more enjoyable experience to get people launch their project on Mainnet.

Strath was sharing his screen and showcasing the improved UI design

The biggest feedback they had was the step 2 of the 3 steps in the current creation flow, the Funding cycles which is some kind of tiered approach and has a lot to go through. current flow

They are trying to break it down to simplify everything, get rid of the cognitive load and give people the ability to make one big decision per page.

Here's what the improved UI looks like: new flow

And Strath was explaining the tabs in the new UI one by one.

Here is the Figma page if people want to leave their comments on this work.

This is not 100% complete and there're some small elements still being worked on. They will do some user testing, so there'll probably be iterations on it down the line.

There will also be some templates, so people can select the template and just go from there, instead of needing to jump into the creation flow.

Q: Do you have any plans or any prototype for allowing a user to launch terminals from there, like custom ERC-20 terminals?

Aeolian: It's quite an easy thing to create, but the main issue is what do we do on the project page, which still need to be conceptualized what it looks like for a project to have multiple terminals. That's probably the next big design project.

Jango: I even wonder if that's in the purview of juicebox.money to experiment with, because there're a lot of ways to go about this. It seems all this stuff is best to serve as an experiment with a juicebox.money fork or something that specifically tailored towards those use cases, and finding out how to fold that in nicely will be interesting.

It gets a little complicated, but it does provide particular accounting niceties if you really want those terminals. I think, from a protocol perspective we can make sense of these logically, but from a UX perspective it will take some work really figuring out what the priorities are.

Two truths and a lie with Felixander

TwoTruthOneLie

The correct answer is 0xBA5ED.

No.3 about the socks is a lie.

MTOTM AMA with epowell101 and Michaelmaher

Background and concept

Epowell101: This concept of MTOTM started with some lived experience and some conversations they had with some early DAOs and DAOs founders, in a sense that there's a need for additional diversification early on instead of waiting untils much later and needing an OTC desk to do the swaps or to negotiate for over months.

What if we, a bunch of DAOs at their very earliest stages, pitch in to a shared pool(Juicebox in this case) and get back a token that represents percentage of the meta DAO that we have just created. So you get some diversification and also some meta governance in which you get certain number of other DAOs who are care about how you're doing and potentially could be an independent voice in your Discord or in your governance to provide an independent perspective.

As we all know, there're a lot of launchpads out there and maybe lots of use cases, but we realized that we should focus on the primitive of DAOs pitching in and getting back while referring to an oracle to get the ratio. That's where we needed a name for this concept and we came up with MTOTM( \ˈemˈtō-təm\ ), which is supposed to stand for Many To One To Many Swap.

jango: To add a little context, we're leveraging these custom payment terminals to basically accept project tokens back into them and issue another project token outwardly, and that's kind of how it ties into the infrastructure that we're working on, the protocol developers are working on. It's cool that it's scoped into its own project and has its own application, but from the primitive perspective, as everyone was saying, it's nice to use these familiar pay functions in token issuance practices.

nicholas: If I'm getting part of the ideas, it's like token swaps between DAOs and also potentially collecting token for many different DAOs and generating one token that is the representation of all those different tokens in one index fund, which allow you to do interesting things and mutually incent each other. Is that the idea?

epowell101: Yeah, that's exactly it.

Explanation of mechanism

michaelmaher shared a GIF file in the town hall channel:

MTOTM animation

michaelmaher: At the base of everything is the extensive use, if we all are using ERC-20 terminals to facilitate this process because what the DAOs pitching in will most likely be ERC-20 tokens, we'll have to navigate the use of these terminals to facilitake DAOs coming into an index, creating that index and spitting tokens back out to them.

With that, there's the ability to use different price feeds, using the Juicebox protocol. If a DAO's ERC-20 tokens coming in and they don't have a current price feed, probably because they are not traded on a DEX, we can set up custom price feeds as well.

But we also want to encompass it in the tradtional Juicebox project architecture, by using a regular project that can receive ETH and manipulate some different split data to send it out to other addresses.

Investors want to come in and spend their ETH to get an index token in the initial raise, and DAOs will also come in and get their DAO tokens in the swap. So all the swap needs to happen under the same umbrella, and that's really what MTOTM is about.

We also don't want to dilute the initial investors either. When they're coming in with ETH expecting some amount of tokens back, we want to make sure that's kept true till when the DAOs are coming in.

We're looking forward to developing some other terminals especially for this use. When you've got multiple projects coming in, you have to launch a terminal per project. Of course, that's not the most gas efficient thing, so we're also looking to help build some multi-token terminals , where you have one terminal and a bunch of tokens can come into it and help facilitate the whole process.

And the final part will be how to distribute everything. ETH will be distributed in a traditional way most Juicebox projects do and routed to the DAOs because it's a way of fundraising.

When you look at that GIF image, the whole point is to make it very simple for the users, and to have all the complexity under the hood.

Community support

jango: Shoutout to you all for really figuring out how all these interfaces work and getting a sense that this can be pulled off with the network's treasuries that we've got going here.

I think there hasn't been full time attention from a lot of the folks that really know the protocol intimately well and have built it, you all really are carrying the load and understanding how things work and prototyping and asking really good questions very frequently, much appreciate it. Hopefully as we wrap up some of the work that we've already committed to, such as versioning, NFT Rewards and stuff over the next few months, we'll be able to be more hands-on and take this through the finish line to some MVP so that we can actually see this animation play out on a website.

michaelmaher: If anyone is interested in the project, you can check out our GitHub repo. And also welcome to join our Discord server and let us know what you think.

jango: There was a grant proposal to help sustain and fund those research this past round, which didn't meet the quorum in temperature check. A lot of this type of research work is more in the background and not really in everyone's face frequently, we are trying to figure out better ways to really highlight developers from around the ecosystem who have been working on it consistently.

I think this is one of the cases that we may not have a full thing ready to go in the near future. There's been a lot of understanding of how things work and prototyping how to really push the limits of how things might work, which is exciting to me. I would love to see it supported, and obviously the best way to support is just being around and helping to answer question and prototype and actually pull the thing off. It does take time and attention, we know that it's hard to prioritize things, but be on the lookout for grants of this nature going forward.

Further discussions

nicholas: Let me run through this once more to make sure I got it clear. So the impetus is twofold:

  1. to allow DAOs to swap tokens with one another, by making contributions of their own DAO's token to another DAO's Juicebox project and receiving that DAO's tokens in exchange
  2. to enable the creation of an index fund and the fundraising for all of the DAOs that contributed their project tokens to this index fund so they can collect ETH.

Is that a good summary of the motivation?

epowell101: The DAOs and investors will all get back the same tokens that created by the meta DAO, but the DAOs will also get the ETH.

jango: I think the main thing from my perspective that is important to note is that right now we have an ETH payment terminal and a generic ERC-20 payment terminal. The ETH payment terminal is deployed and leveraged by juicebox.money. The other one is an ERC-20 payment terminal, let's say DAI, and that would work the same way.

You would issue a rate at which project tokens are issued out when one DAI comes in. If you run both an ETH terminal and a DAI terminal, you want to have the project token issuance rate be only correlated to one of these assets. Let's say 1 ETH comes in 1,000,000 tokens go out, and 1 ETH worth of DAI comes in 1,000,000 tokens go out. Now you can imagine a project token version of the ERC-20 terminal. One project's tokens get issued at some rate of the external project tokens coming in.

The interesting part is the price feeds. At what rate tokens get issued out when something comes in, and how does that relates to other terminals you are also using? That requires you to write price feeds and payment terminals. And then how do you write multiple payment terminals that can generalize this so that you don't have to deploy a new payment terminal for every project that wants to use this? You don't deploy a DAI terminal and then a SHARK, PEOPLE and JBX terminal each time. You can just have a generalized version of this, which is also an interesting problem here.

nicholas: So let's say you have a multi-token terminal that accepts SHARK, PEEL, CANU and WAGMI to create a Juicebox ecosystem index, it would not just have static rates for each of those versus the project's own token, but instead variable rates depending on the value of thos project tokens, right?

michaelmaher: Depending on the value of thos tokens, but some projects might be in their super early stage and we might negotiate a price to start, so maybe they all will have the same price. There're a lot of different ways in basically working with the prices contract set up in Juicebox.

nicholas: So the first step on the roadmap is this multi-token payment terminal to enable some of those ideas we talked about.

jango: I think the multi terminal is how you automate a lot of the operation overhead to set this up manually. I think the manual first step is to have one terminal per project token that's facilitating this, and to have prices feeds and everything plugged in, and the expectations are all set and things are well tested. And then the next step is to automate the operation overhead.

michaelmaher: Yes, we've been trying to develop the multi-token termianl and that's still in progress, so that's more of a future what this can be.

epowell101: We have stood up on testnet versions of this using the single token terminal, it's going to be very simple, because we just want to get to the MVP, but there's some UX work got starting as well.

Kmac: Isn't it an index built on token set?

michaelmaher: Okay, they kind of do this, but the reason that we're trying to be different from them is that they have these certain stipulations within a token set. One is that you have to be listed on a DEX platform or have some type of liquidity, so you have to have a pretty well launched token. Early stage projects are not going to pass that set protocol if they want to join. Also there is no real governance built in with that, you get this kind of index token per se, but the governance of that doesn't really work well. So to us, this is a different niche product that can facilitate a lot more projects out there.

jango: Lastly, just to emphasize is that this is an experiment, and there's a lot of unknowns, a lot of open questions. So let's ask those and let's hypothesize and talk about them. Who knows if it has longevity, but I think it's worth. I think there's definitely applications of this or derivatives of this concept that can be quite powerful.

· 13 min read
Zhape

Town Hall banner by Sage Kellyn
Art by Sage Kellyn

Versioning with @jango

This versioning project is a prerequisite for almost all the other protocol things, and mostly everything of it is complete now.

After the Code4rena auditing contest, there're a few changes need to be made to the protocol to ensure the protocol's risk aversion and longevity. Jango is leading the work now instead of waiting and patching problems that might rise later. A lot of the changes don't really affect the V2 features set, and everything is pretty much finalized at this moment.

The next step is to run another Code4rena contest on the updated repo. Jango is trying to get a mitigation review for the past Code4rena audit, which is to check the changes to the codes from the results of that audit, hopefully by same group of wardens from Code4rena.

The Juicebox projects contract won't be changed. This version won't be a requirement for all existing projects, which mostly won't ever run into some of the inefficiencies discovered. But new projects going to be build will use this new version.

Frontend has deployed a new settings page, a revamped and powerful settings page for Juicebox projects in the juicebox.money site last week, we'll leverage that to give project owners some confidence over how they're managing their treasuries across versions.

New settings menu on juicebox.money

In our chats, we're calling this contracts update V3 but it shouldn't be taken as another major version as V2 was to V1.

@nicholas has been exploring, with as @trebien our main contact to Code4rena, a longer term cooperation with them, by which we can get preferable rates and more flexible contests.

Nicholas has put up a proposal for a larger budget for six months or a year for Code4rena contests, if passed, we can do many smaller contests as necessary for things like the NFT Rewards or small updates to the protocol.

The draft of this proposal can be found here, and the Discord discussion happens here.

NFT Rewards might also be rolled out at the same time, unless the community insists on having it go through Code4rena as well. The NFT Rewards is something that the devs can propose new ones at any time and projects can use updated version for their subsequent funding cycles.

Immunefi bug bounty

@filipv wondered if we have a timeline for the Immunefi auditing and testing for the updated contracts. @jango thinks the Immunefi is less about auditing and testing, but more about bounties for hackers to choose to report vulnerabilities instead of exploiting them. He thinks what we offer most projects to build using Juicebox is the infrastructure as a service with the security model coming with it, but as the protocol grows and our day-to-day operations decreases, there might be a need to designate someone as an insurance mechanism.

@nicholas explained that the proposal we approved before to create a $100,000 Immunefi bounty has expired, for the reason of not implementing it within the contraints of that proposal which had a deadline. He also thinks we might consider change a service provider other than Immunefi, because they charge a 10% fee even though we are the one to custody the funds and triage the bug reports and payouts. He also suggested that the timing for a possible bug bounty should be after the mitigation review and deployment of the updated contracts to Mainnet, for we might need to make any bugs outstanding out of scope thereafter.

Devcon programming with @bruxa and ThirstyThirsty

"Thirsty Thirsty is an ancestral remembrance project disguised as the coolest food and wine club on Earth. "

@bruxa is the founder of Thirsty Thirsty DAO, this community has been in existing since 2014 and set foot into Web3 in November 2021. They are a community of food and natural wine lovers, enthusiasts, experts and Earth stewards focusing on the cultural restoration and ancestral agricultural practices which they see as a really critical component to mitigate climate crisis.

Last week, @jango talked with @bruxa, @Zom_Bae and a few other folks about how we could partner with other communities who already have a leg up on creating events and bringing people together, and how we actually could partner from a funding perspective to do things like during the Devcon Bogota.

Oct. 10th, during the Devcon week (Oct.7-16) in Bogota, will be the indigeous people's day of the Thirsty Thirsty community, @jango and @bruxa are having the idea of creating an event that's Dev focused and bringing people together in an open-ended forum just similar to how JuiceboxDAO did on NFT NYC where people can come together and share ideas and be inspired by whatever happens. Also projects running on Juicebox or leveraging Juicebox can use this space to create a space for their own community to come together, while the JuiceboxDAO can partner with Thirsty Thirsty to provide food and dirnks to accompany this event.

Thirsty Thirsty NFT membership

Thirsty Thirsty Membership NFT

The Thirsty Thirsty is a 501(c)(3) entity that can accpet crypto donations.

Currently Thirsty Thirsty has their own membership NFT minting, with which on one hand they are trying to bring people together to experience the power of nature through food and wine in the cities and land, on the other to empower and share what this tooling is with their community some of which have been left out of financial sovereignty.

They're pretty interested in how Web3 tooling can help remedy a lot of issues with the labor chain and create equity in their communities all along.

They're also very excited to play with some smaller limited edition airdrops through Juicebox as a fundraising mechanism, especially tethered to some event that they're planning.

K.Group DAO with @Jermaine.A

K.Group DAO is an affordable housing DAO, they have a unique solution to solving a housing shortage and trying to combat the affordable housing crisis in the U.S.

K.Group DAO

Solutions to housing for low-income

The house below is an actual one in Houston, Texas, which was 4 bedroom house origially (left), and they converted it into a 12 bedroom one and added another bathroom. By this moment, there are 12 people staying there already.

12-bedroom floorplan in Houston, Texas

You can also take a look at what the house is and its renovation by scrolling down to the bottom of their homepage and explore their first home.

Virtual tour of K.Group DAO's first home

What they are doing right now for this solution to house low-income individuals are:

  • rents are between $650(small room) and $800(large room)
  • all the rooms come fully furnished
  • free internet, free laundry and all the utilities taken care of
  • no first month's and last month's rent and no security deposit
  • leases are on monthly basis so tenants can move if they wish

@Jermaine also said this housing model could be used for anything anywhere in the world, for the conversion that was done is just unversal.

Goals of the DAO

The reason why they set up a DAO is that they think the DAO will be better to upsolve this housing issue with affordable housing.

When it comes to the project token $KDAO, they try to keep it as simple as possible, just strictly a governance token. Decisions to purchase any house or pull equities back into the project treasury will need to follow a governance procedure and be voted on with governance tokens.

They are an LLC entity licensed in Wyoming, so they can purchase physical assets and have bank accounts, etc.

The governance of this DAO will not only be about real estate, it might include the following according to @Jermaine:

  • house purchasing
  • renovaton
  • marketing (local churches, community centers, online housing platforms)
  • management
  • maintenance

Eventually they want to create an online platform to where those rooms are listed and anyone can access them anywhere in the world.

Their ultimate goal is to house at least 10,000 migrant families within 2 years, and be the first DAO to sign a government contract as a contractor for Department of Homeland Security to help and house people.

Two truths and a lie with @Felixander

Two truths and a lie

The correct answer is @gulan

Defifa with @jango

Defifa

With the World Cup Qatar 2022 upcoming in November this year, and being one of the first global events after Covid, @jango thinks this could be a meme shilling point in some way. And he landed on a mechanism, a self-governed game system, facilitating the incoming NFT Rewards and the NFT voting system. (If you are interested in this project, you can read the Defifa specs here, and join the discussion in this Discord thread)

Essentially it'll be a bit hard to really wrap your head around it, unless you really know how the NFT Rewards system works and how it can be extended to support this. A surface perspective the community understands the NFT Rewards contract is just 3 NFT tiers that project owners can put up on the juicebox.money site, and the price thresholds that contributions need to cross so as to get the NFTs minted to contributors' wallets. That's very much the basic case of this contract.

But this contract can do a lot more.

A winner-takes-all scenario as an example

Imagine like two weeks prior to the first day of World Cup, November 20th, someone deploys a treasury that doesn't have an owner. He can preprogram the rules upfront and the game will play itself out and end in a certain date. There is no funds in the treasury to start out, and there's zero tokens minted.

There will be 32 NFT tiers representing each of the teams in the competiton. It's a open mint, so anybody can mint any number of any of the tiers.

After two weeks when the first game starts out, minting will be closed. So everyone has their NFTs, which are all transferable and regular type of NFTs.

Let's say, we have 100 Brazil's NFTs minted and 10 Japan's minted, which will give you a sense of people's confidence of which team is going to win the competition. Now we have these outstanding NFT tokens and a loaded treasury which is the funds of the game.

At the end of the game, let's say Japan wins the competition, there'll be a self-governing process to submit a scorecard on the contract. Then all the NFT holders attest to the scorecard which they deem is correct, via a mechanism that will hopefully keep the result honest. Let's say someone submits the Japan scorecard and someone submits the Spain one, it'll be all the participants' responsibility to attest to the correct result.

Essentially all the scorecard at the end is a redistribution of the game's total funds. During the first two weeks open mint window, anyone can burn their token and get their funds back. The redemption rate is 100%, all NFTs are worth what was put in. But at the end of game, all the scorecards are the redistribution of this redemption rate. So basically a redemption delegate can be created to make all of the treasury now back the Japan NFTs instead of all other NFTs. The funds don't need to be distributed to the winners, instead they are reorganized to back the winning NFTs. Although now you can burn 1 Japan NFT to get 10% of treasury, but that'll be just the floor price of that NFT at the very least.

More complesx version for intra competition game

You can also extend this mechanism to take into account intra competition matches.

Let's say if your team makes it out of the group matches, your NFT will be backed by 5% of the treasury,if you make it to the Top 3, it can be like 3rd place gets 15%, 2nd place gets 20% and 1st place 40% of the redemption.

All the scorecards at the end are basically the resulting redistribution of what back each NFT, then everyone holding the NFTs has on-chain vote from each tier to attest those results. And you should create the value of each vote so that people can't game the system in an obvious way. Let's say 51% of all NFTs minted are Spain, if you do 1 NFT 1 vote for attestations, Spain can just say it won and then vote itself in. So you have to spread out the weight of each tier's vote across the teams based on team's total supply, or something like that.

Actually this NFT Rewards contract that we built is a version of a governor contract that lets each tier have independent voting utilities, you can create votes that recognize a particular voting weight of tier, as opposed to just one NFT in the context of the whole system. All NFTs of all teams are in the same contract, but they often have different voting capacity for attestation, they can be backed by different redemption values given the end state of that scorecard.

Other thoughts

You can also pre-allocate like 10% of the game's treasury to be shared by people who voted for or attested to the correct results, giving people an incentive to participate.

@jango thinks we should play it really simply here at first, and if it works out, it could be a cool thing that scales, you can have this play itself out in different athletic competitions and etc.

This is something that's been on his mind, and it's an extension of the NFT Rewards work that's slated to come out soon.

And there's for sure some cool game theory to tease out. Let's create something that encourages an honest attestation process. Everyone knows the real result and it's black and white, but will anyone defect? or is everyone incentivized to report correctly?

Sayid: Concerning the attestation, couldn't we bpass it by making some kind of API or using existing API to check the scores of the games?

jango: You could maybe pull in an oracle that's attesting to that result, but I don't think that's necessarily the goal here though. It will also be really interesting for the purposes of this being a generalizable Juicebox project that we can create a mechanism where the game theory works itself out, and the participants are encouraged to report correctly. That way, anyone can deploy a treasury in a game and it can load itself up and then be resovled all in a self-contained format.

I think this is also maybe an invitation to brainstorm other World Cup related shindigs that people want to stand up. I think this is maybe something worth doubling down on, and also we can get other Web3 projects in on it. I don't think this is a Juicebox specific thing that we do and try to get an edge on other protocol. This is a pretty cool coming-together celebration of the world through sport.

· 5 min read
Zhape

Town Hall banner by Sage Kellyn
Art by Sage Kellyn

Business dev with @0xSTVG

0xSTVG has been actively reaching out to some blockchain and web3 clubs at universities. The responses were quite warm, and they have been setting up talks with Juicebox, as well as having some in-person presentations and possible hackathons.

He plans to submit some proposals in the upcoming months, trying to help onboarding students and web3 enthusiasts in colleges and universities. He is gearing some of his efforts towards recruiting those types of builders.

Gplay studios with @Sayid

@Sayid came to the Town Hall 3 weeks ago, did a demo with some preliminary designs of his platform. He founded this P2E(Play To Earn) arcade platform called Gplay Studios where uses can make profit by staking $Matic and wagering against each other in classical games on Polygon.

Except for the Tic-Tac-Toe he showed last time, recently he has added another 9 games to the platform.

New features developed:

  • Game invitation link, which can automatically connect the person to a game someone else created,
  • Rematch function, which player can use to request a reset of game and changing the opponent

The Discord server of Gplay is here, anyone who is interested in his project can join and have fun over there. @Sayid also said he would be hosting some gaming nights once all the bugs were fixed.

Nance Funding cycle configuration demo with @jigglyjams

@jigglyjams did a demo on how he runs the Nance script to query from a Notion database of payouts and use those data to submit a Gnosis transaction to reconfigure the parameters of a new funding cycle.

His next step is to query payout addresses and payout amounts from proposals that have been approved and get them merged into those databases for reconfiguration of funding cycles.

Also he is going to work with @twodam to set up a frontend to configure Nance the Gov Bot in a Juicetool page. But he's also a bit concerned about where to store all the configs of Nance at this stage.

Banny drawing contest on JokeDAO with @nicholas

@nicholas was hosting a Banny drawing contest using the JokeDAO voting machenism, in order to help showcasing the JokeDAO V2 new feature of uploading images as contest submissions. Everyone could submit a Banny/Bannyverse drawing in a submission period for others to vote, and the voting would be open once the preset submission period was up.

@nicholas minted the voting tokens and distributed them by airdropping to whoever has taken part in the JuiceboxDAO governance voting on Snapshot before. People receiving this token can vote for whatever images they like, and the image that gets highest votes win the contest.

And @nicholas also made a tutorial about how to create JokeDAO contests for Juicebox projects, which can be found here.

The winner of this contest was @brileigh, and the image that got the highest votes is:

Another upcoming new feature that JokeDAO will be developing, which is also funded by JuiceboxDAO, is the executable contest, in which projects can signify winning conditions so that the winner can be executed on-chain after the contest.

@filipv suggested that JokeDAO can also set up some thresholds, such as top 3 or top 4 in the contests win. This can be useful in application scenarios such as different prizes to Top X winners, or Top X winners get to be qualified as a member of a multisig, etc.

And @seanmc also said that they're talking with IPFS about image uploads within the website, which will be an amazing integration to it if implemented.

PeelDAO updates with @Aeolian

PeelDAO recently onboarded 2 very awesome designers, @Strath and @Lawrence, respectively working on the redesign of the project creation UX and an update to the homepage. Hopefully these two efforts will reduce our currently high bounce rate for the website.

And other big frontend projects underway are:

  • NFT rewards, this is already on Rinkeby so people can play with it already.
  • Settings page, which @Jmill is currently working on and hopefully will be ready by the end of this week.
  • Versioning, a strategy to manage multiple versions on the frontend.

Some features that have been shipped:

  • CSV imports for payouts;
  • CSV exports for payouts and reserved tokens;
  • Juice SDK, which is a toolkit that makes it easier for people to set up frontends on Juicebox protocol.

Also they have been finetuning a lot of dev performance security work, running through all the dependencies and upgrading them.

One thing they are planning to implement is the Twitter verification, currently people can put anyone's Twitter into their Juicebox projects.

Juicenews newsletter new release and Juicecast new episode by @matthewbrooks and @brileigh

A new release of the Juicenews newletters on Aug. 30.

And a new episode of Juicecast featuring @seanmc of JokeDAO. And @matthewbrooks urged us to at the very least listen to the first 10mins, which should be very great!

Two truths and a lie with @Felixander

The correct answer is @Gogo, and he's a great story teller, try to tune in to his story of being surrounded by "Shark DAO" in Australia at 35'37" of the Town Hall recording.

· 18 min read
Zhape

StudioDAO updates with @kenbot

kenbot: How can the audience finances the movies they want to watch? How can we really put the audience in charge?

StudioDAO is defining in a different way what a DAO can be.

Problems in the traditional filmmaking industry

The traditional financing for filmmaking is more or less like this:

  1. you go and sell the movie to investors,
  2. investors take the equity, the rights to distribute the film,
  3. investors make 120% on their money and get 50% of everything that the film makes after that.
  4. This is not so great for filmmakers.

The problems that we're think about is:

  • Why is financing a film so hard?
  • Can we make this easier, simpler, more fluid?

The current difficulties are:

  • Filmmaking is a risky market, people are afraid of risk;
  • It's hard to invest in this industry;
  • Film distribution is a mess;
  • Movie theaters are a mess.

These above problems have contricted the people who can actually buy films or TV shows to big streaming companies, which is not great because there're only limited buyers in the market, and will lead to:

  • Filmmakers are not in control of what they're making;
  • Fans essentially become bag holders that are just getting dumped on at the end of the process instead of actually being at the beginning of it.

The solution of StudioDAO

The solution of StudioDAO to these problems and the way it should be at some point in the future, is to turn itself into a new kind of social network that solves the problem of financing premium contents.

  • Members pay to join the DAO;
  • Members get to green-light the films;
  • Members get to be on the inside of this process.

So this is going to create unprecedented freedom and opportunities for filmmakers and fans. It's a new voice at the table in terms of how things get made and a more direct relationship with all the talent they might care about.

The way that this business works right now and what StudioDAO can do in the future, can be really harmonizing. StudioDAO is going to build a system where we can partner flexibly with projects, whether they're just starting or they're finishing and just need a littile more money to get over to their green light.

The relationship between the community and the filmmakers, no matter where the filmmakers might sell the films, to Netflix or to theaters, the community participates in that and gets 30% of the revenue that the film generates downstream. So the community is not just green-lighting movies for their own consumption and enjoyment, they are essentially building the films into a part of the bigger community of StudioDAO.

By this way, it basically leads us to 3 different ways to finance:

  • Sales of the retail NFTs;
  • A community wallet that we're going to be funding at the beginning;
  • Revenues from previous projects.

The film financing fund

When we think about how the business works here in terms of the traditional piece, there's a way for us to actually create a more traditional fund that wants to play nicely with the rest of what we're creating.

You can imagine, if you had a US$5,000,000 film and you can sell $1,000,000 worth of NFTs, that should be a really good signal to people who want to put other money into the project, because it's appealing and there's people who are behind it. So we're trying to create leverage beyond where the retail market is for NFT's right now, because it's still early and the market is small.

There's a 2 trillion dollar entertainment market out there, we think that there's a clear scenario for decentralized studio that can do a billion dollars of production per year in three to four years from now. we're actually talking with some of the people who funded Kickstarter at the beginning and they shared that Kickstarter actually funded 500 million dollars worth of films in the 10 years that they've been in business. We all agreed that with Kickstarter not being focused on films and not having the benefits of everything that on-chain applications might be able to give us, I think we can shoot for 10x that in the next 10 years. Our target is five billion dollars over the next 10 years worth of films and content.

Disclaimer: This is not legal advice, I'm not a lawyer. This is what we're doing, but I don't guarantee that they won't get you in trouble if you do the same thing.

We have 3 legal entities in the US, two of them are Delaware LLCs and one of them is an Unincoroporated Nonprofit Association(UNA) in Nevada.

The StudioDAO UNA is the nonprofit that will become the million-people-green-light committee. This is the true DAO of StudioDAO, the membership of the community. It's the committee that is picking films, working on financing of films, managing the green-light fund and voting in the governance over the protocol. It's also the recipient of 30% of the participation of the contracts that we are sourcing for the UNA right now and we're sort of creating a legal structure to do that.

StudioDAO Genesis is the legal entity that belongs to StudioDAO UNA so that it can have certain kinds of bank accounts that UNA may not be able to have on their own.

The StudioDAO Backlot is a for-profit services company, it mirrors sort of the structure of Uniswap, in terms of Uniswap Labs, and then the protocol being a separate piece. Obviously we're completely different in almost every other direction, but the process of where you do the product development(the StudioDAO UNA), how do you do the things that have to happen in the real world (the StudioDAO Backlot), is how we're splitting at.

Projects on Juicebox

  1. The StudioDAO Backlot.

For the Backlot, the token issuance is 1,000,000 / ETH, while 700,000 goes to the contributor, and 300,000 is reserved for the projects owner.

  1. The Unlikely Love Stories:

This is a real project, and it will probably be the first juice box that goes live when we're ready to go.

The issuance rate is 840,000 tokens / ETH with 50% reserved rate, so contributors will get 420,000 token per ETH.

The funds distribution will be 90/10, 90% of the funds will go to the project itself, and 10% will go to the StudioDAO Backlot juice box and generate more green-light power tokens that go back to the filmmaker in exchange for a 10% fee.

The tokens distribution will be 50% for filmmaker, 40% for the UNA and 10% for the Backlot.

  1. The other two projects are all for educational purposes.

Juice newsletter

matthewbrooks: So this is a really quick preview of the newsletter.

  • Recap by @0xSTVG,
  • Governance cycle recap by @matthewbrooks,
  • Podcast episode by @matthewbrooks and @brileigh (if there's a new one),
  • Tutorials by @nicholas or @filipv or someone else (if there's a new one),
  • Recent articles on the blog,
  • Town Hall recap by @zhape,
  • Some links at the bottom.

So yeah, that's pretty much simple. It's just an easy way to recap everything happening on the content side and also giving everyone a chance to catch up with the basic goings-on. It's just to keep everyone informed and to also repurpose the content that we're making so that we can get more people to see it and hopefully get a better engagement with the content that we're making.

brileigh: Shout at @nicholas for all the feedback as well as @Felixander and @Sage for all the help for putting this together. And just echo as @Matthewbrooks said, a quick easy way to figure out everything that's going on within Juicebox without having to do the manual work to pull all the information together.

nicholas: I think this is gonna be great for getting better distribution or increasing distribution of stuff we're already producing, because I think a lot of people are consuming the Juicebox content that several members of the DAO are producing via Twitter and Discord. But to try to reach people who maybe not on Twitter or not in the Discord regularly, you can imagine, if there was a newsletter sign-up link on the website during ConstitutionDAO or AssangeDAO periods, some number of the people who participated in those fundraisings might have stuck around for the newsletter. So I think a newsletter is a really good experiment to see if it engages people. I really love what you did with the layout and everything, it looks great.

filipv: I can give a brief update on some of the legal stuff that I've been working on with @tankbottoms.

In short, we set up some structures for MovementDAO, PeaceDAO and a few other entities that are building things related to the Juicebox protocol.

We created a number of structures that are similar to what StudioDAO did. We have two different Unincorporated Nonprofit Associations(UNA), one in Delaware and one in Nevada, as well as a few LLCs in Delaware and Washington for different intellectual property. We also put together a number of intellectual property agreements and things like that.

For the short term, we're just using these for these DAOs. If you want to check out these documents you can find where they are now on this website gov.move.xyz.

But what we're working at is templatizing a lot of the things for common use cases for Juicebox projects, and then letting people put in metadata about their projects and then having it spit out nice looking PDFs. There's like a lot of interesting stuff in here if you're interested in this sort of thing that we're hoping to to roll out to more people pretty soon.

Tiles.wtf by @filipv and @peri

filipv: I also want to do an update on Tiles.wtf

For those of you who didn't see it, it's a rewrite of tiles.art but completely on-chain, so the algorithm to render the Tiles is completely in Solidity. The website is written in Svelte which is super cool because it lets people compile the components and use it with different frameworks if they'd like to. It's also a little bit more portable, so you could imagine someone setting up an npm package using different components or something else.

This website has NFT minting and mint pages as well as a fully featured Juicebox treasury, it doesn't have configuration yet. So you still need to configure on juicebox.money or another website, but for people who come here to contribute to the project, it's all working on this website. This is all open source and available on GitHub.

peri: I can talk on the Tiles project for a second. Tiles is an NFT art project that I put out about a year ago. It was actually launched on day 1 of Juicebox lifetime, it was Juicebox project No.2, next to JuiceboxDAO. The artwork is rendered using a server, so you can basically buy these NFTs but their artwork is rendered off-chain, which is not as cool as rendering artwork on-chain.

A few months ago @tankbottoms came in and decided to try putting the artwork on chain, and he did. It's amazing amount of work that he did to get that working. I don't even know why he wanted to, he just did. So big shout out to @tankbottoms, I wish he was here now.

And @tankbottoms went ahead and deployed a new V2 of the Tiles NFT contract a couple days ago. So it's live now at the Tiles.wtf website. There's still some things that are up in the air right now. The main thing that I'm concerned about is that I really want everybody who has the original V1 Tiles tokens can get the same Tiles. Tiles are denoted by a wallet address, a 40 character hexadecimal string. I basically want to make sure that everybody can get the same matching Tiles, and the V2 token that they have for their V1 token. There's a chance that the contract will get redeployed to make sure that we can settle those balances, airdrop tokens to people or make them claimable as needed. So there'll probably be somemore updates coming in the next few days, @tankbottoms and I are chatting on some of that stuff.

filipv: There's a seizing functionality on Tiles.wtf, so someone mints the Tile that corresponds to your wallet, you can mint that Tile and take it from them. And the same is true for the V1 TILE token. If you own a V1 TILE and someone mints a TILE with the same address, you can mint that TILE and claim it from them, for free. @tankbottoms and @peri are thinking about a new price revolver for the contract, so there might be a new contract soon. Maybe chill out for a few days before minting.

peri: Yeah, I would say hold off on minting any Tiles in the website for now.

filipv: One last thing, the Tiles.wtf repo has a new license on it which basically says that people can only use it if they're pointing revenues at a Juicebox project. It's a little experimental license, but we're trying out some funky stuff to make licenses for a code to do interesting things.

Protocol data by @twodam

Dune dashboard update

twodam: Here is the main dashboard for the Juicebox protocol.

If you scroll down a little bit, you can see the section called period so you can select different periods.

After you select the period, scroll back up and click apply all parameters, and all the stats will refresh using this new period.

Basically we are using the page to do the weekly reporting, so you can see there is a value new projects and active projects in this period.

There is the trending projects:

You can see many links in blue, if you click the See more, it will take you to the related dashboard of that project, with the overview data, like how much total raise, how many tokens and how many token holders in that project.

And on the right bottom of that project page, there's a small logbook where you can see all the actions taken by people there and all the payment Memos if there is any. And you can click all the links, they will take you to the relevant Etherscan pages of those transactions.

Zeugh: What's the meaning of Fully Diluted Valuation here?

twodam: It's the value that equals to total token supply multiplied by market price.

nicholas: By market price, do you mean AMM price or which price?

twodam: If they have an AMM price then it will be used, if not, redemption price on Juicebox protocol will be used instead.

And back to the protocol overview payge, there is this All users If you click the See more after an ENS/Address, it will take you to the dedicated page of that person/address. Let's take @jango's as an example:

jango: Man, I feel this is full-fledged superpowered graph interface for projects. I wonder if we need to build a documentation on how to navigate this into the info site or Juicebox High or something? maybe in a more tucked away Data section or something?

twodam: Yes! I would love to.

One more thing, if you scroll down to the bottom of the protocol overview dashboard, you can see the the current trend of the ETH in the whole protocol.

Twodam's complete Dune dashboards are here.

Juicetool update

nicholas: Can we also look at Juicetool?

twodam: On the front page, we click the Snapshot Plus at the bottom, we can go to the voting info page. In the middle of this page you can see the Status. That's where you can filter by active, Haven't voted, or Under quorum.

jango: @twodam, the frontend chops are fantastic, this is looking great. You've been constrained by the Dune UI just writing queries, and now actually refactoring the interface elements is a huge unlock, this looks fantastic.

twodam: Thank you, I'm still learning.

On the bottom left of each block, you can see the "jump to" symbol, which is basically the place you can click and do a quick jump to that specific Snapshot page from here.

jango: We need to figure out how to make sure that people starting their projects know this is here, and that they feel good about it. It's obviously useful, but I think most projects starting up need to orient governance around and all the things. What a luxury.

nicholas: You can vote from within this interface also.

Zeugh: Oh and it shows a green active if there is a proposal up.

nicholas:So to clarify, is that the list of spaces to which you are eligible to vote that you have voting tokens?

Zeugh: No, to which I joined. The ones I really enjoyed. I can't vote on Gitcoin, but I follow it to see what's going on, so I get to see it.

twodam: If you hover above active, you can see how many time left for you to vote. And if you have voted for this proposal, you can hover above voted, It will show which option you have voted.

nicholas: There's a feature for whether proposals are have met quorum yet or not, next to where closed. If there were active ones, you can sort, for instance, by haven't voted which means that the connected wallet has not yet voted on, and add Under quorum to see all the proposals that you have not voted on and they have not met quorum yet.

So I think if we zoom out a little bit, like this Juicetool plus what @jigglyjams is doing with Nance and some other initiatives altogether are like a suite of tools. Also think of the on-chaining stuff that we use for multisig. These are like a suite of tools that all the projects on Juicebox probably gonna need, given at least the most popular configuration for multisig, snapshot, DAOs. So I think this kind of stuff would be great in Juicebox High on how to set up. Possibly also build a version of Juicetool that the people down the road could deploy specifically for their project, so it has a dedicated URL and only covers their DAO's needs. It's really cool to see you do this. @twodam, when did you start doing front-end dev? When is your first line of HTML?

twodam: Oh. Maybe a month ago.

jango: The user experience of tying all these tools together, making it easy and obvious for people, giving them the understanding of standard and safe tools that should be used, it's fun to figure that out once all the pieces are in place and work our way to something more optimal over time. But you can just pass around links and they are hosted in all kinds of places for now, it's a good start and so useful, especially for weekly multisig stuff all the way through.

JohnnyD: Yeah, definitely came to figure out how we can to streamline this and connect them all together, so if someone new to start a project, they can have access to all these tools in a seamless environment. But yeah, as you said, it's gonna be interesting to figure out the users experience side of that.

jigglyjams: Yeah, totally. That's been on my mind lately, too. I could imagine, as long as we're still relying on Snapshot, in the project creation UI, you could just check a box and create a snapshot space, and we could send a transaction to create that. Along with that, we can add Nance instance once it's at that level. I'm working on submitting transactions for @twodam's Gnosis Safe payout changes. I want to work with @twodam to have Juicetool be the frontend. if possible. I can see that being really beautiful. It looks amazing, @twodam. It's been super cool. I watch you develop it and excited to see more.

The One Hundred Thousand Million Contest by @Zeugh

Yesterday there was a Hundred Thousand Million project of sustainable City based in DAO structure in Chile in Latin America, reached out to me to do a partnership with Juicebox.

They're trying to get attention of nice projects around web3. Because they're building a city and they think that building a city of the future is supposed to have creative people creating awesome stuff and they see Juicebox as one of those spaces, so they wanted to do a contest for giving a prize for a Juicebox project. They reached out to me to help organize that and we put out a JokeDAO contest which is going to start tomorrow,giving out 1 ETH to a Juicebox project that gets more votes. They're opening the contest tomorrow. Everyone is welcome to submit a Juicebox project and go to their Discord server to get tokens to vote.

Two truths and a lie by @Felixander

The correct answer is ... Zom_Bae The lie is the one about an albino rat.

· 32 min read
Zhape

Review of JuiceboxDAO x Morganstern's Ice Cream event with @Zom_Bae

Zom_Bae: I feel like the way we had it set up as Juicebox headquarters was fantastic. It was very nice for us to have one place to come together every single day and we know like what hours we were going to be there. I like the free flowing aspect of it where you know people who just come and go. For most part I think having projects running on Juicebox having the opportunity to post meetups was fantastic.

I think one of my biggest takeaways from it is that while we all kind of get to know each other by working together over Discord, Twitter or whatever it may be, I think getting to meet in real life and in person is invaluable. And this didn't necessarily start as like a Juicebox community meetup, it's kind of how it turned out and I'm glad it did. I think it strengthened a little bit our bonds and we created some. I think that was pretty magical and pretty special. I can't wait to do one on other continents so we can spread this Juicebox fan vibe everywhere. That was super cool.

I think there's a couple of things that weren't considered that we'll learn like through the process of doing it. One of the biggest things was the space isn't conducive to shitty weather. The weather was absolutely perfect the whole time we were there so our outside space was phenomenal. I think that's something we should take into consideration if and when we decide to do other events, I think that's a big one actually.

And then also it was just really rushed. The fact that we pulled this together in less than a month is pretty incredible. And the way it went so smoothly. It's pretty pretty dope got to say.

Let's see, a couple other things like I think just the short time span to get it all planned. Programming could have been a little bit better and I take full responsibility of that, but I think overall it's a fantastic event. It's got me chewing on this idea of what I've been spitting out as calling them like "unconferences" whether it's like NFT NYC or like the ETH conferences around the world. Just wear Juicebox clothes and plan something a little different so we can bond over fun things like cooking classes or we can go learn how to like surf or you know, jam sessions around a campfire because inevitably we're going to talk shop. It's like even when there were like meetup hours ever still was drawn to certain conversations and building and creating and how to make you know JuiceboxDAO Juicebox protocol the whole ecosystem better. So I really kind of like the idea of it if that makes any sense.

nicholas: I was really impressed. I think it's really cool that Juicebox funds a multi-day phase where Juicebox projects with smaller budgets can just create a little event without booking it from advance or too much prep. I think that's a really cool model that we discovered through this experiment.

Zome_Bae: A hundred percent. I wish more people took advantage of it, but being the first time and during quick time span. Yeah, I appreciate that a lot, too.

nicholas: Yeah, exactly. I think it's super powerful if there's enough density of Juicebox projects in a place. I think that's a pretty worthwhile governance proposal to fund to reserve a space that anybody can just come in and grab a slot. That's really cool.

Zom_Bae: Yeah, since you mentioned that I don't know if anybody noticed the Juicebox events project that I created right before this event. That's kind of the what my vision for that project was. I don't know I gotta think it out a little bit more but instead of trying to fund these project or these events all at once, you know, thirty thousand dollars was a lot for ice cream. It's something where we think this is worth doing to just pump a little money in every funding cycle. So it doesn't feel like such a big hit.

jango: Yeah, I feel really great about how this one played out. I think it's certainly something that was really interesting to see and the momentary aspect is awesome. I think ice cream sets a really cool tone, I think New York City set a really cool tone in that particular block in the city. It's a really cool tone Danny absolutely crushed it. And I'm excited to figure out how to support those and evolve those at the moment, but it's also going to be interesting to see what we do with everything that we dreamed up or felt or did in that moment.

Zom_Bae: And yeah, I had more than a handful of people. I think I just have this vibe like she doesn't know what crypto is. I'm not done people come up to me who are new to the space and we're just kind of timid but felt so comfortable around our group. She's like that people are just like everyone here is so nice and welcoming a couple of people.

I think it's a testament to our group of people and but that also actually reminds me of one thing in conferences like that. We should have better way to disseminate information not only for people completely new to web3 or crypto, but also for people who know the terminology and know all the technical aspects of it. Just finding ways to onboard the beginner which I know Juicebox might not be the best thing for beginners, but we can do it. I know that's the thing we can do so having whether preparing QR codes to send them to the educational tools whatever it may be. I think this will come into like the marketing realm and strategy realm down the road.

Kentbot: So it was fantastic and just as like someone who is launching projects having a place to just hunker down and be at home while you're trying to do it was super fantastic. So, thank you to everyone for making it so great and Zom_bae on the stage.

I got a text from Nick a couple of minutes ago, and he's so excited about the whole thing, he wants to actually take all of the flavors that we made and put them on the website and make them like actually permanently the Juicebox collection becomes like a part of what's for sale at Morgansterns. So I think that's super interesting just in terms of us starting something and this is now gonna have like some perpetual aspect to it. So, you know, we'll figure out what that means, maybe we can make like a buck a pint or something and put that into the Juicebox events and start to get like some money coming back into that. So maybe events could make money for us, like maybe at least cover their own costs.

Zom_bae: Yeah. For sure. Let's plan. That's so exciting. I'm glad he thought it went well, I didn't get a whole lot of time to talk to him because he was insanely busy. So I'm glad he's stoked to keeping on with us. That's great.

jango: Yeah, that dude's is seemed just eager to just get the ball rolling on crazy shit which is really exciting. And he leads us to a big wild ideas and is a very just get-shit-done like strict dude in person, which is a fascinating balance that he's of course.

He created a hell of it, we can make up like any flavor and I think from his perspective thinking about what a Morganstern's community funded ice cream flavor like monthly or whatever would look like and maybe certain cut of those sales go back into the community treasury, so there's like some incentive for the DAO to choose appealing flavors or wild flavors or whatever be a wild endgame for this stuff.

Zom_bae: jango's dropshot was the first one to go every single day. I was shocked. I think there was no way people were gonna order that, but they are gone.

jango: I was nervous. I wasn't sure like the day before it dawned on me like damn y'all, the shenanigans just don't resonate in real life like we've just been playing in crypto Twitter and Discord land.

Zom_bae: But yeah. So as everyone who was there you know has more time to think about it after this initial feedback there in the town hall chat. There's a link back to the notion planning doc and at the very bottom if you guys have any thoughts or feels about anything at all. The events moving forward, whatever it may be definitely throw it in there. There're cool things coming.

DAO NYC and DAOPlanet reveiw

jango: DAO NYC was a good scene. It was very panel driven, so there were a few rooms and like a five-person panel with a topic and I was part of a fundraising panel.

It honestly kind of felt like live Twitter, because someone would ask a hot take question and you'd go around just giving the hot take answer or whatever. And it's like bite-size chunks, but it was like facing out towards the crowd and folks like lounging around sitting around.

But it wasn't the same tone as what Juicebox's had which is like casual in the street hanging out, it felt a little bit more put together tight, like you check in and get a badge and and go up and have strict time frames for things. But it was really well organized for what it was. There were some builders as well as a bunch of VCS around and folks from various maybe sponsorship perspectives too.

As far as our involvement, I think the panel was cool. I'm super down to to do these panels every now and then. It feels just kind of like talking to folks on Discord, but you have a very constrained amount of time and you're not totally chilling on the street where you can just keep bouncing an idea and growing an idea for indefinitely, instead you're kind of stuck to a little talking point. I know a lot of folks did it at the DAOPlanet one too. I'm curious what your thoughts were and how it feel for y'all, but I think a lot of the impact we can have will tend to be like in real life over time.

Each of us being able to meander around and talk to folks that come from different perspectives and different backgrounds approaching the space in their own way and finding like how to meet them where they are and then take them to to like a point of view that that you have is going to be increasingly more important. Stuff like this might start happening with more frequency or not I don't know, but it's a cool thing that everyone should take up the opportunities if you're available to expose if you feel like it.

And then the amount we paid for, it's kind of feel paying or sponsoring that stuff for me kind of like giving back to a lot of the ecosystem, because a lot of folks from around the ecosystem are hanging out there that day and it's cool just to be a part of the ecosystem in that way. Is it very efficient for for JuiceboxDAO itself directly? Maybe not, or not as much as ice cream felt to me, but it felt like a worthwhile thing being in the conversation in that sense, but it's something I would actually approach with a little bit more critically next time.

yeah, I don't know I think like apart from the fact that we sponsored that allow us this panel seat, which I don't think is particularly valuable. And so the event was just like finding the people that you want to jam with for a bit and then duck into a corner and do so.

It's cool to have a space where that shit can happen too, right? I don't know what exactly I would do differently like I know the folks that tally were great and super cool to hang out with. I trust that they're also debriefing and trying to evolve that scene. But I think out of priorities, the only thing is to double down on what we did with ice cream and approach more ecosystem routing out contributions to the ecosystem with a little bit more caution.

Zeugh: I'm just super happy that you guys are having those events because sometimes they're not about conversions in the end like actually get into projects launched, but they do go a long way in getting the ideas and the visibility of Juicebox, but also of the ideas that we're having here going further.

seanmc: Alright, I just wanted to hop in and thank you everyone so much for giving a grants to jokeDAO. We're like super grateful and we're gonna make awesome stuff and I'm gonna be in the Town Hall and I'll show on what we're working on too, but super excited and super grateful. So thanks so much.

Actually, we have a little bit of alpha if people want to check that out. That's our V2 UI that will be releasing maybe in like a week or two weeks. But yeah, I can definitely give updates at any point.

NFT rewards

jango: We're just writing that contract and we're just refining how it's organized to try to reduce the number of transactions necessary when you're launching a project to just to the one to deploy your NFT and the other one to deploy your project or reconfigure your funding cycle or whatever.

And so that should be wrapped like my goal is to deploy the contract piece of it on Friday. I think it's becoming more of a stretched goal, but once these steps taken, we're all ready to finalize wrap-up, review and document. That's where all my attention is right now. And I think the UI with its leveraging a cloud function that @tankbottoms wrote to actually create the metadata or something. Maybe @aeolian can step in here or someone from front end.

aeolian: Yeah, I'm a little bit behind on the NFT stuff. As far as I'm aware, @tankbottoms and @JohnnyD are working closely, @tankbottoms basically built a cloud function to handle the uploading of IPFS stuff. And then Johnny is working on the UI on the actual Juicebox.money website. I think it's going quite well, I think just with the NFT NYC everyone's kind of like scheduled to be kind of back on deck the last couple of days. So let us check in and @Kenbot will certainly reach out when we have more updates.

jango: Yeah, I'm feeling really good about like this NFT rewards thing that was a big takeaway for me from a lot of the conversations we had. I talked Nicholas a lot over the days there and there might have been a few misunderstandings about how things were working like the underlying bits and what we were striving for. But I think this week is the week to really get the core of this knocked out and feeling deployable.

Kentbot: Awesome, so when you say deployed that's basically it'll be available on Rinkeby and then we're gonna test and play around there or like what?

jango: that's a good idea. We should just do a Rinkeby version, but it's all tested, right? we've written tests so theoretically it should work fine. So there won't be a lot of rinkby to mainnet delay. The biggest delay is probably just gonna make sure that we have the messaging right in the front end and that we're interacting with things correctly. And so if the contracts go open Friday, then we maybe have in like early next week to bounce the front end idea around maybe all hands on deck from both front end and contract side. But I don't think there's like a Rinkeby play time like the contract is pretty formalized already or ready by the end of the week.

Project Handles

aeolian: Yeah, I can definitely talk to that. So yeah the status of project handles contracts all the contracts side of things as being deployed. So that's really awesome. The current hang-up at the moment that we're kind of tossing around is how we handle the routing on the front end. So the routing on the actual website how someone actually what URL our projects eventually has. I don't know if a few people across the group here have been involved in those discussions. We're pretty close to coming to a reasonable solution, but anytime we're talking about routing, it ends up being quite a sensitive topic because there's a lot of edge case considerations that we need to make, so yeah, it's definitely close. Also Peri who's leading that is sick at the moment. So it's definitely still happening. Hopefully we can get something together by the end of the week.

jango: oh, yeah, it's it's delicate for sure. And the V1 to V2 contract stuff is deployed earlier today, which feels like that's a wrap from the back end thing and I think last we saw a preview from front end that's also looking pretty promising to go out soon, which will be a big step in our migration process.

aeolian: Totally. Yeah, that's another thing on the front end agenda for this week very big couple of weeks in front end, also this last week has been kind of big as well regarding some kind of security things which we're currently talking about on this town hall, but yeah, it's been it's been crazy couple weeks.

Namecheap Hacks

aeolian: I can definitely talk about the namecheap stuff as well. So those that weren't aware, Namecheap is the domain name provider that we use and many many people use in web3, but also beyond web3 as the host for their domain name. That's where juicebox.money lives. So they were actually compromised, in a way that is essentially a DNS hijacking. So Juicebox wasn't affected as far as we can tell but there were a few prominent DeFi projects that were affected. Fortunately for us and other people, the namecheap CEO and the team in general is pretty reacting quite well. They actually coincidentally in the last few months released a premium product where we can isolate our DNS from the kind of generally used DNS service that namecheap offers. So we've upgraded to that, and we're getting that free of charge as far as I can tell which is great. But yeah if you see any rumbbling about that on Twitter, that's what it's about. And yeah, we'll probably be doing a post-mortem on that as well. Well, yeah as far as we can tell Juicebox wasn't affected.

So basically we discovered a vulnerability inside, but it doesn't end up being quite impactful for the website. So we use a service called pinata for pinning our IP address starter and that is essentially how we upload project details and project logo things like that. So we paid for a custom gateway for that product and basically the end result is that because we're exposing our API Keys someone could basically unpin project metadata and that would mean that projects are basically unavailable on the website. Of course, they're still fully on chain, and nothing's affected there, but it just means that they wouldn't be displayed like when you went to load the project page nothing would come up.

The remedy step is basically that we would go ahead and re-pin all that project metadata using our custom gateway. But yeah, the end result is someone could basically write a script to take down every project off the website. And so that's pretty bad. So we acted quite quickly I'd say, but essentially now we are using our own API server for the pinata stuff. So it's a proxy server where we're not exposing any API keys and the IPFS unpinning functionality is not available from that service. So basically that vulnerability has been mitigated. It's worth noting as well that no one has actually exploited that vulnerability. It was just something that our team found internally. Yeah, please look out for the post-mortem on that coming in the next week as well.

nicholas: and I'm just curious as the last note on that. Is there any kind of duplication that data because if they had been un-pinned I presume that's the only copy. Is anyone else pinning that data because if it happened like would there be another copy anywhere of the project metadata?

aeolian: No, when you pin the same data, it's going to be available at the same content hash.

nicholas: Is anyone else pinning it are we pinning it on a node process on AWS or something or or on someone's local machine.

aeolian: I mean it's still living on IPFS. It's just instead of pinning it on the client browser but pinning it via our proxy server.

nicholas: I wonder if it would be worth having a second copy some other process pinning it, just in case anything would ever happen to pinata.

aeolian: Totally, it's it's a really good consideration, there's definitely some redundancy we can build into a pinning process for sure.

tankbottoms: And we have copies of all the pins on our firebase function.

nicholas: Oh, nice. Cool.

jango: Sweet thanks @aeolian for recovering that. Was that exposed during the trending solution that we had that at one time where the front end would pin like recently downloaded list or something? For efficiency.

aeolian: This particular thing has like those API keys have been exposed from JuiceBox. Yeah,

jango: Well bummer and grateful. No one did a thing and grateful you all did a thing. Thanks for recovering and bringing it up for future folks to be wary of.

Bookkeeping work flow with @gulan and @jango

jango: Yeah, I wanted to introduce you @gulan's section real quick. Just saying with all of this movement from V1 to V2 and movement of funds into the multisig to manage these larger scoped efforts like these events and these audits or bounties. It's like the bookkeeping role in keeping these things tight and allow multisig to execute stuff with confidence is like kind becoming a little complex it seems and I think @gulan is like the reason that things can manage to happen on these tight timelines still.

So yeah, like I was thinking about proposals and well, we're probably trying to do some walkthrough of the life cycle of proposals to bookkeeping to proposing aggregate reconfiguration onchain to multisig's signing, because the last time around there's slight gimmick in that process at the very last minute and we had to overwrite a transaction and we got it in just the nick of time. So be sweet if we all understand and recognize the process and then obviously work to automate it away via tooling.

gulan: I will start out by saying is great meeting and seeing all of you last week for those that were there. That was amazingly educational event and very happy to have gone. It was great to see you all.

So I'll start this by just doing a brief overview of kind of my process that happens on a per cycle basis and that always starts with proposals. We have that first two days of releasing the whole governing cycle. We have the first two days that kind of people actually putting the natural language of their proposal and maybe there was some type of edits that we need to make to make the actual proposal executable whether that be for our governance process or for actual funding through funding cycle.

(sharing screen)

So, you know just going here reading every proposal making sure it's executable or not is the first step. So moving forward keeping that stuff really tight making sure that there's no ambiguity for two different people to be looking at the proposal to kind of come with two separate sets of conclusions on how to execute, is what we're trying to achieve.

The second step is actually making a snapshot review document. So this is kind of putting all of the proposals and the configuration assuming that they all pass and having one where assuming that they all fail and this is really good to put down into writing because it illustrates exactly where the money should go or at least to my assumption of where the money should go.

And so that way when we get to the third step which is actually draft a config file. We've already had the community take a look at bookkeeping at least for two or three days to get the right idea from there. We finalize the config file and we save it into the Google Drive and then the final step is to actually add each individual line item transaction to our accounting sheet and I try to convert the natural language of someone's proposal into an actual machine readable line item, which in the future we can totally automate from. But some of these columns are very easy. So anything new that pops up, I just add a column to the right. I try to make sure that allow for as much flexibility in the proposal stage as possible and I use the sheet to to convert that into some type of machine readable thing for historical data to actually see kind of what the payouts were for an individual, going back to the first funding cycle. I keep this USD pivot table and this is just a manually created cell by cell pivot.

The one kind of big hole that I'll touch on here real briefly that we're in the process of discussing is the actual multisig payouts. I'm not sure how deeply I should dive into it, but when ETH was going up this wasn't really an issue because when we allocated budget towards a particular project whether that was in US Dollars or in ETH as long as the ETH price was going up, we always had a budget. But we're now kind of in a whole different world where we've allocated ETH that represents a US dorrlar amount that ETH no longer represents now. So, this new world, I guess of us being a little more cognizant of that we're gonna have to do more detailed in the proposal stage. I'll definitely keep an eye out on that.

And then the two kind of takeaways that I have on my plate to reduce this problem. It's my understanding that most people don't understand how the bookkeeping process works and how funds get denominated into US dollars. Obviously when you put money into Juicebox you put in ETH and then we pay it out in US Dollars, so for these one-time payments that are in US dollars, it's kind of confusing. So I'm going to make a document that goes over the process and how we should kind of unify this process moving forward for US dollar payouts.

Yeah, so I think number one, I'd have said for my vantage for in terms of risk, I feel kind of weird doing the bookkeeping and potentially sitting on the multisig just because of like legal concerns, I think yeah.

I mean if there is a way for me to submit payments after like doing some type of natural language or if we can automate all this stuff away, that makes sense to me. I don't know how to do that. But if there's a way to make it a JSON and somehow easier for Juicebox to process. I personally like having the stuff with @twodam because we have submitted a proposal and then someone else review it while they do the config. That to me has been a very sure way to make sure that no mistakes have been made but there's always room to streamline it, I guess.

jango: Yeah, I think both the things that @filipv suggested are goals that we're striving towards. I think we're making baby steps and understanding very tightly stretched proposals, which is that what we've just recently solved in some sense. We've created processes for them. The end game is is for sure to leverage Juicebox tools to better make the stablecoins and ETH positions, that's not like something you have to prioritize because we have manual solutions for now. But it's for sure a goal and going through these steps that @gulan outlined. I'm going to put a link to one of the current transactions that are pending, and we can kind of look at how it structured.

The front end actually submitted it to the blockchain and for me it's almost the end and I think the name of the game is just go from spread sheet to that formatting automatically. So this is a list of all the queued transactions right now which a little bit of multisig after this call to discuss on the docket here and tease out the details to make sure we're signing the correct things, but if you take the 133 for instance, open up 133 the data. This is configuring the V1 JuiceboxDAO treasury and you can see the the parameters and the values there and at the end you see payout mods and then a bunch of objects in an array which are how the payouts are formatted here. It's quoted in a percent so there's a few things that we have to get right going from your model to this. But like right now the fragile point that we're trying to make sturdier is like a human effort to have to parse all this and make sense of it to approve it when intuitively we're just gonna trust that whoever is putting up the transaction and sending the screenshots over are submitting the right stuff, but we should have algorithm to like verify.

gulan: Yeah so I can tell you that pretty much the data in this format seems really easy, I mean, I don't want to speak too confidently, but from the conversations that I had previously, just bringing in data from Snapshot and Notion which was building an automation for that. It required a little bit of structuring and I got pushed back initially for trying to fully structure all of that input data because it seems like we could definitely structure at least 90% of cases, put it through a simple machine like the accounting set that I set up and have it export into it config file like this like it seems very very doable to me if that's the end state that we're looking for to kind of automate these steps away. I'm very happy to let the needle more in that direction for sure.

jango: It's definitely gonna require the effort to manage stuff because now we have like many transactions here, right? We have transactions going to the V1 treasury to reconfigure it. We have transactions going to V2 treasury to reconfigure it. They both have unique parameters, and obviously we're tending towards the V2 sides slowly. But in the meantime, there's just a lot to juggle and if we can one thing out of time to find ways to automate I think we had at least like just the V2 stuff again. We can even put pressure on ourselves to move quicker by just automating stuff and then eventually plug it into Nance so that all the way from notion we have some weight format language to get all the way to the config file if everything is approved along the way.

nicholas: I think beyond some of this process details that it's probably a little mind numbling for people. I think broader issues that there're some challenges that as you said have become apparent in the DAO market with the way that funding cycle configuration works and particularly from the perspective of someone writing a proposal, it's not clear how to write a proposal to be totally executable and perfectly specified. So I think we're gonna have a meeting probably tomorrow or the next day ideally with @twodam in the picture as well. I'm time zone wise and hopefully we can sort of come to some solutions that make it easier because basically if you're making a payout if you're doing a payroll payout the funding Cycles are USD denominated and so, you know giving contributors getting a thousand dollars and then the price of ETH fluctuates, and they get a thousand dollars worth of ETH at its new price. That's fine. But if you're doing a funding cycle configuration to pay a specific dollar amount and the price of ETH is fluctuating and it can actually be a real problem. So we've seen this with a bunch of proposals in the last cycle specifically the bug bounty ones. There's all this like weirdness around USD denominated grants to Juicebox projects like BuidlGuidl and jokeDAO like we're denominating because the funding cycles are denominated in USD. We're saying we're going to give $20,000 or $40,000 to Juicebox projects but ultimately they got paid out in ETH. There's something a little bit weird like a mismatch between we might as well just be allocating to projects based on ETH, but I think there's some protocol limitations here that we're pushing up against. But it is a bit of a mystery from the proposal author perspective. So hopefully we can come to the best system.

jango: I think a lot of the issues are like in this V1 to V2 transition. We were utilizing the multisig quite a bit and with these bug bounties we're not just paying out the Juicebox projects, but in normal circumstances even with BuidlGuidl in Juicebox and jokeDAO, I think the answer is more put funds from V1 treasury into V2 and schedule payouts in V2 to those treasuries. We should be paying USD denominated ETH right? And I think the functionally correct thing that we're doing is paying USD to denominate ETH at a particular point in time. At that point that project can do with it what it wants. But if it happens if there's an intermediary step then you lose the fidelity of what USD denominated ETH is like at what time. If this synchronizes three transactions within a small scope of time to distribute fund from V1, dump it back to the V2 treasury and then in the projects treasury to do the conversion, if we were to specify sending USD to someone then we can't do it through Juicebox directly and then that swap should happen. we should move towards doing so automatically building the tools for that. But it's gonna be imprecise for a while. Let's do the best we can.

nicholas: I have two questions for you. First one is at what point is the exchange rate between a USD denominated payout and the amount of ETH being transferred, is it decided by oracle when someone hits the distribute button?

jango: Yeah decided at the moment of "distribute".

nicholas: okay, so because there is one perspective where there's like a two-week delay between when temp check proposals are frozen and when funds are actually distributed, but it's actually not that bad because the oracle establishing exchange rate at distribution time. So there's potentially like only a few minutes lag even if you do need to swap the ETH to USDC as long as you can get the multisig signers together right after the distribution. However, in V2, you're saying it's not possible to do USD or stablecoin payout directly from a funding cycle.

jango: We'll get there.

nicholas: Okay, it's down the road. Because like one thing that @gulan and I noticed as we were dealing with this like it really does require a full-time bookkeeping person to manage a complex funding cycle payout

jango: Absolutely.

nicholas: all right, in the first example, we're trying to get ChoiceDAO to choose Juicebox, and from their perspective, it's going to be a hard sell because if they're able to perceive some of these problems like they're already gonna have to deal with a multisig on Juicebox in some way like just added complexity like obviously that's feature also. For people who have like ukraineDAO chose Utopia payroll system on top of the gnosis, if we don't make it easier to manage bookkeeping, I think that's a dangerous comparison that perspective projects will be making.

jango: Very much on the same page, but we'll figure out if there's a priority for right now or are we trying to ship NFT rewards and stuff like that. The way to solve that is going to be through standing terminal and just routing funds between your treasuries and running payouts for any levels the terminals.

nicholas: It is conceivable to have a funding cycle configured to do both stable and ETH.

jango: Yeah right, you'll still just have one funding cycle, but you'll have any number of payment terminals that you can store funds in and have your community redeem from and pay to. And then make the payout from your treasury to addresses and to other Juicebox projects. We can imagine the payout to your other currency and in that distribute transaction that you're moving funds over. And then Juicebox can schedule payouts out from there. We'll get to the point where we can actually codify these proposals, but I think for now we just have to simplify the proposals and just deal with the trade-offs.

· 10 min read
Zhape

Front end updates with @aeolian and @peri

@aeolian: It has been a while since we gave an update, quick couple of housekeeping things on what Peel's up to. So for the last few funding Cycles, we've been operating in two experiments, which has been really great. These align with the Juicebox funding Cycles, I'll drop a link in the town hall chat for those who haven't seen it before. So we're basically scheduling issues every two weeks that is aligned with the JuiceboxDAO funding cycle. And I think what we're going to plan to do is to give a recap of the previous funding cycle every two weeks. So next week, we'll give a recap of all the stuff that was done in the last two weeks, which is going to be really really great this time around there's been so much done. So definitely don't want to miss that.

I want to highlight one quick fun feature. That was merged yesterday. So this is the ability to add Banny stickers to Memos, which is a small thing, but potentially a fun feature which some of you have been enjoying. So thank you for everyone who worked on that particularly JohnnyD who led the implementation. Check JohnnD's twitter for a video demo of this.

There's four big things in flight at the moment. And I'll list them out in order of the time that they'll be shipped more or less.

  1. The first is giving projects the ability to relaunch on V2 and giving token holders the ability to migrate their tokens to the V2 project.
  2. Second is V2 project handles, which is being led by Peri. Right now projects on V2 don't have handles like they did in V1 so that is adding support for those.
  3. The third is NFT rewards for projects. Essentially it's giving projects the ability to specify like if you contribute a certain amount of funds to this project, then we will reward you with an NFT. So that's going to be really exciting giving projects another avenue to get funding which is great.
  4. And then the fourth is obviously veBanny and staking.

So I will quicking give an overview of what's in store with V1 V2 migration, basically we need to give V1 projects the ability to relaunch on V2. So the canonical example is juiceboxDAO. We're a V1 projects. We also now have a V2 project but none of our funds are in the V2 project.

What's gonna happen is the projects will re-launch on V2, JuiceboxDAO has already done that so we have a project on V2. They're then gonna move their whole balance to the V2 project. They're going to add another payment terminal to the V2 project, and this is a special payment terminal where it'll accept a V1 token and then return the V2 token in a 1:1 exchange rate.

So basically if I have Juicebox V1 token, there'll be a place in the interface to go to swap my V1 tokens for the new V2 tokens. And that's pretty much it. So the contracts are more or less done. Thank you to jango Dr.Gorilla and whoever else worked on that. That was really quick turnaround. And now it's pretty much up to the front end to get the UI done for all of what I just explained. And then we'll finally have upgrade path to some V1 projects to get on V2 and use all the cool new stuff.

@peri: I think as everybody knows we still aren't supporting project handles for the new V2 projects. And this is basically just has to do with some of the changes that are made in the contracts. We used to store a handle for a project on chain and it requires a lot of extra finessing in the contracts because we had to make sure that people can use the same contract and that handles could be transferred and reserved for certain period of time and claimed, there's a lot of functionalities to bake in. So with the V2 project contracts, we just skipped over all that because it ended up not being very necessary for the functionality of the contracts themselves. But the downside of course is that it's really nice to have in the app to be able to look up projects and search for projects.

So we've been working on another layer, another contract to add into the existing contracts that will support handles for V2 projects. It is not quite finished and it's not on mainnet yet. But we do have everything kind of functionally together so I can give a demo of how it'll work in the app and explain how it works pretty quickly.

(screen sharing ongoing)

So I've got this empty project here on Rinkeby, ID 4117. And we are going to set a handle for this project.

We've got a two-transaction-process for setting a project handle. And so the way that this works is we decided to use ENS names to handle the uniqueness of project handles what I mentioned earlier for making sure that handles be passed around and exchanged. There's a lot of complexity there that ENS has already solved really beautifully and so we built the system around ENS names. The idea here is that if you want to use a handle for a project you will need to own the matching ENS name. So for example, I just got this ENS name on rinkby testinginprod.eth and this would allow me to set the handle of this project to testinginprod. So I'm gonna do two steps here,

  1. I have to own this ENS name first of course, I'm going to set the ENS name testinginprod.eth and this would be one transaction. Once this completes, step one will be done.
  2. The next step here is to actually set a text record on the ENS name. So if anybody's used the ENS name app before you'll know that you can come down and set these text records for any number of different things. We are using a particular key "Juicebox project ID". You can come and set this property in the ENS name app manually if you want, but that's a little bit of extra work. So we've made it nice, pretty and clean in the app and you can basically come down here and click this button and we're gonna set that value in the ENS name text record to the ID of this project. So this one is 4117. So I'm going to send this transaction, which is the same as if I just came over here and just manually put 4117 here. That'll show up here if you got the handle set up.

Most importantly that'll allow your project to be searched on the projects page. Right now the search bar works by searching for project handles and V2 projects don't have handles you can't search for them. It's very lame that is now a thing of the past as soon as you set a handle for your project. Your project will be searchable.

An important thing to note is that either of these things change, for example if you were to transfer the ENS name and someone else changes that text record, your handle will go back to empty. So you have to have both of these things set constantly or if you were to change this to some other ENS name, your handle would go back to empty.

Another fun fact is you can also actually do subdomains here.

We will hopefully have that on mainnet this week. I'm pretty sure we're doing. some just some last-minute things, but mostly everything is good to go. So expect it pretty soon.

@0xSTVG: So does that mean that I could create multiple projects with subdomains of my ENS?

@peri: You could. But you can't have multiple projects using the same ENS name. So if you had like STVG.eth, and you want to do like one project one.STVG.eth and the other project two.STVG.eth, those could be two separate handles for different projects.

@mieos: Once we get that up and running, I think a screen recording of you going through that or WAGMI can put together a little infographic on what it is and how it works, especially when it gets up to the subdomain part, it's just technical enough.

veBanny by @Jmill

I want to show a map with the veBanny stuff. I've been doing some work on the subgraph implementation to index the user tokens and interact with them. Right now we had a couple of big steps forward. One thing is there's now a metadata file to parse for all the the characters or the variants so you can go through and scroll through the characters and figure out which one you want and then you can see them all in here, too. So that's been a nice upgrade because you can pull that all from one place now.

(screen sharing ongoing)

So these are NFT positions that I've taken on this account. So you like lock positions that are actually coming from on chain. And then you can interact with them also, so I can do that to extend the lock or I can unlock the ones that have finished. So I can take this one and extend the lock like a thousand days. Then it takes a minute for the graph to re-index it, but it'll show up 30 seconds later with the new lockdate.

And then other than that I showed this last week, we have a new contract where you can mint for one second just like test the unlock and redeem stuff. But yeah, I showed this on the last demo where you can also like take a staking position and actually mint these things through the front end works also.

quizz time:

The answer is....

Nicholas

  • As a student I made jewelry and garment.
  • I was a nationally ranked debater.
  • I haven't been Malta before.

NFT update by @JohnnyD

@JohnnyD: I'll just add a few sentences to what @aeolian has summarized before. We're gonna be automatically rewarding contributors NFTs when they contribute above a certain amount. and then the next step will be adding a restriction around, such as time restrictions so ensuring that those NFTs are distributed only before a certain funding cycle. But for now, we're just going with the amounts.

Announcement from @briley

@briley: Yeah, thanks. I was just gonna make a small announcement that Matthew and I are recording podcast episode with lexicon Devils on Thursday if you have any questions that you would like to ask you can let us know. Otherwise, we'll be doing that in advance of the JB MorganStern's voxel slash IRL event.

· 21 min read
Zhape

Warning of Influx of new members.

filipv: On June 7th, 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

· 11 min read
Zhape

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.

· 25 min read
Zhape

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!!!!