Peel Updates​

Website update walkthrough by Strath​

This is a project that includes redesigning the home page and then creating some supporting pages, such as About Us, creating some case studies, activity feed, and so on.

The purpose of this project was to make the project page a lot more functional, highlight the project creators, highlight the projects themselves, and then increase contributions as well as project credit, making it a lot more clear and concise for users to come in there, getting a few different value competitions.

Hero Section​

The section of trending projects have been pulled up in this iteration. And also we are about to implement project tags and introduce them immediately more as a sub-heading, so that when someone lands on the page, we can give them the option to take a look at the different categories of projects and click into them. It also serves to free up this space and have only one primary call-to-action, which should be working very well.

• Hero section discussion

Jango thought that the main sticking point right now seems to be the character set, art and style, so pulling Banny off the hero section seems a trade-off here.

Strath was initially hesitant to pull it off due to the new hero illustration being very nice, but they have leaned more towards having a functional homepage to balance aesthetics and functionality. Strath thought that functionality will be the one really drives people to use our protocol, especially by pulling the trending projects above the fold, which will help people understand immediately what it is and inspire them to create their own projects. Tjl also mentioned that highlighting the project art here is important and a chance to let creators and their art to shine as well.

They all agreed that there will be a very cool challenge in how might we make sure that there is always a trending Banny up here via the trending mechanism.

• "Create a project" Action

Nicholas asked about the "create a project" feature and the reasoning behind having it on the homepage. Strath explains that they considered different options, but ultimately decided to focus on showcasing projects and their content on the homepage. They removed the call to action for exploring projects and made creating a project the primary action they want people to take. However, exploring projects is still a built-in part of the experience, similar to other NFT marketplaces like Opensea. The idea behind this is to make people aware that creating a project is possible, while still allowing them to explore projects by default.

Features Section: Built for ideas like yours​

This section is just reassuring people like "This is what we can do and for people like you. " We help DAOs, Crowdfunding, NFT, Creators and builder. Big shoutout to Sage for these epic illustrations which are super nice.

Features Section: Success stories​

During the user testing, the main reason most people had used Juicebox or felt trustworthy to use it was the fact that all the these big projects have put so much money through it and it worked without anything bad ever happened. We are really highlighting the fact that we've had a ton of ETH come through the platform and people have used it successfully, which really helps cement that trust with new users.

Features Section: How Juicebox works​

This section is pretty straightforward and Filipv's new copy has been implemented here. And in the actual build of this, there will be an animated effect with this line going down with scrolling.

Features Section: Why Juicebox?​

This is a really cool section which is just giving people a run-through of some of the benefits to use Juicebox, really highlighting why Juicebox is so good and giving them the tools to explore without having to read the docs and really do their own research.

Features Section: Juicy Picks​

The idea behind this is: each month we will select five projects and give them the tag of "Juicy picks" and then they will jump into this section.

And we will have 1 featured project, which is like a huge call-out. This would be really interesting to use as a kind of marketing tool, where we can run various competitions to get projects featured on Juicebox for the month, which could help drive a lot of engagement.

There should be a lot we can do with this in the marketing visibility sense.

Features Section: Explore categories​

We will have project tags coming soon, so there will be full project categories that people can scroll through here and browse the various categories, whether they are fundraisers, DAOs, NFTs, Art projects, Photography, etc.

Final call to action​

Project Tags by Peri​

The background of this project tags is that we want to allow project owners to tag their projects with up to 3 labels that they can pick from a pre-defined list of 10 different tags. And the main goal is to increase discoverability of projects.

For people who are coming to Juicebox right now, it's pretty hard to find random projects that fit particular interests unless they already know the name of them, or they will be just browsing trending or the latest projects that were created.

Once project owners add some tags to their projects, people will be able to go the explore page and filter by a specific project tag. The idea is to make it more fun for people to actually browse projects and hopefully find some projects that might be interesting to them.

The project tags will be a big win and it will also be shipped together with an improved search functionality as well. Right now people can only search for projects by their handles, when the search functionality gets updated, they will be able to search for projects and match things, by their names and also their description.

The reason why it has taken so long to implement this new search functionality is that we've been building on a new tool called Sepana and it became a little too tedious to deal with some of their growing pains and we've been waiting on them to fix some things.

But in last week, we've updated the whole infrastructure of that to be built aound the database that we've built in to the APP and given up on Sepana. A whole bunch of updates coming with new features will be coming verys soon, which will be a pretty big update and very fun one.

JBX V3 Migration Update by Aeolian and Jango​

We have officially announced the start of JBX V3 migration this week. Token holders of V1 JBX will be able to migrate their tokens to V3 JBX which will be redeemable on the JuiceboxDAO V3 treasury. Also our Snapshot strategy accounts for V3 JBX now so it can be used for voting on Snapshot.

Jango said it's fun to reiterate the function of legacy JBX and that of the new V3 JBX, they are backed respectively by these particular treasuries and are the effort of moving all of our operations from V1 to V3. We are now progressively moving funds from V1 treasury to V3, V1 JBX won't be backed by anything there anymore. In order to maintain the redemption value, people will need to exchange it for V3 JBX.

The journey we've travelled so far to get here, was really the motivation for all the versioning work we've done. Jango was very relieved and very impressed in many ways by the effort it took to get here and the fact that we have pulled it off.

Jango has moved his JBX holdings over to V3.

The instructions for JBX migration:

• JBX V3 Migration Guide by Aeolian;
• JBX migration video tutorial by Matthew and Brileigh

Versioning History by Jango​

Jango wrote a blog post in the day when he migrated all his JBX over to V3, which is one that he has been wanting to write for a long time to recap our versioning history.

He felt very good to write and recall all the steps to get to where we are, giving a very broad stroke reflection on where we started and how we got to where we are today. It's not perfectly linked to other pieces of content over time, but hopefully it at least serves to tell the versioning story and give some rationales to the trade-offs that we made along the way.

Jango also talked about how the versioning work has made the development process more laborious for those trying to make cross-compatible extensions or reference documentation and addresses. However, he believes that building on a stable set of contracts will bring long-term stability to Juicebox.

Jango expressed gratitude towards the DAO for backing the versioning process, which has been expensive and patient. He feels that the commitment made by the DAO to this process will provide Juicebox with long-term stability and prepare it for any future versioning work that may need to be done.

He also thank folks at Peel for building these great experiences, and the contract crew for writing this and testing it along the way including Dr.Gorilla, 0xBA5ED and Viraz for their heroic work in making all this possible over the past year and a half to two years.

Juicecast New Episodes by Matthew and Brileigh​

Matthew and Brileigh recently published a new Juicecast episode featuring Jigglyjams, who has been one of our contributors for a long time and building Nance, another DAO tooling in our ecosystem.

Next episode, they will be interviewing Chris Carella from PurpleDAO. Recently there was a proposal in Purple DAO to fund a developer in residence through a Juicebox treasury. 6.9 ETH was funded for this residence by Purple DAO and the Farcaster ecosystem.

Also they plan for a special ETH Tokyo Peel episode to chat with Peel team members Strath, Wraeth, JohnnyD, Tim and maybe Aeolian.

Prop House Voting by STVG​

Juicebox's 1st Open Funding Round on Prop House created by STVG is live for voting. STVG encouraged everybody to vote.

STVG created a Juicebox project for this purpose, where the grants from JuiceboxDAO will go into that project while the top 3 winners of this open round will be added to the payouts of this project and distributed with 0.3 ETH each after the voting is ended.

STVG said this is a really good opportunity for us to create some sort of intersection between Nouns and Juicebox, and give a little bit more visibility to Juicebox,

Thirsty Thirsty Updaes by Bruxa​

Jango recently put up a proposal in Thirsty Thirsty Snapshot Space to help create a Thirsty Thirsty treasury to manage the funds and membership of its community through Juicebox. This will allow them to reinvigorate their membership and link to other project ideas.

Secondly, they are working on an interesting project with one of their partners, focusing on experimenting with selling staples with crypto, specifically flower. Bruxa is excited to keep iterating on this project and launch it on Juicebox.

Finally, they are doing a charming NFT NYC activation on Saturday, April 15th, where they will be hosting a flower and wine tasting with an amazing wine shop in Williamsburg called Dandy Wine.

Token Resolver Theming Demo & Project Cards by Nicholas​

Project Cards​

Nicholas developed an experimental contract, the Juicebox project cards contract, which is an 1155 NFT contract that lets anybody mint an 1155 NFT that replicates the metadata from any of those Juicebox projects.

People can use the etherfunk dedicated page to interact with this contract and mint a project card of Juicebox project, by inputting the relevant project ID and at least 0.01 ETH.

And the project cards minted can be found on OpenSea at this page.

Theming option​

The DefaultTokenUriResolver contract is the one that generates the default orange theme for project NFT metadata in Juicebox. On this contract, Juicebox project owners can have access to the function called setTheme, where they can pass their projectID and HEX colors to update the theme colors of the metadata to whatever they like.

Another more visual option to do this is at the etherfunk setTheme page.

Staking Via ERC-20 terminals by Jango​

The contract crew tried to create a pull request against the JBM repository, aiming to accept a project token.

Consider a project that accepts ETH and issues NANA tokens in return. The team is currently testing a method for another project to accept NANA tokens and generate NFTs, which can be burned to reclaim NANA tokens. To accomplish this, they are utilizing the juicebox.money website and frontend as the entry point for a basic staking mechanism through ERC-20 terminals. By limiting it to a specific application, they can create one-off contracts to solve staking issues for multi-chain organizations or other purposes.

However, the frontend is typically a hurdle as it is crucial for accessibility and ease of operation by users. Jango is contemplating how to leverage the tools and extensibility that have been developed with Juicebox to build various applications that can reuse similar visual elements without requiring significant effort or starting from scratch.

One example could be a "Stake" button for staking, and a "Unstake" button for redeeming, both wrapped in a Juicebox treasury for standardization and interoperability with other treasuries.

JBX V3 Migration by Jango​

The JBX V3 migration is on the final finish line. Jango has moved some of his tokens into a vault to test stuff out.

We are just wrapping up a very clean and safe UX for the migration purpose. Next week we will have more to announce together with the actual instructions to migrate tokens. Huge ups to the versioning efforts, and shoutout to Aeolian for his great effort in putting all this togerther.

Peel Updates​

Preliminary Home Page Designs by Strath​

Peel is working to enhance the functionality of our juicebox.money homepage by placing greater emphasis on project creators, and by making it easier for users to discover relevant projects in different categories.

They have redesigned the main navigation bar, reducing it to three items with subcategories, placing greater emphasis on the "create a project" function and simplifying options on the right-hand side.

Peri's project tags will be prominently displayed at the top, significantly enhancing discoverability of relevant projects.

In the central section, they have incorporated project cards that will showcase trending projects.

They are also planning to feature a 'Success Stories' section that will showcase case studies of previous projects. Rather than linking directly to the projects, this section is likely to provide information about the successes of each project. The team may use Filipviz's excellent work on case studies for this purpose.

And an area for docs:

Additionally, they plan to introduce a new section called 'Juicy Picks', which will feature the most popular projects as voted on by the community on a monthly basis through polls hosted on Discord. These results will be displayed on the website using an exclusive project tag named "Juicy Picks".

Lastly, we will have exploration section by categories:

Email Pay Event by Wraeth​

Now users can edit the profile to add their bio, email address, Twitter accounts etc.

• If someone makes a payment now on Juicebox, they will receive a transaction receipt by email if they have added in their profile:

• If there is any activity in a project that a user has subscribed to, such as payment events, they will receive email notifications about the events to their registered email address.

Token Migration by Aeolian​

There are still a few more steps that need to be completed before we can migrate our tokens, but we are now in the final 5% of the process.

Next week, we will provide clear instructions and visuals to assist with the migration. We are optimistic that we will be able to complete this versioning soon.

Pay Modal by Peri​

Peri is currently working on a improved pay modal, which is the window that will pop up when people are going to pay a project.

Upcoming Projects by Tjl​

Peel is currently completing updates to several pages on the website, including the home page, the About page, and the DAO page. They plan to unveil these changes over the course of next week.

In addition to these updates, they will be revamping the project page to better cater to contributors and project creators. They will be rethinking the design from the ground up to display more relevant information and attract more contributions.

Token Resolver by Nicholas​

Previously, the project NFTs representing ownership of projects on Juicebox had no metadata. However, Nicholas has recently developed a TokenUriResolver that provides dynamic and customizable metadata for Juicebox's project NFTs.

This token resolver comes with several features, including the ability to view live project stats in an on-chain-generated SVG, customize colors for a project's metadata, and use a custom metadata resolver contract to replace the default entirely.

For more information on how this token resolver works, you can check out the documentation here.

StudioDAO Updates by Kenbot​

StudioDAO plans to sign a contract between StudioDAO Backlot LLC and Tiket to Space LLC to establish an investment relationship and downstream revenue stream for both the DAO and Backlot.

Meanwhile, production for the Ticket to Space film has recently begun, with Fernando, the director, and Pablo attending a Blue Origin event in Orlando. There, they obtained behind-the-scenes footage and interviewed several executives about the prospect of sending someone from China on a Blue Origin spaceflight.

Prop House Juicebox Open Round by STVG​

STVG has launched an open funding round for Juicebox on Prop House, inviting anyone to propose ideas that they believe will benefit the creator ecosystem using a Juicebox programmable treasury. Once submissions are closed, JBX holders will vote on the proposals, and the top three will be awarded 0.3 ETH each in funding.

Defifa Updates by Jango​

In mid-April, they plan to launch a competition for the NBA playoffs, along with a create flow that enables anyone to design their own tournament game. Mieos and Sage are developing exciting ideas for the NBA competition, including the use of canned beverage artwork to represent each NBA team.

Jbdao.org Updates by Twodam​

In the town hall, Twodam presented the improvements he and Jigglyjams made to jbdao.org, where we conduct our Snapshot voting recently.

• New UI design, now we have more graphics;
• We now have a VotesBar to indicate the status of voting;

• Sorting by fields, desc or asc;
• Now we have unique short link for proposals, e.g.: https://www.jbdao.org/p/353;
• And a sidebar to display votes

• A pop-up for information of voters, showing their delegation status, voting history and voting power, as well as enabling more convenient voting delegation.

Juicy-reimburser by Filipviz​

Presently, when DAO contributors are deploying Juicebox contracts, distributing JuiceboxDAO payouts, and distributing reserved JBX tokens, they have to pay the gas fees incurred in these transactions on their personal account first and apply for reimbursement from the DAO with individual proposals.

Filipviz recently submitted a proposal to authorize the reimbursements of these payments by the DAO's multisig, and this proposal has been approved by the DAO earlier. But fetching all those transactions and the addresses executed them and organizing the reimbursement details before queuing the transaction manually can be a very annoying and backbreaking work.

So Filipviz developed a Node.js application caledl Juicy-reimburser to help facilitating this task. With this tool, user can specify a Gnosis Safe or any Juicebox project and a time range, it will grab all the relevant transactions from them and build them into two files, one being a JSON file for Gnosis Safe Transaction Builder and the other one a regular CSV file. Users can use these files to execute transactions to reimburse those gas fee with a Gnosis Safe or some APP like the Disperse.

On the town hall, Filipviz demontrated how to build these files with Juicy-reimburser and use the JSON file to queue a transaction on a Gnosis Safe multisig.

EduDAO with Felixander​

Felixander came to our town hall and shared some of his thoughts and plans about a project temporarily named as EduDAO, and wanted to get some feedback from our community regarding the governance models of this project.

The concept of this project is to ultimately create a network of schools that shares an open source curriculum that is blockchain oriented and allows anybody to create a school and make use of the curriculum. And this is also done in an attempt to make changes to the education system and the accreditation system, which in Felixander's view had been broken for quite some time.

According to Felixander, there will be 3 phases to accomplish the high level goal of this concept.

1. Setting up a tech lab in a public school. This something Felixander had managed to accomplish by coming into agreement with some school in Los Angeles, the 2nd largest school district in U.S. The tech labs are meant to teach technology and innovation.
2. The next phase will be create some kind of after-school program.
3. At the last stage, it would evolve into a full blown school.

Felixander expected that it might take about one and a half to two years to ride through these three levels, with all the necessary funding and support in place.

He thought that it would be more appropriate that the EduDAO doesn't directly manage or get involved with the funds, but to focus on the development and curation of curriculum instead. And he's trying to figure out a tokenomic system where educators who are putting more efforts into this DAO will have more decision making power.

In terms of the targets of EduDAO, although Felixander has mapped out from K to 8th grade, but the plan would be a full school system covering K through 12th grade. He also introduced some expected results of students from this education system by giving a rough example about an 8th grade might be able to do.

STVG is currently also working with GeniiDAO, which has a plan to set up a project on Juicebox, on something to a similiar effect. They are discussing about some ideas of DE-SCHOOLING and open source curriculum resources. They thought maybe they might to able to share thoughts and work in collaboration with Felixander in this respect.

ComicsDAO Updates by Gogo​

ComicsDAO recently started an open edition NFT mint of Nouns Comics #1 Generative Cover, at the time when they are about to publish the physical comic book for Nouns DAO, and all the proceeds from this sale will be used to purchase physical comic books which will be donated to children's hospitals in North America.

Peel Updates with Peel team​

For the branding refresh Peel delivered last week, we have had pretty positive responses from the community, while at the same time we are also seeing a bit of uplifting in our traffic.

Project Tag by Peri​

We are adding a new data structure to projects which allows project owners to tag their projects with up to 3 tags from a list of 10 different pre-set tags available. This will open up some possibilities for actually discovering projects in Juicebox.

Right now, the search function on our "Explore projects" page is quite simple, supporting searches only by project handles. We have recently overhauled the search function using Sopana, so that the searching experience will be greatly improved, especially when we have tags in place as well.

We'll be able to highlight projects in certain categories across the APP, so as to make it a lot easier for people to create projects on Juicebox and get them exposed to their potential supporters.

Profiles And Events Notifications by Wraeth​

Last week we shipped the function to support editting user's profiles, where people can add their profile picture, bio, Twitter handle, website and etc.

Another useful function that we are going to integrate is the association between email address and wallet address of the users. This function, which will hopefully be shipped within this week, supports the event notification of projects, so that if someone pays a project, they will be able to receive notifications of any future "pay events" happen in that project.

Front End Support of JBM by Aeolian​

All new projects will be created with JB3.1 contracts. And NFTs will be deployed with new NFT contracts, which will also support NFT collection category and royalties, the two functions yet to be exposed in the Juicebox.money front end in the near future.

Also Aeolian will be coordinating with the contract crew and some other contributors to work on the token migration process, where eventually we will need to migrate all the tokens from V1 JBX to V3 JBX.

WAGMI Bake Sale with Mieos​

At the beginning of February, when WAGMI Studios renewed its recurring payout, their proposal was not approved by the DAO. But due to some following bookkeeping error, they were mistakenly paid according to their last approved proposal for another two cycles.

Both for a purpose of crowdfunding to return the funds back to the DAO, and for a purpose of experimenting an open edtion NFT mint with Sage Kellyn's new artwork, they set up a Juicebox project called Cosmic Bake Sale.

Peel Update by Tjl​

Brand Refresh And Website Reskinned​

The Peel team has been working on a brand refresh project recently, in collaboration with WAGMI Studios and others. Today they have collaboratively designed and shipped the new brand and our juicebox.money website.

We should shout out to Strath for leading this effort, to Sage for the incredible illustrations, and to the rest of the team, especially JohnnyD and Aeolian. All of them has done an amazing job together. This is absolutely a tremendous effort from the entire team. It was only two weeks ago that we started to discuss and work together on this direction. Then in this period of time, the team managed to define the direction, collaborate with WAGMI Studios, make the entire brand refresh, get it approved by the DAO and finally publish it on our website.

Hopefully we will get some comments and feedback from the community around the new brand refresh.

Not just the home page, literally the whole APP is taking on a very different look, in areas such as create flow, project discovery, project pages, etc.

Features to be released​

Not only have they shipped the brand refresh on the website, but they have also been very busy working with some other features that will be shipped soon.

• Profile settings, wallet auth and email engine by Wraeth. He has done a really fantastic job of actually linking the user's profile pages to their wallets. Now users can connect their wallets and then essentially personalize their profile, where users' email address can be added and in turn be used to kick off some product-based email marketing at some stage later on.
• Project tags. This is a feature that Peri has been working on lately, which will enable us to tag different types of projects such as Art, NFTs, Games, and so on.
• Leaderboard and announcement notifications. Products also developed by Peri. The headboard is going to be visible in the new footer on the homepage, while the annoucement notifications on the top right with messages letting users be informed with the updates in our ecosystem.
• JBController3.1 and JBETHPaymentTerminal3.1 support by Aeolian. After the Multisig signing a transaction for the migration of these components , the front end support of these new versions of contracts is currently at a testing stage and will ready to go very soon. Also as result to this upgrade, the gas fees of NFT deployment in Juicebox protocol will be lowered dramatically, thanks to the efforts of our contract crew.

L2 Update by Jango​

During the past few days, there has been some hefty gas spikes, moments when the protocol felt very unusable, which is something we have always known to be true, it's the trade-off the Ethereum Mainnet.

Just like we'll figure out how to operate organizations with independent treasuries on mainnet, it has in some sense been an open question revisited over the past couple of years that we may need to have separate treasuries and memberships across different chains. This question is now being heavily discussed in the thread of # Juice Distributor under the Protocol channel.

Essentially in the next stage, we will try to run a new treasury on a L2 network, to experiment with a few different things and attempt to take on a strategy that won't overburden Juicebox or the organization that runs on this treasury right now.

Over the past while, we have noticed the tax that it takes to do versioning and migration work on the core treasury. Even if expansion in other L2s is something that JuiceboxDAO might want to adopt in the near future, it makes sense to de-risk by running a separate treasury with its own incentive structures which is related to JuiceboxDAO through the regular Juicebox treasury components.

Jango wrote a blog post to summarize his string of thoughts about this matter derived from the recent discussions. There's not much specifics at the moment, but he hopes that he will be able to share them on a more regular basis, when they are available in the near future.

Token Resolver Preview by Nicholas​

The new token resolver will look something like this for projects in Juicebox protocol.

If project owners want to try a customized theme for their token resolver, they can do it with the default token resolver contract, or implement from this etherfunk interface which will be more convenient by just inputting project ID and relevant HEX colors.

If people prefer their own image setup, they can also go to the token resolver contract, which is like a main registry contract. Project owners can set their own token resolver, which will entirely generate image with whatever contract they want, on the condition that a few codes of solidity will be needed.

The setup is very nice because the token resolver contract points to the default token resolver contract, in which case we will be able to change what a default resolver looks like, to add metadata or to improve other details, without overwriting what has been made by the project owners with their own token resolver.

This feature has been deployed on Goerli testnet, when the proposal to extend the permission of the multisig for this product is passed, it will also be released on our mainnet APP a little bit later.

ComicsDAO x Juicebox Art Reveal by Nicholas, Sage and Gogo​

Here is the artwork delivered with the efforts of WAGMI Studios and Nicholas. It will be submitted to ComicsDAO and printed on the first edition comic book of Nouns DAO.

Through the QR code on the bottom, people will be linked to a Juicebox project and can mint a limited edition NFT of this artwork. The proceeds from this NFT sale will be split between WAGMI Studios (50%), ComicsDAO (25%) and JuiceboxDAO (25%), which is also a good way to showcase the distribution mechanism of Juicebox protocol.

This artwork went through a lot of different iterations, they came to an agreement that we should try and create some Sage Kellyn art that brings the Juicebox and Nouns communities together through a fun scenario. And NIchilas thought that we had learned a lot about the creative process of doing a more involved illustration, hopefully some of that experience can be taken forward into future projects.

In the process of deciding which Nouns characters to include in this image, Nicholas suggested that we choose those Nouns whose owners are active and relatively more influential on social media or Twitter, so that they will be more emotionally involved in this artwork.

SongADay Project by Nicholas​

At the request of Nicholas, Jonathan Mann aka the SongADay man, made a song all about Juicebox.

Like all the other songs he produced, this song was put on auction as a NFT on the website of SongADAO here. So Nicholas created a Juicebox project to crowdfund and use the raised funds to successfully bid the NFT, which in turn was transferred to the multisig of JuiceboxDAO.

Nicholas also thinks it extremely interesting way for an independent musician to fund a whole NFT DAO platform, and the mechanics they are using might also be informative for Juicebox projects.

Brand Refresh Representation by Strath​

Over the last couple of weeks, we've been talking a lot about the Juicebox brand, moving into some new audiences and really building the trust with them. We've come to a conclusion that if we want to grow, build trust with new audiences and get bigger project etc., we will need to think of building a brand that is more aligned with those audiences and can be perceived as trustworthy and super top tiered.

Goal​

The goal for this brand refresh: Give Juicebox a refreshed look, while paying tribute to our creative and unique origins. Make Juicebox feel easier, more familiar and more enjoyable to use. Creating a strong brand presence and building trust among new audiences and verticals.

The No.1 thing that we want to be is trustworthy because people are exchanging a lot of money here in Juicebox, but we also want to bring the fun, cheeky human element into it, especially with this brand refresh to keep it clean while still having that bold and cheeky Juicebox vibe that we all know and love.

Vision​

Strath put toger a mood board, collaborating with WAGMI Studios on creating illustrations and really bringing out the Juicebox vibe.

Logo​

For the logo, we are giving Juice a fresh, clean and unique feel while keeping true to our roots.

Thanks to Sage, the current logo has been serving us really really well. And the refreshed logo is quite similar to the old one, basically just taking what we had and making it able to be scaled, able to be used on different color backgrounds, pair a little bit better with different fonts, etc. We're just tidying it up a little so that we can use it across a broader range of use cases.

As we don't have an official logo lockup yet, what we've come up with is like this:

A comparison to other industry standard branding. It sits really well next to some of these tech companies, but still holds its own unique and interesting feel.

Color Palette​

This is obviously very important for us. Strath wanted to go with something that really fits Juicebox, inspired by tropical and good times. The new Juicebox color palette conveys our playful nature while building trust and setting us aside from the crowd.

Typography​

There has been a lot of contention around this topic. Obviously it will be a very big choice to shift from DM Mono, which we have been using all along and has served us very well. But it's absolutely time to move to a new typeface.

Agrandir is a contemporary sans serif that celebrates the beauty of being imperfect. It was designed to be a brave antipode to the nuetral modernist font. Agrandir accepts its own shapes as they are, unaligned, quirky and funky. It celebrates humanity, not machines.

Iconography​

Another thing that will obviously get refreshed as we go into the brand refresh. Our icons need to be fun, playful and modern, bringing the interface to life for informing the users. It's a fairly easy switch, but definitely makes a difference.

In a lot of the user interviews that Strath has done, people said they'd love to see more visual representations, because there're quite many reading and complex terms. He thought that we can use the illustrations to pair with the iconography to really bring some of that to life and make it easier to use.

Illustration​

With the help of Sage, we will be using the same sort of stuff we've had before, but bringing a little more or a playful, fun, funky vibe to it. Also having some fruits and interesting Web3 Juicebox related objects around throughout the experience will work very well.

This is where we create the super unique identity that nobody can copy.

User Interface​

This is probably a question that everyone is having. What will it be looking like when we are refreshing the interface?

What we really need to move into is, making the experience a lot more fun and playful, but still really drawing the user into some of those main call-to-actions.

Timeline​

There'll be a phased rollout. We will have a very structured plan of how we are going to phase the branding in, updating the type face, rolling out the new colors and then starting by slowly redesigning some of those UI elements. It will seamlessly migrates over to the refreshed brand.

Discussion After The Presentation​

Jango: Super sweet. Lots of work goes into this, big shoutouts for pulling it together end to end over all these time.

Strath: Really appreciate it. Though it only looks like just some new colors and stuff, a lot of research and work goes into coming up with the ideas and refining it all. It's not just some random choices as well, but very specific choices to move us into this direction.

Also big shoutouts to Tjl for some of insight into where we're heading and how we want to position ourselves, which was really helpful. And also to Sage and WAGMI team for bringing the vibes.

Jango: The thing that's going to really tie together for me will be those customized illustrations by WAGMI that define the edge and ride that line, which is how they serve in the current site. And there's definitely a version of those that fit really nicely with this aesthetic. It still pulls towards that edge and that line which set the tone for use.

I think the last piece of feedback I have for the broader group is that the current juicebox.money in some sense rides this line somewhat awkwardly, between the more dev-oriented aesthetic with mono font and maybe data forward, and the fun aesthetic that this version pulls more heavily towards.

It's kind of an awkward pilgrim to seeing that you will go and bring JBM in this direction. I think it's necessary to really explore in earnest what this means and there will be a massive audience that feels home and comfortable here. But it will leave that opportunity for the other client or other kind of aesthetic to maybe find some foothold within more of a developer community or something like that. That's totally ok.

I think both of the things can, and maybe even should, exist at the same time, but it's just awkward to try to do them both at the same time in the same interface. So we are going to double down here and give this our go.

But I also want to acknowledge that the alternative side, which is more computer, more mono and more straight to the point, is still valid and may have some visibility at some point. And it's going to be really really cool. I think both can borrow a lot from each other while also catering towards specifi audiences, specific tool sets, etc. But from a perspective of project owner and payer, I think this is such an exciting direction to try.

Strath: For sure. There could be the more developer-esque side of things, but I think as we move more into growth, having something that both sets of users can use and enjoy in going to be really crucial for that.

Peri: Thanks, Strath. There has been a ton of work into this and it's looking great. Thanks for such a thorough presentation and a breakdown of everything. Echoing Jango's sentiment here, I think it definitely makes sense right now to be optimizing for what we try to improve. I think everyting that you've done is going to make the site look a lot more approachable to people who come to the current site and feel that it's a little overwhelming or not meant for them for one reason or another. This is going to serve those people really well.

If there's a future version of the UI that is much more dev-oriented, I could totally see a home for that. But I like where our priorities are right now, and I think we are making good progress towards it.

Ticket to Space Juicecast Episode by Matthew and Brileigh​

Matthew and Brileigh just released a new episode of Juicecast about the Ticke to Space documentary of MoonDAO.

MoonDAO last year held a contest of randomly drawing a winner of its Ticket to Space free mint NFTs, the winner will be sent to space on a Blue Origin flight. A MoonDAO member from Beijing won this contest and is going to be sent into space. There will be a documentary made about the journey of this winner, and the film is going to be made via StudioDAO.

Matthew and Brileigh recently had a conversation with Kenny and Rachel from StudioDAO, and the two filmmakers, Susie and Fernando, as well as Pablo, one of the founders of MoonDAO. They had a roundtable discussion about this Ticket to Space documentary, which will be the first one ever being made about a DAO.

Also StudioDAO is going to launch a Juicebox project to support this effort, and people will be able to buy a Ticket to Space NFT to sponsor the production of this film.

Krause House Project Introduction by Nicholas​

The Krause House 50pt Game Charity Bounty is a Juicebox project created by Acidicsantana. This project is crowdfunding and offering its treasury to a NBA player who scores more than 50 point in one single game. The eligible player can unlock the funds in this Juicebox treasury and have them sent to a charity of his choice, by interacting with this fandom project as outlined in the project description.

Nicholas is very interested in the overall mechanics and he thinks there are couple of takeaways that are worth thinking about for future projects.

First of all, it's a bounty. People are fundraising for a bounty, with an explicit goal stated upfront and its mechanics made clear in the project description. Nicholas thinks that it will be more interesting for people building projects or helping people build projects to take a little more inspiration from what works for traditional fundraisings in Kickstarter.

But even more than that, when the project reaches certain goals of fundraising, it will unlock other things such as raffling off an NFT randomly to a lucky contributor. This is getting closer to what really works for Kickstarter, which is the benefits for donors.

And Nicholas thinks that cumulative sum of the treasury unlocking other features or actions can also be motivating to get people to donate and participate. In the case of this project, a fandom is collecting their funds until they have enough money to attract the attention of somebody more influential and has more reach on social media.

There are some elements of this project that are worth repeating in future projects. And he encouraged folks to take a closer look at this project.

Roadmap Process Update by Tjl​

Tjl presented a roadmap for Peel and juicebox.money last week on our town hall.

He thinks Peel is making quite an effort to move towards our goal in a project-based working style, while giving clarity of where they are along the way, just like they did in the brand refresh presentation today.

The roadmap they build now lives in Linear, anyone who wants to keep track of the project management can apply for an invitation. This will help a few folks, like WAGMI team, Brileigh and Matthew to work in coordination to make some marketing materials so that we can have a deeper connection and relationship with end users and our community members by giving them updates about the progress of this roadmap.

Roadmap Presentation by Tjl​

Tjl was doing a roadmap presentation on the town hall, which is realistically a guiding force for those in Peel so that they can make progress and track against it and work towards a unified vision and goal.

Product Framework​

The full version of this document can be found here.

As a very high level context, this product framework by tjl has been pulled together through a series of workshops, some front end analytics, on-chain and off-chain analytics, as well as the user testing and interviews by Strath. Thanks for all the efforts by everybody involved, which has been the premise of building all of this.

According to this roadmap, which is supposed to be with a trickle-down effect, we will start from the top of the vision to enable creators of tomorrow to launch, fund and manage the boldest projects on the internet.

We are on a mission, there are some of the numbers we're looking to work towards. Even if we only achieve 10% of those, that will an absolute win for us.

Some of the product goals:

• Create the easiest way to get your thing funded online;
• Encourage everyday dreamers to launch their thing and make it successful;
• Create the world's largest network of contributors;
• Connect contributors to projects;
• Make it simple and straightforward to contribute to projects;
• Introduce the benefits of transparent funding to the corporate world;
• Create much trustworthy and reliable Web3 platform.

Some values we're working towards are trust, transparency, reliability, fun and exciting, community driven and customization and control.

Product Roadmap​

• Phase 1: The makeover.

  Refreshing the brand to commuicate to a wider audience.

• Phase 2: Engaging users.

  There are a couple of different features here, such as introducing profiles and linked email communication.

  Shoult out to Filipv, Mathew and Brileigh for their previous effort in the area of product marketing.

• Phase 3: Expanding verticals.

  Breaking into and expanding our reach so that we can capture new parts of the market.

• Phase 4: Optimizing the reach

  Overhauling the project display and discoverability features to increase contribution participation and expose us to new opportunities.

• Phase 5: Increasing engagement

  We worked really well at the early part of the user journey, which is launching and getting the project funded. But, there's so much to do after that, where Nance and a few others have been doing some great work, to expand the juicebox.money engagement through and post the early stages of the user journey.

• Phase 6: Supporting and serving

  Trying to introduce new support services.

• Phase 7: Expansion of large-scale experiments

The items in this graph are pretty much categorized into the above phases, with some milestones in between. We have given these objective quite conservative estimations, so very likely these will be happening a lot sooner.

1. Firstly there will be the brand refresh, launching a beta program, making some updates to the website, and including case studies on the website.
2. We're going to jump into project page, make a small refresh on the project page, get into the user profile setup.
3. Then we will be moving back in the create flow and expanding the capabilities,
4. Next will be some features around project discoverability:
   • giving project updates, making it possible to discuss on project pages;
   • ability to message project owners;
   • activity reactions;
   • project discoveratbility platform;
   • ability to watch projects and subscribe to them;
   • revamping the setting.
5. At the 6 Month Milestone, we will be looking to increase the engagement features, such as proposal creation and voting, project verification, etc.
6. The phase after that will be all about the reliability, introducing platform status features, developer elements, diversified payments, and so on.

When asked by Filipv when will we sunset V1 protocol, Aeolian explained that the only real delay in the V1 sunsetting right now is the availability of the token migration to let V1 projects migrate their tokens to V3, which will be coming in the next couple of days. Once that's done, we can probably broadcast the end of V1. He also thought that we would always maintain read support for V1 projects so that folks will be able to visit the original Juicebox project and ConstitutionDAO project. We're just going to probably remove all the edit functionality from it, but if V1 projects do need to edit their projects later on, we can look at making some V1 sites available later on.

JB Branding brief​

The day before this town hall, some contributors from WAGMI Studios and Peel had a very good call to discuss about the branding efforts, which is the first project on the roadmap, in order to refresh the identity to expose us to new opportunities.

They came to agreement and essentially approved the branding brief. In two weeks' time, we'll have a very solid foundation for a new brand to be shipped.

Features Update by Aeolian​

1. Cover image. Projects can now add a cover image on the top of their project page.

A tutorial of adding cover image made by Matthew and Brileigh:

2. Project page tabs. The infomation of projects such as funding cycles, payouts etc. will be neatly displayed in different tabs, instead of cluttering together in one place.

3. ENS avatars. We will show ENS avatars next to the addresses in the activity feed of the project.

4. Personal profile page. Every user will have a profile page of their own, showing the Juicebox projects that they contributed or created, and the activity feed of this particular address is yet to come later.

5. MP4 NFTs. Now Juicebox will support using video files to deploy NFTs.

   The tutorial of deploying video NFTs made by Matthew and Brileigh:

New Create Flow Changes by Wraeth​

In our current create flow, funding target and payouts are two separate steps where they have to be set individually. But as the funding target of a Juicebox project is actually the distribution limit of its certain funding cycle, which is also euqal to all the payouts added together, so we are now going to consolidate the two steps into one Payout tab.

In the new Payout tab, instead of setting a separate funding target, all you need to do is choose among the options of Limited, Unlimited or None.

Limited means the project will have a specific distribution limit, which is the total of all payouts added together.

Unlimited mean the project will have a infinite distribution limit, while all payout recipients will share by percentage splits.

None just literally means the project will have a distribution limit of zero, there will be no funds distributed out of the project.

Introduction Of Bruno From AgentHQ with STVG​

Bruno is the founder of AgentHQ, which is his attempt to make building AI enabled tools easy and fun so that people who are non-technical can build tools that leverage different language models.

AgentHQ lets users build an AI agent in their browsers, and it also has a lot of built-in tools that the users can lean on, such as text summarization, text generation, interfacing with APIs, pulling and pushing data from APIs, even connecting to users' emails.

STVG created the AgentHQ Juicebox project and handed it over to Bruno, in a hope that Juicebox will be leveraged to support his effort in AgentHQ.

Nouns Comic Book Ad Page by Nicholas​

ComicsDAO is going to publish a printed comic book for Nouns DAO, and they are offering an Ad page for Juicebox for thanks for the support and help from JuiceboxDAO when ComicsDAO was launched.

With the efforts of Sage and Nicholas, we've come up with a page which Nicholas shared on the town hall to see if folks have any feedback on it.

The QR code on the image will link to a Juicebox project, where limited edition NFTs with this same artwork will be available for minting.

NIcholas thought that this would be an opportunity to speak to the Nouns audience, as well as to cross pollinate, as Nouns is playing in an overlapping space with Juicebox, both communities are actually compatible to explore more development possibilities.

Art by Sage Kellyn

Specifications 3.1 by Jango​

We are now on the creative side of reacting to the lessons learned of the protocol, such as in the token migration bug that we experienced the past few weeks. Jango outlined what changes we've made in the controller and terminals, for reference purpose of the projects who are using the current terminals and controllers. Even though it will be a little more technical, but it should be useful to go through and explain it in terms of user experience.

You may also check the full version of this report by Jango here

Here are the changes made to the three malleable surface components of Juicebox projects:

Controller​

You can check full code difference here.

Every project uses the same contract but accesses it via their project ID, and then every project gets to choose one of these canonical controller contracts to use. The controller contracts are stored in this contract called the JBDirectory, which you can ask what current controller a project is using and it will return the current address of the controller.

This controller has permissions to mint tokens on behalf of a project, burn tokens and keep track of a few other things. It also has exclusive access to do a few things in the fundingCycleStore and the tokenStore on behalf of every project.

The changes that we've made to the new controller, which project can choose to migrate later, are two reserved token oriented function interfaces, the reservedTokenBalanceOf and totalOutstandingTokensOf. This new version of controller won't be backwards compatible with old versions payment terminals, so projects that are going to implement migration will have to move both controller and terminal to their new verions. The same for new project creation.

Essentially it's just a very simple and small change, which just changed where the distribution limit of a project is accessed. Before, you access it directly in the controller withcontroller.distributionLimitOf, and the project would return what the distribution is set and properties such as which terminal it applies to, etc. Same with overflow allowance by overflowAllowanceOf. But now, these are accessed in a separate store called fundAccessConstraintStore which fixes the problem that we experienced with payouts when we did the first patch migration.

And then there are some changes to how reserved token balances are accessed. The amount of reserved tokens outstanding is no longer a function of the current reserved rate, as now reserved tokens get tracked automatically when payments come in. You can just get from the new controller the reserved token balance of a particular project ID, and it will give you the full amount. The same with totalOutstandingTokensOf.

These are all very small and very inconsequential changes made to the controller, if you are not depending on this original interface explicitly. But if you are, you will need to figure out how to connect with these updated APIs.

Payment terminal​

You can check full code difference here.

You can think about the payment terminal as where funds are stored. It accepts new payments on behalf the project, allows token holders to redeem tokens to get their share of fund, and allows anyone to trigger the distribute transaction of funds.

Specifics​

Payment terminal is changing very slightly but meaningfully. As we had to publish a new terminal to be compatible with the new controller, in so doing we are also fixing the problem that we noticed a few funding cycle ago, when we tried to pay a grant to Defifa project which had its payment terminal paused, the entire transaction of distribution got reverted.

What we did was to wrap a functionality to catch that error coming back from trying to pay a project or an allocator and dump the funds back into the paying project's terminal, so that other payouts in that transaction still go out and any reverted ones will be negated. Then we emit events so that subgraphs can check if there is any reversion happening.

Another change in the payment terminal is of the addToBalanceOf call, which used to automatically bypass minting tokens when funds are injected into project's treasury by calling this function. We have been refunding any held fees by this call. If projects chose to hold fees when they were sending funds out of the ecosystem, they could deposit any amount distributed funds back in to release a proportionate fees back to the project.

Now the addToBalanceOf call will not do so automatically any more. There is a separate addToBalanceOf overloaded call that has a Boolean parameter requirement. If projects intend to refund any held fees, they have to pass that parameter as True in the transaction.

New event signatures​

• The distributePayoutsOf function used to emit a memo, which is kind of pointless since it is a public transaction. So we replace _memo with a _metadata parameter which allows callers to send their project ID in that first chunk of metadata, that way we can use events to attribute which projects are responsible for these value adding actions in the ecosystem.

​ distributePayoutsOf is important because it's the one where fees actually get accumulated and registered.

• useAllowanceOf, we don't even expose this in the client yet, but we probably should consider doing some version, or at least alerting in the project page when there is an allowance in the contract, even though the UI doesn't facilitate it.

  Its API is also changing to include the _metadata parameter alongside _memo. As this will only be called by the project owner, so it's usefull to keep the _memo there.

Tiered 721 delegate​

The tiered 721 delegate is an extension that projects can use for their NFTs.

There are some new properties in the create flow concerning NFT functionality:

• Project owners now can specify a royalty rate and a royalty beneficiary. These get exposed in a standard way that some marketplaces listen to.
• There are categories as well so project owners can add tiers that are organized by categories. They can get NFTs by particular category and start to create a new organizational traits around these tiers.
• Project owners can also set the metadata of tiers after they have been made, without having to deploy a tokenURI resolver. They can just upload the encoded IPFS hash and then the metadata of NFTs will get uploaded and changed.

Obviously the NFT stuff also needs to correspond to the new controller and terminal, so new projects will use all these new contracts instead of the old ones.

Also, as the NFT deployment is now using a proxy deployer pattern, the cost of deploying an NFT contract will be much more cheaper than it used to be, which is a very big win.

Hopefully we're inching towards a more resilient place where there will be few risks that projects owners need to know about, and adding a few different opportunities for features along the way.

Ticket To Space Update by Kenbot@StudioDAO​

Ticket To Space is a documentary that StudioDAO will be partnering with MoonDAO to create to document a Ticket To Space winner's journey and story.

StudioDAO is about to launch a funding process for Ticket To Space, which Kenbot thinks a big win for MoonDAO, for Juicebox and for StudioDAO. He also thinks with a lot of creative energy that can be deployed through this effort from people such as Matthew and Brilleigh, Jango, Mieos and Aeolian etc., we will be in a good moment where some of the big corporate companies are working that well.

He is very interested in terms of how they can do some NFT drops, more in a form of open editions and potentially with some burn capabilities. He is going to make use of the functionalities of Juicebox V3 protocol and offer different tiers of NFTs to supporters.

On one hand, they will have some high end NFTs which will cost 50ETH or 10ETH each. For example, he is going to put up a proposal in Nouns DAO to get them buy the NFT of 50 ETH in exchange for a credit in the creation of this film. But on the other hand, there will also be the open edition ones that will be more bottoms-up driving force to engage hundred of thousands of people around the project.

Drip Box Update by Mieos​

Drip Box is a project that Mieos launched to try to sell some NFTs and comes with them some mystery boxes of merchandise.

People can mint the NFTs and go to another website and have their holdings verified so that they can leave their physical addresses to have the mystery boxes sent to them later. After the selling phase, with all the cost and proceeds deducted, the project treasury will be open to NFT holders to redeem their share, in a sense giving buyers some discount or refund. The logic is, more people buy the NFTs, the more the purchasing cost of merchandise and operational overhead will be spread out and lowered, and in turnthe leftover funds to be redeemed gets bigger.

Mieos thought he would need to figure out how to work on marketing and build some traction for this project, in order to scale it properly so that it would be possible to get bulk discounts on the merchandise.

And he has spent much time researching some best-in-class items for the mystery box, and this first NFT drop will becalled the bug-out bag, which is a collection of goods that people would want to have at any given time and comes as a pack people can grab and run out the door feeling well set up to encounter things in the world.

Also Mieos and Jango discussed about the possibility of offering some producer NFT to give some potential sponsors a choice to put their brands on the products.

Art by Sage Kellyn

Versioning / Postmortem Update by Jango​

Three week after the original JBX V3 contract was put up, we've put out the V3.0.1 JBController and migrated to it, which caused another bug in how payouts are distributed as we had scheduled that distribution from the previous V3 JBController.

So the impact is folks on the payouts won't get their distribution in this funding cycle, as we need to go through one transaction to swap the controller back to the old one, distribute the payouts and swap back to the new one again. This process is outlined in this proposal, which is currently up for voting. If this proposal is approved, we can mitigate this bug and fulfill the distribution of payouts within the next governance cycle.

And our next steps are to fix a few other things that we've noticed over the past several months. One of them is when you are trying to make a payment from one project to another project which is paused, the whole transaction will revert.

We're looking forward to this kind of more permanent migration verion, which is also in the abovementioned proposal, it should take effect in the next few weeks if the proposal is approved. If it all goes well, at that point we'll have actually done migrations in the system to the extent possible. Although it has added complexity and bugs in the meantime, but given the current state of things and the product in the pressure, it's actually nice having this dogfooding process go through.

Shoutouts to contract crew for helping out in the past week really focusing on making sure this migration stuff goes well, to the frontend team for dealing with the controller routing and soon-to-be terminal routing so that projects can make use of the best and most reliable versions going forward.

Next few weeks hopfully we'll see new versions. There's very little risks in the system for what were exposed, which are very well known and articulated, but the versioning is really just to reduce the risks for future projects that maybe will be running without us or without knowing they ever existed, and may not look through the documentation as closely as we would recommend.

Peel Update by Aeolian​

It has been a while since last time Peel gave an update on Nov. 15, 2022.

Aeolian started by acknowledging some of the growing pains we've had recently, when we had a few reasonably critical bugs pop up over the last few weeks. Although these bug got squashed quickly, we've recognized the need to definitely improve on this font.

A lot of versioning stuff is being worked, as certain parts of the App were revealed to be in need of improvement, which is a good segue into versioning. As a lot of stuff goes into versioning, there are also a lot of different parts of the UI that need to evolve to support multiple versions of these particular contracts.

Great progress is being made, with a UI coming up soon for other projects to upgrade to new versions of controller and ETH payment terminal, after which point other projects should be able to start their token migration process as well.

Also there are some exciting new fuctionalities available with the efforts of Peel:

• Video NFTs. This will be shipped at the end of this week. Projects will be able to deploy NFTs with MP4s;
• Multi-selection of NFTs. People can now select multiple NFTs before they want to mint, this feather was pioneered by folks in the Defifa project;
• Diff view in project's Safe page on Juicebox.money. Multisig members can go there, review transactions and compare the difference before signing them;

Search feature is also coming along, and Peri has been working on that. This is really another big pivotal change in the APP that has a lot of moving parts, so Peel team wants to take the steps slowing so that they can iron out the details before putting out in the wild.

Also Aeolian reminded us to keep looking out for the changes made to the create flow, because projection creation is always evolving and iterating with new feedbacks.

SVG Template by Nicholas​

Recently Nicholas has been cleaning up some stuff for the token resolver, and Jango needed an on-chain SVG solution for spinning up SVG metadata for Defifa, so Nicholas created a repository of SVG template which might be helpful to other people as well.

On the town hall, Nicholas did a demo of using this template to generate an SVG. Other users can make changes in the SVG.sol to write their own SVGs. People can use this template to make their own on-chain SVG metadata for NFT rewards, project, or whatever they are interested in, and it comes with the Juicebox contracts built-in.

And then in the project-handle branch of this repository, people can call a slightly more complicated test to load Juicebox project handles in the SVGs.

Jango had been playing with this template this week. He wanted to make it an auto generating terminal for Defifa NFTs, so that anyone can use and create their own tournament. We can start showing data on the NFTs and customizing it with Peri's on-chain fonts. He thought that it is a very cool and useful tool, especially on a data heavy protocol as Juicebox, quickly visualizing data on the NFTs will be a great default for many projects.

Nicholas added that it will be also really cool for NFT projects to be able to have their token metadata directly served from blockchains, so that if Juicebox.money or whatever stops pinning their IPFS, the NFTs won't disappear. It will also be super cool for projects that want to be more autonomous or founders that want to keep their anonymity.

Reflection as a DAO contributor by Jango​

Last week Filipv reported and shared some things in our announcements channel, about a former JuiceboxDAO contributor, tankbottoms. Last week some people on the MovementDAO multisig contacted Filipv to say that they had discovered that Tankbottoms was convicted of fraud in 2010 with a number of PDFs proving it. And he also exfiltrated millions of dollars from the MovementDAO multisig.

JuiceboxDAO has no connection with MovementDAO aside from some contributors work at both entities and MovementDAO forked some of open source code of Juicebox.

Taking a step back from this particular instance and reflecting on how as a DAO member sees with this proposal and contributor cadence that we're currently accustoming ourselves to, Jango wanted to reflect on what had happened and how it had happened, then to reflect on what we can be doing to learn from things in order to avoid things bad happen to us and to recognize things that going well and looking good.

Jango wrote a blog post on his personal ENS address, and shared his thoughts one by one on this town hall.

• Jango thought that he tends to over-index on being trusting and enabling to people, and open to whatever happens with a diversity of outcomes, not really with the strong opinion what these kinds of accompany and what happens along the way. This can be abused. He felt very disappointed at what had happened, reflecting on how he relates to that kind of enabling energy.

• He thought enabling certain ideas or energies in some degree feels like enabling of things, which tends to be not good, but instead doing so can be hurtful and disabling to others who may have a different approach or different engagement with that energy. There's something to reflect on as a kind of loose social orientation observation, but valuable nonetheless.

• He thought that people can behave very differently with one another 1:1 in a DM format. It's interesting to see how different perceptions can be made depending on which conversations you're having and how they're being approached.

• Good communication is very important obviously. It's very important as a DAO. We can address and observe periods of miscommunication and reflect on their shadiness and how we might improve those, so that we're at least more consistently understanding the current context that we find ourselves in, so we can think about an approach to move forward.

• The 7-cycle recurring payout term that we have developed precedents for does seem to limit risk, which is something to look back on and be happy about. In his perspective, that system somewhat evolved from the void of systems altogether in the beginning. Recurring payout proposals can cause moments of reflection that can lead to inflammation and more difficult conversation, which then puts pressure on contributor's expectations -- both social and technical -- and shifts leverage a bit more into JBX community's value set. This value set is always changing and hard to get right because there's no right or wrong and this is the product of the people that are around.

• Contributor and JBX holder skepticism is really necessary to the DAO's health, but being the contributor that instigates the inflammation can be risky and hard to do. Jango thought that we should try to figure out how to allow skepticism to occur, to support it and to actually figure out forums or venues to make some certain things actionable. This can be taken in various degrees.

• The DAO's values outlined in the Foundation that we confirmed a few governance cycles ago, does leave room for interpretation. A lot of it talks about finding balance between urgency and patience, what kind of things that make our process tick or of particular value. It's a good thing that we do have the room for interpretation. It's not clockwork rules that you either adhere to or break, but a great set of values to reflect on and really figure out what does pulling towards balance mean when stuff like last week happens.

• A strong DAO immune system that minimizes bad risk and maximizes good risk over time takes attention and taste. Taste is a hard thing to get right, because we're an evolving community that has a Venn diagram of overlapping interests, tastes and tolerance. A lot of it does come down to the gut feeling or taste, and a lot of it technical, we have to be open and accepting of folks who are different from ourselves and may be providing new points of view. It's the balance, but it takes attention and taste, and we have to trust each other with the stuff we delegates to each other.

  There exist specialized viruses which is just part of building the system that we're building in. It's an adversarial environment. There're also designed viruses to attach these systems and figure out how to ride that way. To some extent the risk mitigation that the DAO has already pronounced is pretty cool, but there's obviously work to do.

• Developing an efficient and consistently sensible mechanism for moving JBX to productive workers and productive funders over time is a priority. It's a tricky thing. The buyback delegate will start, but that's something we talked about recently with the JBX strategy. There are more objective token things that we've already talked about and we're already aware of on the horizon from a technology and governance perspective. We'll hopefull have to take a consideration of the broader social environment that we exist in.

It's unfortunate to give a lot of chances or open space for something to exist, many times things blossom from that, but sometimes things just occupy that space and cause pressure to the actual fun beautiful things that are being worked on in blossom along side. The whole journey is just part of this dance and it's cool to be part of it, but it also takes these heavy amounts of reflection and actually feeling the consequences that can sometimes play against the general train of optimism towards actually creating cooler world of more open finance.

Discussions in the town hall​

Aeolian: Thank you Jango, those are really good. One of these points you made has been on my mind and definitely on people's mind for a while, which is that being the contributor that instigates inflammation can be risky.

I don't know what the solution is. Folks who have pushed back on proposals know that it's very hard to do so from a number of levels, which is emotionally taxing having to be involved in proposal and takes time to do. Obviously the risky part is that suddenly you publicly state your disagreement with someone's payout essentially, which can be risky for yourself. But folks who are willing to put in that effort, passion and care to push back where is appropriate on proposals because it's obviously really important and probably would have gone some ways to preventing this scenario that we found ourselves in.

Filipv: I certainly agree. I think that's a great point. Not just in proposals, but also in everything we do as a DAO. There's a tendency to want to agree on everything, which is human nature in some ways. If you're in a small group, you depend on these other people's approval to get things done. It can be hard to disagree with people, but we all need to continuously remind ourselves because there's that natural bias.

It's okay to express our opinions and hopefully we can come towards the right anwers even if no individual has the perfect answer all the time. Hopefully we can more towards it on the aggregate.

OpenGSN explainer and demo by 0xBA5ED​

OpenGSN is an open gas station network, it essentially allows you to make transactions without having to pay the gas for them. You don't actually perform the transaction yourself, you just sign a message, which gets sent to a decentralized network of relayers that in turn put it on the chain for you.

There are a few reasons why this would be useful.

• To improve the UX for projects. When projects want to onboard new users, those new users need to create a wallet and maybe go through KYC procedures, before they can fill the wallet with ETH through onramp. Then they have to perform the actual transaction when they get confronted with the need to pick a gas price and go through the rest of the entire flow.
• To incentivize users to perform certain actions, by projects paying the gas for them if they do this or that.
• It's also useful to automate tasks that need to happen, so that contributors don't need to do it manually.

0xBA5ED made a demo of minting an NFT on Juicebox without needing to pay gas or make transaction himself. Here is the link to his experiment on Goerli testnet.

For people who may find this a bit scary, 0xBA5ED also added and option of "Mint with burner wallet", which would just create a burner wallet in the browser and then perform the transaction with it. Nothing need to be signed in this case.

This is a good example of how the distribute function on Juicebox could work. Currently the distribution of payouts on Juicebox projects need to be triggered by someone clicking the distribute button, and this person will have to pay the gas of this transaction and may or may not get refunded from the project treasury later on. By this "Mint with burner wallet", in theory someone can just click distribute, the browser will make a burner wallet, sign the transaction and send it to a relayer to put it on-chain, at the expense of the project treasury.

0xBA5ED wrote a pay master which allows owner to set which addresses are allowed, which contracts are allowed to be called, which methods allowed to be called, and also to deploy system contract to verify the calldata.

By doing this demo, he wanted to give us some idea about what openGSN is and how it could be useful in lowering or reducing onboarding barriers for Juicebox.

Forming Plug by Darbytrash​

Lexicon Devils will be holding their next volume of Forming in collaboration with Emanate on Friday Dec. 17th.

There is another very exciting thing revealved in the Forming Juicebox project, an idea that Lexicon Devils have been toying with for a while. From this volume on, they are going to launch the new Forming Record Store NFT collectibles every month, which will be the personalized NFTs for each artist going to perform in the Forming event of that month. And as usual, all the artists on the event will be set as the beneficiaries of distribution, all the funds in Forming project treasury will be distributed to the artists after the event.

Banny Valentines by Matthew and Brileigh​

Matthew and Brileigh created a Banny Valentines project in collaboration with Sage, putting forth some Banny Valentine's Day NFTs.

If people want to buy one of these NFTs and have it sent to someone else, they can turn on the option of "Custom token beneficiary" in the pop-up payment window and put in the intended recipient's ENS or wallet address. After the payment is made, the NFT will end up in the hands of that recipient.

And we've just implemented a new functionality in the front end. If the custom token beneficiary is enabled at the time of payment, the caller and the token recipient of that transaction will be both shown in the project's activity feed.

Art by Sage Kellyn

Postmortem Update by Jango​

The governance proposal to migrate JBController V3.1 has been passed. Big shoutouts to Dr.Gorilla, 0xBA5ED and Viraz for helping test and publish this latest version of JBController, which is used to fix some reserved rate accounting inefficiency that exposed during the JBX V3 deployment.

Once we have the transaction queued by Dr.Gorilla and checked by Jango to especially conduct this migration on JuiceboxDAO, we will verify and sign it. By then, we will have the first principle things out of the way with a process agreed upon by the DAO. There is some ambiguity in the proposal because we had some last minute building, so we published the contracts and got their official addresses after the proposal was passed.

It also brought up a few other things so that we may want to look preventatively towards controllers, where a problem was exposed a few cycles ago when the payouts distribution transaction reverted because one of payouts recipient, the Defifa project, had its treasury paused. So we will be doing a quick audit of other components that we may look towards versioning. These components will just be controllers and payment terminals, there will be nothing that requires funding cycles reconfiguration or tokens like last time.

After this, we will be at a really good spot afterwards and having basically done all the versioning paths that available to us going forward in case of other risks that we may find, which hopefully will be very very far and few in between. And versioning should be kept very slim, because they are risks themselves when introducing some new components.

Big thanks to Dr.Gorilla, especially for helping to lead this process to get JBController V3.1 out there, as well as the migration components.

For project owners, they will soon have an opportunity on Juicebox.money to migrate controllers, which is just the contract that mints token on their behalf, listens to payment terminal intructions, etc.

And new projects will be created using the new controller. We'll have the actual UI components on Juicebox.money probably next week, as Aeolian is focusing on that work this week. Big shoutouts to Aeolian and the whole Peel team for working with project owners to really make sure the expectations are correct for them. Also we'll follow up with the instructions both in the form of documentation and some quick tutorials that our content contributors might help to create.

Thanks for everyone for moving very fast, it feels like we will be at a better place because of it. Despite the dogfooding having caused a little glitch and had us introspect a little bit and go through the process to learn from it, Jango thought that we might be better on the other side.

Banny Valentines by Matthew and Brileigh​

Matthew and Brileigh have just created a new project named Banny Valentines, which is an experiment in collaboration with Sage.

This project has deployed a few NFTs of Valentine's Day cards so that people can mint and send them to their friends or loved ones. So it is meant to be a fund little project to spread the meme of Banny leading up to the Valentine's Day. Matthew and Brileigh have the plan to send them out to people tweeting about this project over the next few days before the Valentine's Day.

This project is also a very good demonstration of how to use the function of custom token beneficiary, so just enter another address when you are checking out with the NFTs and then these NFTs will end up in someone else's wallet.

Except for this project, Matthew and Brileigh have recently finished a tutorial on how to reconfigure a project. And they will be making more tutorials and educational materials in the upcoming future.

Ticket to Space on Juicecast by Kenbot@StudioDAO​

Ticket to Space is a documentary that StudioDAO is going to produce for MoonDAO, which will also be a independent project in the network of StudioDAO. Kenbot said part of the launch strategy for Ticket to Space and the funding of it will be to run a series of interviews with filmmakers who are associated with this film, other filmmakers who are doing other space related content, MoonDAO contributors and also some real life scientists.

So they are thinking of partner up with Matthew and Brileigh to make a theme Juicecast series for a deep dive into the Ticket to Space Juicebox project. It seems to be a good place where they can combine forces, get helps from some other DAOs to get more distribution.

Matthew thought the idea with the Juicecast series would be like some thematic episodes leading up to the funding events. Ken said as they were not expecting it to explode out of the gate, they would want to do it and feed it gradually. So maybe they should plan to do the first Juicecast up, have some good experience, and then follow up with other conversations with other people who are associated with the film in one way or another.

Ken said they would be making announcements about this next week, by posting on Mirror for Ticket to Sapce on the Valentine's Day.

Forming Plug by Germs​

Lexicon Devils will be collaborating with Emanate to hold a new Forming event on Feb. 17th. The RSVP to this event is open now at the Forming webpage.

Merch Squad by STVG​

STVG was wondering if folks were interested to purchase the Drippy Long Sleeve on his Merch Squad project, an experiment for different ways to sell some merchandise related to our ecosystem.

Art by Sage Kellyn

V3 JBX Deployment Bug Postmortem by Jango​

Recently we have been going through the current strengths and current fragilities of JBX, meanwhile going through the last stretch of the V3 token migration, which we signed off on last Wednesday.

A few hours later, when Jango was checking the JuiceboxDAO V3 treasury page, he found that the numbers of reserved tokens were unjustifiably big. Jango immediately recognized that it was an inefficiency with how the V3 token was taking into account the balances from V1 and V2 token supplies. This was a design decision meant to make the redemption process smoother on V3, but it ended up exposing an accounting bug.

This issue was sort of delicate, if someone were to have sent the distribute reserved token transaction at that time, the big number of reserved tokens would have been distributed to everyone on the reserved rate list and we would have had a different recourse which would have been a little bit more annoying.

The governance cycle right before this happened, we had just approved an proposal for emergency strategy of JuiceboxDAO. Shoutout to Filipv for doing the research and Dr.Gorilla for helping that effort and everybody for approving it. We made use of it right away.

As the project owners can change where the reserved tokens are routed to during a funding cycle, we had the multisig set the reserved token splits to be the DAO's address, then distribute that big supple and instantly set a transaction to burn that extra supply. Thanks to the quick response of multisig team members, we managed to pull this off very quickly.

How you will be affected​

If you are a Juicebox project, you are unaffected. This only pertains to JuiceboxDAO treasury, JBX tokens and reserved token recipients in this case. If you're running on V3 protocol, you will probably be recommended to migrate the JBController to a V3.1 version.

If you are a DAO contributor, there is no reserved tokens on V3 right now, and that won't change for another few weeks until we're no longer printing reserved tokens unexpectedly.

If you are a JBX holder, the timeline to open redemption will be postponed a little bit longer. We currently have 0% redemption rate on V3, so let's take our first principles and then more forward with our previous plans.

If you are a multisig member, we'll probably still be receiving reserved rate issuance into the DAO's account and burning them accordingly. If someone wants to make a proposal to go in and make token distribution as if this never happened, that's certainly possible, just requiring more steps on the part of multsig and the DAO. We could do that if that's something someone wants to do.

Current situation​

As it currently stands, V1 and V2 tokens are minted when fees are paid or funds are put into the treasuries, together with some corresponding issuance of reserved tokens. So if someone pays in V1 treasury, V1 reserved tokens will be minted and the same on V3, reserved tokens will increase in both treasuries, which is obviously not what we want. Hence it will be the responsibility of the multisig to burn the extra supply on V3.

The next step is to actually fix this problem so that we can move forward, by putting up the JBController V3.1, which is just a small shift in how tokens are accounted for, but will be a lot sturdier and dependable.

If you choose to change your reserved rate within a different funding cycle but you haven't minted or distributed the tokens reserved according to the previous reserve rate, it will calculate with the new reserved rate based upon the current outstanding supply as if the old rate has not existed all along. This was the way the reserved tokens had been calculated, but we won't do that anymore, we will shift it over to JBController V3.1 to solve this problem so as to get reserved tokens up and running on V3 treasury.

Jango has put up a proposal to proceed with outlined recovery plan from this postmortem, which has been approved at the time of compiling this town hall summary.

And the reason why we choose the option of migrating the JBController to a new version of V3.1 is that it will allow us to keep V1 and V2 in place doing exactly what they're doing, and avoid the tradeoff of totally stopping V1 and V2 and no longer managing interoperable fee collecting treasuries, which was the big hypothesis of this migration strategy.

Lesson learned​

Once we have removed it problem from any immediate actions needed, we can assess what we have learned along the way, to prevent this from happening in the future or reduce is probability. We will need a stricter checklist to our GitHub repos, because theoretically V3 JBX migration tests should have been more broadly covered.

Also we have to do a better job of assessing ownership over different pieces of codes and projects, and keep aware that there are certain pieces of smaller, more passive codes that are greatly important and need focus and space, despite all the other exciting stuff happening in the surface.

There are also some thoughts, from the contract perspective, to evaluate tradeoffs between low probability unexpected behavior exposure and squeezing transaction costs down.

Jango thought that we would be in a much better place once these steps are taken, without this reserved rate risk looming over us.

We are thinking about reducing there risks and fragilities as much as possible in the name of building the stronger and more resilient JBX, as we talked about last week in the town hall.

Takeaway​

If we all commit a week and a half stitching this together and documenting it as well as teaching people how to make use of 3.1, we'll now have yet another instance of versioning under our belt. In some sense, we have this implicit understanding that the payment terminals controllers do have this lighter weight migration path which will require stitching together a few more components to facilitate those. But eventually as things emerge as risks or very very pointed opportunities and there might be moves to make, it will be easier to do it now when there isn't a whole lot of on-chains governance process and weight on the core infrastructure. We should try them now instead of doing it out of choice. Given the current need, it makes sense to get one of these under our belt, let's record it, let's lean into the postmortem all the way through till the end so that we learn from it. Then if we need to repeat this in the future, there will be very clear steps. At that moment, let's get back to where we were, which should be a great place of building more surface level experiments and imaging how this thing can be extended to do new things.

Dripbox Update by Mieos​

Mieos launched a Dripbox project recently, which will be in conjunction with some arts by Sage Kellyn.

Dripbox will offer some NFTs which are mystery boxes. If people buying those NFTs want to find out what is inside that NFT, they can hop over to another website of dripbox and link their wallet to check their holdings of this NFT, and provide an address to have the mystery box sent to them.

The proceeds used to provide these mystery boxes will be deducted from the treasury of this project, while all the leftover funds will be redeemable for the NFT holder in a "Slurp Overflow" phase. So there's basically a bulk discount rate for these mystery boxes that using the treasury redemption mechanism in Juicebox。

This is a little fun experiment, and Mieos that he was planning to start with something chill and simple and see if they can get this exciting project moving on into the year.

Projects Update with STVG​

AgentHQ project​

STVG created this AgentHQ project on Juicebox, to help fundrasing and support the development of Agent HQ, which is a way to build your own AI info center basically by putting in some links or PDFs.

STVG has tried to created a “Juicebox learning center” using this Agent HQ, by putting in some of the links and docs related to Juicebox, . He demoed how the interaction with AI agent worked on the town hall. He thought that we could maybe do a better job of explaining some of the technical terms for project creators and eventually evolve this into something that people can ask questions about Juicebox before they want to reach out for help in Discord.

Merch Squad​

STVG would be attending the Office Hours of Nicholas and Jango to talk about some NFT drops along with pairing up the merch.

Also STVG and Justin Harder are talking about launching a project on Juicebox for a show calld Molarky, where they have the plan to do some NFT drops as an open edition for a week or 14 days, while buyers can get a Juicebox shirt or a shirt with the graphic of NFTs on it.

Updates by Nicholas​

Office Hours Promo​

They would be hosting their Office Hours at 4:20 pm EST every Wednesday. STVG will be the guest on the new episode.

All the past three episodes have been edited by Matthew and Brileigh and you can listen to them on Juicecast.

Galaxy Brain Ads​

Nicholas is selling 5 second ad spots on its Web3 Galaxy Brain project on Juicebox, for his Twitter Space podcast Galaxy Brain. People who minted an NFT can let Nicholas to improvise in the show or read a specific text the minter leaves in the payment memo. This is an experiment of selling something practical through Juicebox NFTs.

Gabriel Haines Frontend Open Call​

Nicholas is working on the next version of the Gabriel Haines project, and they might be thinking of having a website to have some interaction with the NFTs of this Juicebox project and maybe also with 0xsplits or something of that kind. So he was thinking of inviting someone who might be interested in the frontend work to discuss together.

ComicsDAO Nouns Comic Book Ad Page for Juicebox by Gogo​

ComicsDAO is making a comic book for Nouns DAO, which will be the first mass market comic book printed from a Web3 venture. As JuiceboxDAO had been very helpful when ComicsDAO created their project on Juicebox, they are happy to reserve one page in this comics book for JuiceboxDAO to promote itself or share something meaningful.

Gogo encouraged people to go to the thread of ComicsDAO Artwork to join the discussions, and share their suggestions of what would be cool to have on the Nouns comic book ad page for Juicebox.

Forming Plug by Darbytrash​

The next Forming event will be on February 17th, 2023. Lexicon Devils will be doing a collaboration with Emanate featuring djlethalskillz.eth.

w