App Framework introduction by TJL​

In response to some of the relevant discussion lately in the Discord, Tjl had been working on the App ecosystem framework that he believed can be enabling an extensive ecosystem of Apps to extend the Juicebox fuctionalities and drive continued development.

On the town hall, Tjl gave a walkthrough of this document, identifying some of main problems in the Juicebox ecosystem, givinng some suggestions and corresponding solution, projecting the potential changes this framework is going to bring to our ecosystem, as well as some opportunities that will be opened up with this initiative.

Problems​

1. Brand strength: It's the lack of uniformity, consistency and strength to the brand, and not tying back to the original Juicebox, therefore suffering on the branding front.

2. DAO Alignment:Everybody in Juicebox speaks about Juicebox in a slightly different way, causing a fundamental problem of value alignment and over time creating inconsistencies with the way we talk about Juicebox and what it is.

3. Product complexity: Difficulty in effectively nailing a clear value proposition for JuiceboxDAO to try and move towards Product Market Fit (PMF).

4. Growth effforts: We failed to do a great job at focusing on growth initiatives and strategies.

Suggestions​

Solution​

The solution here is using JBM as the key vehicle in the market to

• firstly, define a core set of features that provide clarify to what Juicebox is, and are essentially 100% valuable to 100% of projects, while everything else that is in contention to every single other project made available as a plugin;

• then slowly peel back extensive features of the platform, but replacing with in-house built plugins which ultimately match the current fuctionalities.

We wouldn't be changing what Juicebox is, but just changing how we market it and how we talk about it. And then we'd be changing some of the UX and opening up more opportunities on the plugins front.

Changes​

Acording to TJl, there will be following changes:

• Simplified JBM create flow;
• JBX create flow with a modular design;
• Settings with a modular design;
• Project pages with similar modular design;
• A new page/section of JBM for exploring and project plug-ins.

How might this work​

Tjl also demonstrated some very early stage wireframes as the visual indiction of how this might work in regards to Juicebox.

He also showed the audience some rudimentary mockups to visually represent how this framework might work within the current setup, in areas such as App Store, Developer assets, List an app, Create flow, Project page and Project setting.

Opportunities​

What Tjl saw as the opportunities of take this initiative:

What do we need to make this work?​

If we were to go down this path, there are a few things to make it work:

• We need complete alignment and support from the DAO. We're all working towards a single goal, we talk about it in a single way and we have a kind of a single destiny.

• A slight shift in priorities for the Peel, even though we've kind of put all of the building blocks in place for this, it would be a slight shift in priorities for us in the way that we build some things.

• And cooperation from existing JB-funded projects.

• And Contract crew development support

• Documentation from Filip.

Discussions On App Framework​

Nicholas: I completely agree with a lot of the motivations, but I think that clarifying the core function of Juicebox makes a lot of sense, or at least what it is advertised as, even if it has a lot of extensibility beyond that.

And I want a bit more certainty that App Store not only is a convenient solution for updating the front end from something more complicated to something more streamlined, but also can move us towards increasing adoption.

Tjl: I totally agree that we're already doing this in a sense, but I don't think we're doing it with guardrails, and we're losing a lot of potential opportunities by doing so. Also it doesn't tie back to the brand and the growth of Juicebox.

Secondly, we definitely have a Product Market Fit (PMF) problem that we have yet to solve. And we haven't nailed our positioning, which is a product of the fact that we can't get consistent with talking about it.

NIcholas: To get that process started, it would be interesting to have a single front end which is compatible with separate work streams, updateing them at the same time. If Blunt is something that can be executed inside of an optional add-on tab instead of a project, then a handful of devs, internal or external, Peel or non-Peel, can start working on that. And it can be integrated into juicebox.money immediately, rather that having to either spin up an entirely new site, or to redirect Peel resources to it.

Tjl: Totally. That's definitely one of the biggest motivations. Let's tidy everything up, move everything towards a single source, and start to grow that as an ecosystem, rather than crumbling off in different directions.

Nicholas: It does remind me of interacting with an AMM like Uniswap or Matcha and importing untrusted tokens. I would be curious to know, more from the perspective of contract crew, if we could achieve something like a level of standardization around front ends, or extensions to the protocol where they can be added either as trusted or not trusted. For instance, right now if you want to rip the NFTs, you can take NFTs out of the create flow pretty easily.

I don't know if it's possible to achieve, but it would allow for a faster, simultaneous and concurrent development of extensions to the protocol, if it is easier to get them into an interface.

Filipv: I think the generic UI problem is probably the biggest question there. For people to build Juicebox extensions, we would have to find some generic solution for that and it's not very easy to generalize.

Kenbot: I don't think that Juicebox is a fundraising protocol. The complexity of it is beyond the scope of what most people who are looking for fundraising capability are looking for.

I think the strength of the protocol, the platform and even everything that's been created so far, is a fundraising solution. It's a smart treasury that remembers who contributes and can reward them later on, making it a powerful tool for managing money flow.

I think that Juicebox's strength lies in its general purpose treasury tooling, and then the more specific interaction interfaces are where we will win.

Jango: I think there are two ways to look at it. There's the revenue angle, which will lead us to a certain path of what do we really enjoy working on and what's our passion. And we are building something in alignment with what has previously brought the DAO's revenue, which in a sense you can see it as revenue, and in another you can see it as a community building exercise, because the bulk of the funds we use were from folks who tripped into the treasury and not even though a project.

Another interesting way to look at it too is: what are the projects that we really care about and what do we want to build? Folks like Kenbot, Livid and Kmac etc., are building their thoughts here. It might be telling to take what we've done, what we've seen and what we've learned from, and then figure out how we should apply it to the current cast of motivated people who are here and building.

Tjl: Most definitely important. I think that's step one over everything else. We need to get clear, and there needs to be a lot more clarity on the direction and why.

Jango: I think part of the motivation in trying to figure out the right way to express these Apps, what we used to call extensions or templates, is because ultimately we can't really control what comes the protocol's way. We don't have the luxury of a single alignment and a single brand. The paramount principle of our old strategy was to welcome diversity and recognize that folks are encouraged to build their own wacky things, while the DAO would step in and add some level of legitimization if things prove interesting.

So I am aligned with the conversation in large part, but I think it will be really tricky or impossible to actually get on a single same page. I think it's worth considering, despite it being counterintuitive, the opposite of how can we be as accomodating as possible to chaos.

Tjl: I think it's incredibly important to try to at least nail down where we are going, Even if you do think it's impossible, I think having many and frequent discussions about this will be important in moving us into a direction which makes sense. And that should be a priority over everything else, because it seems to be too many narratives over there.

Nicholas: I feel that we need clarity. It's okay to have some clarity what this thing is about. I don't think that's the enemy of chaos or productivity or creativity. In fact, I think it's enabling of creativity and chaos.

JB Project Metadata: Static Metadata by Nicholas​

Nicholas had developed a TokenUri Resolver contract in the past several month, which can visualize some details of a project on its ownership NFT. Some of the projects that deployed this contract can be found in the Juicebox projects page on OpenSea. And he also made another contrat called Project cards to let folks mint an NFT to keep a copy of any Juicebox project's metadata in their own wallet, which can be found here on OpenSea also.

In the past week, he made a small contract, which basically is a custom token resolver that lets project owners change their projects' static metadata to some JSON posted on some custom location like IPFS, HTTPS or even Arweave. So people don't need to upload or deploy their own contracts, they can just set the text using this contract and then set their projects to use that as a resolver.

Though he is going to make a dedicated website to help people mint those project cards more easily, if anyone wants to try it out earlier, they can follow these steps below:

1. Pin your desired metadata to ipfs (use this template ipfs://QmQs3MLLqyxVKWn7BccxEmweQ17JfT3ttnmZ7nga7c1D3S);
2. Call setUri on this contract, passing the project ID and URI from step 1 (eg ipfs://...)here;
3. Set the token uri registry as your custom token resolver by passing it's address and the project ID of your project here.

Filipv had made a PR for the earlier contracts shipped by Nicholas, as soon as it gets reviewed and merged, project owners can go to the projects' settings to set their custom metadata, instead of interacting with the contracts directly themselves.

Post Mortem of V1 Payouts by Filipv​

Filipv had put up a proposal recently to move all the ETH from JuiceboxDAO V1 treasury to V3 treasury.

After this proposal got approved, Filipv went to queue a transaction to increase the funding target of V1 treasury to 100m ETH, the total amount that can be paid out of the treasury, and set the payout beneficiary as the address of V3 treasury. This transaction was approved and signed by the multisig later.

But later Jango noticed that the payout beneficiary was set as the V1 treasury itself instead of V3 treasury, and the team soon found this was a bug which would set the allocator to the zero address when the funding target of a V1 project was changed, which meant that the V1 treasury will pay itself and mint some new JBX tokens.

Theoretically, this could be exploited to make the V1 treasury keep paying itself until the 100m funding target is reached and mint out an astronomical number of JBX to be allocated to the multisig and other reserved rate recepients.

Filipv quickly hid the "Send payouts" button in the front end of V1 project, and Jango queued a transaction to set the right V1 allocator, which was signed and executed by multisig members soon after.

To recount and analyze this bug, Filipv had posted a post mortem here, he also outlined some procedures to be taken in order to prevent similar problems in this article.

Community Feedback by Gogo​

Gogo came to our town hall two weeks ago and announced that he wanted to suggest the DAO to attend the NFT Brazil event but he didn't have a chance to fully explain his thoughts and instead suggested to submit a proposal. And he did put up the proposal for NFT Brazil and came to our town hall last week again to advise folks to brainstorm what cool things we can do on this event. This proposal was turned down by the DAO in the phase of community temprature check.

He thought that there isn't a space in our community to brainstorm and give ideas. As a OG Juiceboxmember ever since 2021, Gogo felt he had been very passionate about our community. And this was the first time he want to do something for Juicebox directly and specifically, together with the community. He had not felt very welcome and neither had a space to discuss with the rest of the community.

But instead, when the first time he created a proposal to Nouns DAO, he had fours calls with the whole team, got together with them to have some feedback from that community and think about what would be the best approach. He created a proposal and changed many details according to the ideas of the community, and finally the proposal was passed.

He suggested that we should have a space to communicate, a space to think about what we want as a DAO and make people feel they'are welcome here.

Jango expressed his gratitude to Gogo for bringing this up. He felt that we spent a lot of energy thinking more about next future customer and product market fit, which didn't really make much sense in the context of the tools that we're building. He suggested that we prioritize the needs of current builders and community members, instead of constantly seeking new customers or revenues. He believed in building strong relationships with the current members and providing them with the necessary support and resources to succeed.

Jango also emphasized the importance of focusing on individuals rather than revenue and product market fit. He believed in fostering a community of passionate builders who can work together to create innovative solutions.

Mieos thought that we need to find a nice balance between pushing the family vibe where we all feel welcom, loved, appreciated and motivated to take risks, and a place where we are trimed and efficient towards a product that the world wants and makes profit to make it more sustainable.

And he thougt that we recently got a little too serious in the proposals, maybe it was because we had been hot and loose for a while and the pendulum had swung back a bit. He suggested that we find a way to add more productive feedback and be more open to giving and receiving. He also was grateful for Gogo to catch the vibe and be willing to step in and say something about it.

Planet Croptop Template Demo by Jango and Livid​

Livid introduced that Planet is an App that lets users have a website running on their ETH domains. It's a fully decentralized solution, which means that the users' content and domains are totally controlled by their own private keys, and there is no server and no centralized thing with this project.

On the town hall, Livid demonstrated posting a screenshot onto a website of ENS domain, and then collecting one of the images on Jango's ENS website as an NFT.

Jango then took over and introduced the mechanism of this Croptop template for Planet App.

As you create websites using Planet App and post content, you are esentially hosting it on your computer. Anyone who follows your planet can then access and distribute the content in a peer-to-peer network.

The model from the peer-to-peer perspective is that the content kind of lives in this peer-to-peer network, and it can be removed or de-referenced. But once someone collects the content, then it lives forever, it's stored and permanent, and can't be removed or deleted by the person who made the content and posted it in the peer-to-peer network in the first place.

This might be a path to build the unstoppable sites that are hosted on the Ethereum network, and the content is peer-to-peer. And then the only step missing is to really make this a fundraising tool, to let these images be posted and mintable on a Juicebox treasury.

Recently, Jango developed a Croptop contract and made these content collectible/mintable as NFTs and be posted onto a Juicebox project.

Any project on Juicebox can give this contract permission to post a new NFT onto its project page. Up till now, our mental model of NFTs that only the project owners can go to their project and post a new NFT on their project page, but now they can give this Croptop contract permission to post a new NFT on their project page, and put these NFTs in a specific category if they want, so that the NFTs posted by the Croptop contract can live besides or separate from the project's main NFTs on the project page, how ever the project owners see fit.

And then the project owner can also set some thresholds like the minimum price and the minimum quantity of NFTs can be posted on their project page. So that when someone goes to a project and post their own NFTs with the Croptop contract, they can set the price for that NFT, as long as the price is higher than the threshold set by the project owner before.

In the example above, one of the images on Jango's ENS website was collected/minted and posted to the project page of Test Croptop (Goerli testnet), at the same time a 5% fee was paid into another Croptop Publishing Network (Goerli testnet) for using the Croptop contract. ( Right now, Croptop is still an experiment that lives in Goerli testnet.)

So then anyone can basically post art or things they want onto a project page, which can be a project page or something specific for this feed aggregation. In order to post on someone's feed with Croptop contract, you will both add the NFT and mint the first copy, so you're basically paying the project to post a new piece of content.

Maybe there will be a reverted model, where project owner is not posting NFTs, but its community is getting together and deciding which items should be posted on a certain project.

Nance Updates by Jigglyjams​

During the Town Hall, Jigglyjams introduced the new homepage for JBDAO.org.

One notable feature of the updated proposal process is that proposals now include links to the relevant discussion threads in Discord during the Community Temp Check stage.

Additionally, the new proposal template allows authors to easily drag and drop Markdown files or images, and add actions such as payouts, reserve rate distribution, and token transfers from multisig wallets by clicking the "Add an action" button.

Another exciting development is the effort to genericize JBDAO.org, allowing other Juicebox projects to use the same front-end for managing their community governance. Several communities, including Thirsty Thirsty and Bananapus, have expressed interest in this product.

Visibility Updates by Matthew and Brileigh​

They have recently given Juicenews a new landing page, where folks can subscribe to the updates in Juicebox ecosystem.

Peel team has launched a new website in collaboration with WAGMI Studios, featuring an updated homepage, an About page, Case Studies, as well as new functions like improved search and project tags. Matthew and Brileigh published a blog post of website updates to introduce some of the new pages and features, while also releasing a walkthrough video to accompany it, as part of the launch strategy of new products.

And they also are going to have an interview with CryoDAO for the new episode of Juicecast.

Defifa Updates by Jango​

The Defifa team is in the final stages of organizing a tournament for the NBA Playoffs. The plan is to host a Defifa game for each series and focus on smaller competitions within those.

Jango has suggested the idea of a Town Hall minting session in the near future, but for now the team is focused on wrapping up a few remaining tasks.

Thirsty Thirsty Updates by Bruxa​

Bruxa has written a document about the Season 1 treasury and membership NFTs for the Thirsty Thirsty community, which she plans to publish on the Thirsty Thirsty Community Journal and formally announce on May 13th.

New contributors will be able to mint their Season 1 membership NFTs and join the governance, building together with the rest of the community. Additionally, there will be an airdrop of $THIRSTY tokens to Season 0 membership holders.

Bruxa believes that this will provide a strong foundation for the community to explore further in the Web3 world and help new potential users understand the mechanisms of IRL communities in this space.

NFT Brazil Proposal by Gogo​

Gogo put up a proposal this week concerning the thoughts of suggesting JuiceboxDAO to attend the NFT Brazil event, which he mentioned in our last Town Hall.

He thought that this initiative can bring some value to Juicebox from this event. And he invited people to brainstorm together some cool things that we could do during this event.

Peel Updates by Strath​

Peel was set to unveil a brand new homepage for juicebox.money, along with an "About" page, on the day of the town hall. This launch was the culmination of extensive planning and preparation, including a thorough exploration of user needs through interviews, testing, and data analysis. Peel had also gathered feedback from the DAO to inform the development process.

One major user request was for more content showcasing project creators and their projects at the forefront of juicebox.money. This included a desire to bring trending projects above the fold, and was a high priority for the team.

Peel has implemented a clear and concise approach on their homepage to immediately inform users of what's going on in our ecosystem as soon as they land on the page.

During the town hall, Strath shared his screen to demonstrate different sections of the homepage, including "Built for ideas like yours," "Success stories," "How Juicebox works," "Why Juicebox," and "Juicy picks," among others.

The upcoming works from Peel include two major initiatives:

1. The launch materials created by Matthew and Brileigh, which will accompany these website updates. This marks the first time that we have implemented a comprehensive launch strategy across multiple platforms, including podcasts and social media.
2. The project page design phase, which Peel initiated with a kickoff meeting prior to the town hall. Peel will continue iterating on the project page design and hopes to launch it within the next couple of weeks.

Projects Updates by Jango​

Bananapus​

Filipv had been working on a more manual instantiation of what the full mechanism could look like, and some members of the contract crew - Viraz, Dr. Gorilla, and 0xBA5ED - are collaborating to create a stripped-down version of the 721 delegate, which are the NFT rewards currently displayed on project pages. However, this project is still in development and has yet to be finalized.

Blunt​

The Blunt project is ready to be deployed to mainnet. We are also exploring ways to make the juicebox.money experience more accessible to everyday users seeking an easy fundraise and low commitment tool.

Hopefully the Blunt experiment will play out on blunt.finance as a website, where we can play with it, study it and prove it safe. Once we are confident that this is something worth investing and prioritizing on juicebox.money, we can have discussions with the Peel team.

You may go to blunt.finance and give it a try on Goerli testnet now.

Defifa​

Defifa didn't make it to the initial NBA playoff run. However, Viraz completed the last tests yesterday morning and we reviewed some things over the weekend. Currently, DeFIFA feels good and we're planning to run a contest next week that's more relevant to one NBA playoff game or series.

Our goal is to be able to play a Defifa style tournament with everything updated, updated front end with the create flow and updated contracts, in time for the semi-finals of the playoff and definitely the finals.

Thirsty Thirsty​

Thirsty Thirsty group was about to launch their treasury on Juicebox. The proposal to run Thirsty Thirsty alongside their new season's NFT was approved by their governance process. They were trying to attend as many events as possible to host a workshop, so it would be beneficial to have a landing page on Juicebox to sell memberships and build a treasury.

Although the aim is to accelerate project creation and simplify the process so that people can easily spin up projects, Jango acknowledged that for some of the projects under discussion, they might not be ready to be deployed immediately. Instead, he suggested that the drafting of their configurations could be used to communicate to their community about the specifications and the way it could work. These projects are seeds of thoughts that a Juicebox project can help articulate, and their deployment may require more patience and considerations for a longer time.

Thirsty Thirsty is launching a project named Ten Bags, where they will sell 10 bags of premium quality flour from a Juicebox project. They will set up a treasury and sell 10 NFTs, and the proceeds will be split between the distributor group, Thirsty Thirsty, the restaurant group, and the farmer. This project can be a source of storytelling, showcasing where the money ends up going once they sell those bags.

This project represents an ambitious long-term vision of building relationships with Earth-friendly goods directly from treasuries, starting from just selling 10 bags of flour. It might inspire some thinking on how these kinds of projects can be part of a narrative as they build and consider who their users are and what they want to use Juicebox for.

Bruxa also expressed her eagerness to offer more dynamic content and support the storytelling, like some recipes for pasta, an interview with farmers or aerial video of the farm and dry storage, etc. And she hoped for opinions about Thirsty Thirsty from our community as well.

Art Collection with Nacho Fredes​

Jango has plans to create a project for his friend Nacho Fredes, a Spanish designer who has been making digital art since the 80s. The project is called Happy Gods and comprises of 128 hand-drawn images that celebrate happiness.

As part of the project, a portion of the proceeds will be allocated to the museum that Nacho Fredes works closely with in Spain, while another chunk will be donated to a non-profit organization. Jango aims to distribute and display these artworks on a Juicebox interface, though he may initially rely on juicebox.money.

Overall, this project aims to support both the arts and philanthropy, while showcasing the unique digital artwork of Nacho Fredes to a wider audience.

Pinnable CropTop Template with Livid​

Last December, Livid presented his decentralized website building and hosting app, Planet, at our town hall meeting. He subsequently created a Juicebox project, Planetable Pinning, which has its own discussion channel in the JuiceboxDAO Discord server.

Planet enables users to locally host their content, which is pinned to IPFS, and can be referenced via IPNS to an ENS name. This means that content creators can publish their work from their computer, and once the content is distributed through peer-to-peer networks, it can be accessed by anyone by visiting the related ENS address on a browser, such as Jango's personal address jango.eth.limo.

Recently, Jango and Livid have been collaborating on the CropTop template for Planet, which offers a visual blog format for publishing content. The template uses the same underlying technology as Planet, and allows users to optionally use Pinnable as a centralized storage service. By going to the Planetable Pinning project, users can mint an NFT, which gives them access to centralized storage for their content.

Jango has shared his vision of creating a version of CropTop where users can mint or record pinned images onto the blockchain, which cannot be removed by their owner, and use that same transaction to fundraise for other Juicebox projects. In this scenario, anyone on the internet can add content to a project and mint it in the same transaction, with project owners potentially offering to let people post whatever they want on the project for a fee that goes into the project treasury.

While still in the research phase, this idea holds exciting potential for creative interactions between peer-to-peer websites hosted on .eth addresses and smart contracts. For example, we could use juicebox.money/@juicebox as a hub for JuiceboxDAO's treasury information, while using juicebox.eth to showcase a more unique template that offers multiple entry points into Juicebox projects.

Ultimately, the possibilities are endless, and it will be interesting to see how the Juicebox community continues to innovate and leverage decentralized technology to build new and exciting projects.

Internet Archive​

After Livid's introduction, Jango made his way to the Internet Archive building in San Francisco. Internet Archive is a non-profit organization on a mission to archive the Internet, and they have been doing so for quite some time. Jango felt a personal connection to Internet Archive's mission, particularly with their goal of creating a more peer-to-peer internet-based infrastructure, which he believes aligns with the principles of unstoppable money and treasuries.

During the pandemic, Internet Archive was sued by large media conglomerates for lending out digital library books. As a result, they may require substantial financial support to navigate the lawsuit. Given the cultural alignment between the Ethereum, crypto, and Internet Archive communities, there is an opportunity to raise funds to help them fulfill their mission. However, the question remains: what is the best approach? Is fundraising the only option, or can we offer other types of assistance to make the idea of a permanent, indexable Internet Archive a reality?

At this stage, it's still early days, and we need to explore the right moment and toolbox to determine how we can best support Internet Archive. By understanding their situation and aligning our efforts, we can create a more legitimate and impactful outcome for everyone involved.

Thoughts on NFT Brazil by Gogo​

There will be an NFT Brazil event from June 2nd - 4th in Bienal, Brazil, which will be the largest Web3 event in Brazil this year, with Bienal be an iconic art venue in Brazil. The event is targeting an audience such as creators, gamers, artists, developers, investors and etc. to onboard people into Web3.

And also the reach is huge, there is expected to be around 40,000 people that will go to this event, so Gogo thought that it will be an incredible opportunity to showcase Juicebox and connect with the Web3 communities there. He had the plan to submit a proposal to suggest JuiceboxDAO to attend this event in a certain way.

StudioDAO Update with Kenbot​

They spent time learning and navigating Eventive, a film festival platform, and have successfully included two documentaries and a video podcast in their movie festival. They are also incorporating NFTs as membership passes, allowing fiat-paying users access to the films.

A particularly exciting aspect is that Eventive's API provides a clear record of all user actions, which they plan to leverage for retroactive rewards to those who participate in the festival, fund the films, and share them. By using the data to generate a record of these activities and implementing token rewards, they hope to scale the token economy and integrate it into the festival.

Bananapus Updates by Jango​

The proposal to fund Bananapus project has been approved by the DAO earlier this week. Bananapus is an experimental ground for some more delicate token related things so that it won't pose too much risks for JuiceboxDAO. We can keep proposing specifics to tackle, in realms of front end, contract, visibility and collaboration between everyone.

A dedicated Bananapus Discord server has been created, and folks are welcome to join and participate in this project.

Right now there is no roadmap or game plan for Bananapus, but there are several steps we want to take as depicted in the general gist that Jango posted in the discord thread.

These can been considered as the three objectives of Bananapus:

1. To allow active stakeholders to participate in a treasury's growth. Part of the treasury's reserved tokens can be allocated to token staker.

   For example, JuiceboxDAO could route 10% of its reserved token issuance to be claimed by those staking JBX, so that the treasury's growth which is measured in reserved rate issuance is claimable by those who already have a part of the community and are staked.

   The claimed rewards can be vested over certain interval of time, e.g. a year. If you unstake before that vesting period ends, any of the unvested rewards will be forfeit.

   The goal here is to distribute tokens more efficiently so that we have a body of active members participating in a treasury's growth. It will be a lot better to get the tokens into the hands of active participants directly, instead of some project owners of other orgnizations.

2. Same thing as 1, but allow active stakeholders to particpate in the treasury's growth across chains. An organization running on an L2 allocates a portion of its reserved tokens to staked members of an L1 organization. There are certainly some complexities to figure out, but we will try to allow these organizations to relate to one anohter and share each other's incentivized growth across chains.

3. To figure out how to govern a Juicebox treasury on-chain, while also making it safe for JBX to be able to use. We will be working closely with Nance to carry much of the governance process used by JuiceboxDAO over into Bananapus.

4. There is an intermediary step. Right now Bananapus is routing some of its NANA reserved rate to dao.jbx.eth, the multisig of JuiceboxDAO. It would be a lot better if we could reroute the reserved NANA to JBX holders directly. We will try to get JBX holder an opportunity to claim this experimental NANA situation in the next few weeks or months, so that JBX holder who are active here can participate in the actual on-chain governance process in Bananapus.

Blunt Recap by Jango​

JuiceboxDAO also approved the proposal to support Blunt Finance project in the same governance cycle.

This project has been in development for a while, and it's meant to solve a simplification problem of Juicebox project's first funding cycle.

You can try out the Blunt Finance create flow, which is only available on Goerli testnet right now. It's a very simple create flow which allows to set a funding target, a hard cap and an optional issuance rate.

Also it allows to set a time frame for the fundraising, so that it gives everyone confidence that if a project doesn't raise its funding target within a certain amount of time, a funding cycle No.2 will be automatically triggered to open up refunds which takes the burden of management away from that process.

If the goal is met successfully, the project will be passed to a pre-specified project owner and put into operation in subsequent cycles just the same as a regular Juicebox project.

Obiously Blunt project is all open source, so we can all learn from it, copy it, use it and fork it. Also we want to recognize that indie devs taking on an initiative and going to try something, prototype something and take on that risk would be healthy for the ecosystem. We should all work together to share and propagate an idea forward, as well as to create room for others to come in with new ideas of what simplicity means to them or to another subset of target audience projects.

At the same time, Blunt has got some business models within its system, so there's opportunity for its treasury to potentially see some growth. It will be also on-chain governed. We need to think pretty critically about how we will approach this kind of stuff as an ecosystem, make sure things are audited, safe and reliable before making it available to people.

Fee structure of Blunt​

When a project successfully raises its target within a certain point in time, the project's ownership will be transferred from the Blunt contract to the pre-specified project owner address.

Right before that transfer happens, the Blunt contract will schedule another funding cycle and set a payout from this project to Blunt's Juicebox treasury as the fees charged by Blunt in this fundraising. And in turn, BLUNT tokens will be issued back out to the project as the on-chain governance tokens of Blunt.

So essentially, after a successful Blunt round, the pre-specified project owner will receive a Juicebox project that encoded with a Blunt Finance payout. And the project owner can choose to remove this payout in the upcoming funding cycles that they reconfigure themselves.

Blunt collecting fees from projects that use it will be considered project-to-project payment within the Juicebox ecosystem, so no Juicebox membership fee will be charged. But if funds in the Blunt treasury were to exit the ecosystem, there still be JBX fees incurred.

Peel Updates by Tjl​

Our search functionality by Peri is live, which has been put together by Aeolian and Wraeth. There is no statistics yet, but they will put some together and find some much better than the last one.

Project tags are being used now, which is also a product by Peri and a huge win as well. Projects are slowly and surely starting to add tags for themselves, which is awesome.

Peel is making some progress with the website update. In the town hall, Wraeth is showcasing the new About page that will be shipped together with all the other website updates by end of this week.

And in the Mission section of the About page, Tjl suggests that we could discuss about some ideas to use community monetization milestones, such as 250m, 500m, 750m or 1b to do an airdrop or something similar to the community and bring them in on that mission.

Secondly, he suggests that we add an + button in the contributor section to link to the specific docs that show visitors how to contribute to Juicebox, so as to encourage new contributors to come onto JuiceboxDAO.

Feedback From Jango​

Jango suggest that we put in a JBX token ditribution information, pie chart or something of that kind. The folks in the contributors chart are the ones contributing more on a day-to-day basis with their expertise in our development flow or whatever, but there's a ton of projects that have JBX tokens by paying fees, there's also a ton of people contributed into the JuiceboxDAO treasury where we're still using the funds to actually get stuff done. Those are just as much members as everyone else. This is something that we shouldn't forget. We've got to respect ETH and the broader scope of membership, and respect ourselves as folks working here, but surely not just in the Discord process. It's kind of hard because it gets a little fuzzy and open-ended, but that's also kind of the beauty of it. Maybe it's worth figuring out how to communicate.

Buyback Delegate Update by Jango​

This is a project that has been in discussion for a while since last year, and it was something that we couldn't really do until we've stitched together the entirety of versioning since it involves the actual JBX token as well as treasuries.

Now we're at a good point after all the versioning work is done, and we have built and tested this delegate. The only next steps would be formal audits and then DAO's approval to actually stitch it onto our funding cycle.

We all know that, for each ETH that comes into our treasuries, the DAO will create new JBX according to its issuance rate and issue them outwards to those either are paying fees or just clicking the contributing button. Also we acknowledge that there is just someone out there willing to sell JBX in an open market like Uniswap for a different rate.

So in the case of open market price is lower than our issuance rate, what the buyback delegate will be proposing is that DAO will forgo taking ETH into its treasury and instead route ETH into the market, to make sure that whoever pays into our treasury will get the most JBX possible for the ETH they pay in.

We are aware that right now there's a very shallow Uniswap pool for V1 JBX, and people are still migrating to the new V3 JBX. So the buyback delegate has the open question of which pools should it be looking at. There's a case to be made that it should go and get V1 JBX to the extent that it can, and then convert it to new JBX for people as they're 1:1 convertible.

Hopefully we'll eventually start to talk about audits in the near future. There will probably be a proposal to fund the audit, and if that goes well, we'll see an opportunity to actually use the buyback delegate on the JuiceboxDAO funding cycle, and we'll get JBX in the hands of active projects and members for a better distribution.

721 Tiered Delegate Updates with Jango​

The 721 tiered delegate is the standard NFT rewards, the one that we've been using and evolving. We're at a good point now where the delegates can be evolved on their own very independently from the core terminal controller infrastructure.

There're a few improvements to the current JBTiered721Delegate that have been queued for a new version.

1. Renaming of the variable contributionFloor to prices, because we're actually treating them more as a price these days;
2. Introducing the operatable pattern, so project owners can delegate certain functions to operators, which are basically other contracts or addresses that can manage these functions on their behalf. It will be cool for allowing other contracts to post NFT tiers on a project's behalf and open up functionality there.
3. Reassessing storage bits to make more design space for certain features, and removing some other features that haven't really been used, like locking fuctionality.

There're still a few things from the current version that the front end has yet to expose and we're in the process of designing them, such as categorization aspect, and royalty function which is now available contractually for projects to deploy collections with royalties.

For now, Jango is hesitant to publish or push for prioritization of any new 721 delegates, rather just to make sure everyone know that it's changeable. We can make changes to that contract and publish new versions, and that's not a big weighty taxing versioning process as the other stuff has been.

We can also publish new types of 721 delegates, like the staking delegate that Bananpus is proposing. There are various ways you can imagine NFT working on Juicebox. Right now we're opinionated towards one because that's where we started, and we've created a flexible one to make it workable by a wide variety of applications.

We can go narrow, we can go broader, we can go specific in various ways. But it's a tricky thing to build front ends that cater towards one specifically, more so to build for something that handles a variety of different types of extensions. So, it will be a long term patient process, but hopefully we manage to capture this open-mindedness of how delegates can work on Juicebox.

Defifa Updates by Jango​

We are going to run an NBA Playoff version of Defifa with a relatively short minting session.

There will be some new NFTs that we are trying to play with both the generative art components and some HTML rendered SVGs. And contractually, we're running a similar tournament to NFL, but with an addtion that users can delegate their attestation votes upon minting, so that they can play the game without having to come back later and attest themselves, if they are feeling good about giving that resposibility to someone else, such as the ballkids or some other delegates they trust.

From a front end perspective, we're deploying the game from a new create flow, but there are still a few bugs in the whole process so we're tightening things up and looking to get that out very soon for the tournament.

It's less of a tournament to get high attetion, high traffic or high participation, more in a sense that the NFTs are cool, the tournaments are fun and we're trying some cool new things.

And we're launcing this tournament from a create flow that will be available to everyone else, so anyone can go to create.defifa.net to launch their own tournaments.

Project Tags Update by Peri​

We have officially released project tags lately, which means project owners can select up to 3 tags to associate with their projects.

The benefits of projects tags are as follows:

1. It will show up in the project header and in the search results. It's a nice little additional description that helps adding some context to what the projects are about.
2. People who are searching on the explore page can also filter projects by tags and search for projects in certain categories.
3. It will allow us the surface projects on the landing page or elsewhere in the APP for people to browse.

Except for project tags, our search fuctionality is also enhanced. Insead of searching only by project handles, we can now search for projects by text in their names and description.

Bananapus Q&A with Jango, Nicholas and other members​

Why L2? What Are The Motivations?​

1. Ideally we will get to a point where people can pay a project while incurring less gas, which also means projects can make more of what people pay in. So the priority No.1 is, with payments as the most frequent transaction, how we can make them cheaper.
2. There are also all other kinds of operations, project deployments, reconfigurations and payouts, everything becomes easier and cheaper when running on a non-L1 environment.
3. It's also movivating to be able to address new audiences and communities to build and partner with, in the various L2s where each has its own pocket of life and toolbox.

There wil be a lot of things to think about when considering how Juicebox might run on L2.

Even through the experience in our versioning efforts, we know it's hard to operate with many treasuries, as each treasury is a pocket of funds, they can accpet funds and issue tokens which are only backed by the treasury they are issued from.

Is L2 Juicebox a consideration that solves specific problems that relates to L1 Juicebox protocol, or does L2 just run an instance where people can do the same things from?

We've learned a lot over the past year doing versioning work, with regard to synchronizing and managing various treasuries. It can be expensive and delicate, but if we get it right, it can be a huge blessing that gives us a lot of great affordances. Hopefully with the persistence, we can get there anyways despite the cost and fragility.

Also it will be really delicate to keep things in various treasuries in sync, especially when they are designed to issued the same asset convertible 1:1, just like JBX on our V1, V2 and V3 treasuries. It will get even trickier to include cross-chain assets, bridging and pockets of funding that don't necessarily correlate as neatly.

The Bus Stop Metaphor​

The bridging of assets between L1 and L2s, we can do it in a way like routine bus operations.

We can have a bridging layer which basically waits for people to show up for payments with a certain time box, just like bus stop runs on daily schedules, travel back and forth between L1 and L2s. The bus stop would pay the entirety of gas for these trips, the more people get into this batched chunk, the lower the cost can be distributed across.

And the payments are generally of the same amount, for the same projects, expecting same token outcome. Except that paid by different people, they all look the same, so the L1 project can basically just treat them all as one payload.

Anything happens in the L1 project with beneficiary outcomes, such as distributed project tokens or NFTs or whatever, will get back to L2s with the bus and the payers there can claim their proportional share.

Trade-offs and benefits​

1. The L1 treasury might be operting on timed cycles, and the payment bridging bus could lead to mis-timed operations, so usually bridging operations have some time contraints.
2. L1 treasury could be running with a pay data source that makes it difficult to evenly share an outcome.
3. Project tokens and any assets will necessarily have both L1 and L2 versions, which will be interchangeable only through the bus stop. Assets are taken into custody by the bus stop to issue corresponding L2 version, which will not be backed by any L2 treasury. If tokens are used to vote on Snapshot, how will their L2 version be realted to that?

Filipv thought that a good option might be have mostly independent projects on L1 and L2, but optimizing the payout experience across chains, so that people don't have to have same projects deployed on multiple rollups, rather different projects deployed in various chains but payouts can be done between them. He added that other benefit of this option will have less cognitive burden to understand with existing Juicebox concepts. He also thought that the biggest tradeoff of the bus stop option is to add some extra complexity in our onboarding process.

Jango agreed that the bus stop bridging will be fragile to implement right now. Also he thought it will be more effective to compartmentalized opportunities and risks in communities to empower individuals rather than organizations.

With the fact that we have reserved token issuance and payouts as a function of the protocol, the Bananapus schema is to try to send a reserved JBX allocation to the projects and cohorts of project members in the ecosystem, rather than to the DAO's wallet, dao.jbx.eth, which is currently managed by a multisig. Currently we don't have an affordance to allocate reserved tokens directly to community members, but this operation will be worth experimenting, as it's an incredibly important primitive to develop so as to enable broader governance participation for individuals.

Priority of L2 operation and L1 protocol improvement​

Nicholas pointed out in the town hall the defects of Juicebox protocol as follows:

1. As a self-declared automated programmable treasury protocol, there is actually no solution for distributing payouts to really make life easier for project owners;
2. Juicebox claims to support transparency through pre-programmed on-chain payouts for potential contributors, and delay strategies can be added to let community members prepare for any unfavorable changes, but in practice it tells a different story in this respect;
3. Despite all the modularity in the protocol, in practice people are only paying with ETH, none of the ERC-20 terminals are being used. Although there is the potential for network effect of token swaps and issuance between project paying each other, the reality is that those tokens are not something people have a claim on with their membership.

Nicholas thinks that we should prioritize improving the usability of our protocol, instead of focusing on the expansion into L2 environment where there's not too much demand in there currently.

Jango said that he was interested in experimenting on L2s because there are several projects have this needs and they will benefit from it. And it's very difficult to know ahead of time what is biggest ROI for improvement of our protocol unless people come forth and elucidate their specific needs.

Nicholas reckoned that although reducing gas costs by expanding into L2s is good, it doesn't solve our primary problem which is more in the engagement with audience. So he suggested that we prioritize improvement of current protocol over expansion into L2s at this stage.

What Juicebox Is​

Jango thinks that Juicebox is a data model on Ethereum that offers a way to model data saved to the Etheruem blockchain. It's nothing without JuiceboxDAO, Peel, WAGMI, ConstitutionDAO, the DAOs that are expressed on top of it. In a sense, it's just the expression of a data model. People are able to express a lot of potential things that are built on top of the protocol, which is defined by a few set of levers that relate to each other.

Jango thinks that the protocol is way more as data layer than a product looking for acceptance. Our goal is to grow out from the inside, rather than needing to go out and convince other people that this is something they should drop everything to come study. And he's more interested in building with individuals who share the same philosophical principles, than for a specific growth mission.

Nicholas thinks that the protocol needs to be comprehensible and solve specific applications. He thinks the treasury model is not complete and doesn't work for people. Jango argues that Juicebox does solve the treasury dynamic for some people given current tools, but it's up to the project owner to make changes over time. Jango thinks there are a lot of creative ways to manage project owners and solve problems.

What Bananapus Is​

Bananapus is a proposed project with a particular schema trying to make the claim that the most important problems for Juicebox to solve are achieving on-chain governance, or nurturing cross-chain organizations, as well as working to help projects better distribute their tokens to cohorts of other members over time.

Nicholas sees Juicebox as comparable to SAFE or Uniswap, a protocol that has some functionalities and serves a purpose for people. But currently he doesn't see this protocol solves very well as an automated programmable treasury it declares to be, nor does it have any kind of solution for on-chain guaranteed expenditure of assets collected in a fundraise. He feels disappointed that all these issues have been dismissed and not discussed about. Nicholas suggests that the contract crew should prioritize addressing these issues before adding more complexity to the protocol, like expanding into L2s.

Filipv believes that the DAO needs a better way of prioritizing issues because proposals are not an accurate signal of the DAO's interests, especially like this proposal for Bananapus.

Jango thinks we are now at a point where we can afford ourselves creative freedom to figure out how we want to move next, folks can take the tool suite available and propose a narrow application of their choice. The decision of launching the Bananapus project is not a rushed one and it has been under discussions for a while. We have experienced gas price surges when it was unviable to interact with projects, and going forward we probably would see even more proliferation of rollups of chains or application specific chains, it would be nice to do a lot of this heavy legwork of strategizing how Juicebox might play in those worlds.

By submitting the proposal of Bananapus, Jango is trying to suggest our community come together and propose how we might operate on multiple chains, which acknowledging the fact that we won't be able to keep up with it as one organization. We should encourage folks who want to run the protocol on other chains and give them support.

And Jango remains confident that if the protocol is working and proves lasting as a data model, people will want to use it finally. But he's also willing to work together to figure out how to play the prioritization game, and make a deep dive in research.

Concerns about feedback being neglected​

Nicholas expresses his supports for the Bananapus project, but he also points out that there are issues that need to be addressed in our Mainnet protocol, if Juicebox wants to provide the solutions it claims to be available. And also for the protocol to be successful, it needs to have a thriving developer community, but it does seem that we have one except for our contract crew and Jacopo. He also feels the feedback that the protocol is very difficult to understand should have been incorporated into the protocol architecture discussions for a long while.

Jango says that the protocol is a piece of tooling that has seen evolution and has affordances and flexibilities, there are a lot of decisions to be made along the way, but easy could mean a different thing for different projects running on the protocol. As we have finished the versioning work, we are now in a very good position to determine what are those needs and how we might create the contracts to index the protocol, get information, aggregate them, pocket them together and then serve them to users or develops as they like.

He stands by the hyposthesis that a lot of the stuff wouldn't be usable on our current L1 protocol if it wasn't written or massaged over time. As things start out very simple, we listen to each other's ideas and share each other's concerns, and then things take shape and evolve until we get to a place where we are now. Jango wants to assure that we are not ignoring some need for simplicity, nor do we have the urge to make things complex just because it's a nerdy cool thing to do, nor that we want to go deep into the Solidity cave to have Solidity clout or whatever. We are just pointing to more optimum ways to do things or ways that might be more sound.

Jango admits that there's a lot of work to do, to make things more accessible and simple to folks, but at the very least the philosophy is sound, so we can listen to the needs of folks and try to satisfy them. We don't need to start from scratch, as we have a solid, tested and used code base to build from. He emphasizes that we are not ignoring or overlooking certains needs, there's just been a lot of preconditions and first-order concerns that allows us to even get to the point where we are. It's a long-winded patient effort to get here with a lot of work that has been done, but he's optimistic to take all the feedback into account in whatever we build next.

Nicholas thinks that we were all moving in the same direction towards enabling people to create operational on-chain projects, favoring things that are long enduring, rather than those more successful one time fundraisers, and allow people to use Nance, Blunt and JBM and all these different tools to create projects that last, so that things like open source projects choose to run on Juicebox, because it's advantageous to them and it's worth the 2.5% fees and the administrative overhead because they actually get something from it.

But currently he thinks we should figure out how to actually solve the issues that are existing in the protocol, by paying attention to what devs are thinking, what are their challenges in understanding how the protocol works. He also thinks that the shift to redeploying a protocol that has not achieved developer traction on L1 to L2, the L2 is not going to change the issue of developer traction, and it won't solve the core challenge facing the protocol, where there isn't a really thriving community making use of the protocol itself.

Jango explained that as we've been doing versioning efforts for the past year, it'd be unwise to spend any time in earnest telling people to develop on top of a protocol with looming changes. And he thought we need to either find developers or have people with big ideas and looking for engineering partners. It will take a lot of hard work to both index the world of possible projects that people are looking to build contract for, and leverage JBX as a very simple interface that people can use so that they don't have to hire a front end developer at first.

Up until now, the goal has been safety, stability and getting to a point where things work and are de-risked. The number one goal of JuiceboxDAO is security, only then can we afford ourselves anything else, because now we can build on a solid foundation, climb the ladder confidently knowing that the ladder isn't going to tip over. We're at the a point now where this thing is bolted on, after the versioning work has been finished. We can now tell people with confidence by building projects and documenting the whole thing along the way to create a catalogue of information where people can pull from.

Nicholas thinks that in a way the protocol development is actually very opaque to anyone who is not directly involved, and the decision making that goes into it obviously is expert decision making, but it somehow seems detached from what the rest of the DAO believes to be its operating mission.

He also thinks that there're actually two philosophical approaches in building products in crypto or in software, espcially in crypto.:

1. Approaches that are more focused on creating smaller things, testing them against the market and seeing what achieves traction, and then building more complexity around them. This is also what Juicebox has done to an extent
2. The more grand architectural approaches, which is not a conversation that we have ever had about the style of building that we're doing, what kinds of choices we're making about building, are we making big long term bets about our ability to imagine, what kinds of modularity is required, or do we want to do smaller iterative things and test agaist the market and see what achieves PMF (Product/Market Fit).

Nicholas thinks that what Jango expresses is not so much about PMF, but about having a data layer on the EVM that can be portable and has a lot of expressive potentials.

Jango says that the evolution from V1 to V2, hopefully gets us to a point where future iteration aren't a protocol wide change difference, but pockets that we can test agaist the market with a lot more velocity. He understands that what feels to him like an ongoing conversation may feel to others like an opaque directive without much back and forth. We could always do better with documentation, with sharing things out in town halls, and with prioritizing things in general.

Opinions of Other Members​

Filipv: I think this is an important conversation to have and I'm glad you're bringing all of these up, Nicholas. I would like for us to have more hands-on conversations about protocol development, front end development and prioritization and things like that. I find that a lot of time in town halls and Discord, it becomes very philosophical very quickly and very abstract, and I don't know if that's a great tendency for us to have. I love the kind of ideological way we approach things a lot of the time, but I do think at some level we need to be pragmatic when it comes to certain things. I don't think we can ignore the proatical reality of a lot of things, like the developer adoption that Nicholas is mentioning. I would like to have more discussions like this.

Aeolian: It doesn't seem to be a shared understanding of what the goal of all these little components are. Does everyone have a shared understanding of what the goal of the protocol actually is? Is the goal to get usage? Or is the goal, like Jango articulate, to just build it in such a way that's very secure and optimized for things to be built on top?

As a JBX holder, when I see this Bananapus proposal, I'm like: How do I evaluate this proposal? What criteria am I using to vote yes in favor of this proposal? Is it going to increase usage on the protocol? Is it going to eventually lead to more revenue, or something totally different? Is it simply that it's going to be a huge cost and a huge effort, but the value that it's going to bring to projects is going to be so grat that it's worth it? Maybe these things are kind of individual perspectives, but it seems like at a fundamental level there's no shared understanding about what our goal is.

Filipv: I think similarly I generally evalutate proposal based on maxmizing the likelihood of long term existence of JuiceboxDAO, so things like security of course are very high. But you also can not get too far in any one direction. Maximizing revenue exraction could kill the cosystem and would be bad for long term existence, but idealistically ignoring revenues and sustainability completely, treasury goes to zero, people stop contributing, then the ecosystem slowly fizzles out. I think a lot of things end up happening in the DAO are not in line with that, so I'm curious to hear how other people evaluate these kinds of things.

STVG: I thought from my perspective, most of the things that we used to evaluate proposals with is how are we going to increase usage through Juicebox and generating revenue, so that we can all continue contributing to the DAO. At one point, we were focused on these giant fundraisers, then we started going into the smaller projects, thinking that people could run startups, experiments and things of that nature on Juicebox.

I think I sort of agree and disagree both with Nicholas and Jango. I do think it's an important experiment, but at the same time I also agree that we have a lot of experiments going on right now and it may be time to start looking at our primary function, which is to generate more projects on the protocol with the hopes that it generates more revenues so that we can continue building and be more attractive to the developers and project creators.

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.