Skip to main content

71 posts tagged with "town-hall"

View All Tags

· 6 min read
Zhape

Town Hall banner by Sage Kellyn

Croptop Updates by Jango

Jango and Livid had done a lot of work to make the Croptop template support posts of audio, video and Markdown formats, so that now users can post whatever snippet of content on their ENS websites and have them all linked back to their Juicebox treasuries.

They had worked a lot in CID (Content Identifier) to make sure the content was being correctly displayed and funneled into minting process.

During the town hall, Jango showed us a website created with Croptop template but not yet pinned to an .eth domain, and demonstrated how to post and mint these contents of different formats onto a Juicebox project.

unpinned decentralized website with various formats of content

Jango had been playing with some treasury design stuff recently for both Defifa and Croptop, which had in turn led to his reflections on where JuiceboxDAO's intitial treasury design started, what were some learnings, what were some things to take into consideration moving forward, and what were the experiments Jango was eager to try. Jango wrote down his thoughts in the blog post Treasury Design Reflections on his personal ENS domain website.

In the blog post, Jango proposed some treasury designs he thought would apply decently well to projects like Croptop and Defifa. But he also thought that this design was still up for discussion, so he ecouraged folks with doubts or curiosities to come forward and share their ideas, so that hopefully we could make a better design in this respect.

fully automated treasury designs

Jango gave an example of a possible treasury design for Croptop in this town hall.

This Croptop Publishing Network project will collect 5% fee when anybody posting on this project using Croptop template. $CPN project token will in turn be issued at a ratio of 1,000,000 / ETH with a decreasing cadence of 4% each following cycle (28 days). 10% of total $CPN issuance will be reserved to a multisig for two years, with a reconfiguration to remove this reserved token allocation scheduled to start two years from now. Also a 70% redemption rate is set so that $CPN holders can choose to claim their share from the treasury anytime if they want. Ideally a buyback delegate will also be attached to the cycles so as to guarantee payments will always get $CPN at its best price available.

Then the project ownership will be thrown away, or essentially be given to a wallet that doesn't have access to make further changes to this project. It will be an experiment to check if we can figure out enough incentives to have $CPN distributed to developers who are keen to manage this project. It is a setup that leaves the bulk of the treasury unmanaged, which means folks have certain guarantees when contributing to it, and ETH in the treasury can serve a particular purpose and everyone is playing by similar rules.

At that point, Jango hoped that "devs can dev, community can community and network can network" without too many isolated concerns and interest is equally aligned throughout.

Ideas of ETH Shanghai meetup by LJ

LJ introduced that he was planning to host a Juicebox meetup during ETH Shanghai for Juicebox Chinese community from Jun. 26 - 30. His plan for this event were as follows:

  1. Host a IRL happy hour, and submit a proposal to the DAO for financial support;
  2. Organize workshops with some other DAOs that are buiding public goods, discuss about juicebox.money and how people can use Juicebox to raise funds, as well as the governance improvement of existing Juicebox projects.
  3. Put Juicebox's logo on some merchandises (like T-shirts).

Peel Updates by Aeolian

Latest work by Peel team:

  1. Bookmarked projects by Peri. On a project page, users can now click the bookmark icon to save the project to their account for future convenience.

Bookmark project by Peri

  1. Improvements to the Safe page of projects by JohnnyD. If a Juicebox project is owned by a multisig, there will be dedicated Safe page for this project on Juicebox.money, so that people can check any queued transactions or the history of transactions.

Safe page of project

  1. Revamp of project page mainly done by Wraeth.

project page revamp

  1. Thanks to Aeolian, Juicebox.money now supported the new JBTiered721Delegate V3.3 contract (NFT rewards), new project would be created with this new version.

Juicecast New Episode by Matthew and Brileigh

Matthew and Brileigh had been on the DAO Talk interview hosted by Frission from Tally, to talk about Juicebox, about working in a DAO as contributors, about decentralized media, and about making content for DAOs.

Also they invited Tommy and Frission from Tally over to the new Juicecast episode, to talk about their views on the future of onchain DAOs. This new Juicecast episode was released shortly after our town hall.

Buyback Delegate Updates by Jango

According to Jango, Dr.Gorilla had been working on some of the touchups after the Code4rena audit and Jango had also made a review on this work. Things were looking great, as soon as our contract crew went through all the questions found in this audit, the buyback delegate would be ready to use for Juicebox projects, and anyone can propose for the DAO to use it.

Jango was looking forward to using it in a few more experimental treasury designs, but he was not in a rush to put up a proposal for JuiceboxDAO to make use of it in a short period of time. Although he was definitely exited to try it in production, Jango also said he would be pretty conservative about this delegate, because it is a very big component that carries out some important functions.

Jango also believed that it had the potential to bring about significant changes to contributor operations, fee paying operations and investor operations, due to the way it work in the reserved and outward token issuance.

· 4 min read
Zhape

Town Hall banner by Sage Kellyn

Defifa Demo by Kmac

Defifa project had made some progress recently, and the team was starting to run some small games to make sure that the mechanics of the protocol and the front end UI would be working as intended, and hopefully get some feedback from users as well.

In the Town Hall, Kmac invited the audience to play a simple chicken-shit-bingo style game that he ran with Defifa.

Defifa.net now

Aeolian recently joined the Defifa team and helped improving some front end stuff and updated the codebase with a few libraries.. Most of the original codebase had still been those started and evolved by Blaz and Devian in the early stage of this project last yea, and their technical components under the hood were quite different from those being used on juicebox.money.

And according to Kmac, the NFTs are all dynamically generating SVGs that will reflect some information about the game, such as number of times they have been minted, and the different phases that the game evolves into, which means the state of the game will always be represented in each NFT in real time.

This SVG development had been carried out mainly by Jango, and Kmac was working to push it one step further to accept artwork uploaded by users, so that the NFTs would have custom artwork on one side, and full onchain SVGs reflecting the state of the game on the other side.

They wanted to get to a place where the game would be reflected inside the NFTs, so that no matter where people look at them, either from their wallets or makets like OpenSea, they can get a glimpse of the current phase of a game, or the NFT's backing value if the game is over and distribution is done.

And also according to Jango, the attestation process that they were about to try out for the Defifa project was based on a Governor Bravo contract, which Jango had been refactoring to make it more Defifa specific and lean. He thought that maybe this component could be reused, if other folks had similar game mechanics they wanted to implement as a state machine.

Buyback Delegate Audit Updates by Dr.Gorilla

The audit contest of Buyback delegate on Code4rena had ended on May 23rd. According to Dr.Gorilla, the full process of auditing had not been finished yet. Our contract crew had reviewed the findings, acknowledged or disputed them accordingly, and Code4rena had yet to publish the final audit report at the moment of this town hall. By far, no bugs of high severity had been found, and only a few medium severity ones and some gas optimizations had been proposed to our contract crew.

Dr.Gorilla said that he had started implementing what was in need of improvement, expecting to get it done by end of this week.

Metadata Refresh Demo by Nicholas

The Juicebox cards was a project which allowed users to mint an NFT to replicate the metadata of a Juicebox project and stay updated with its changes. This project was developed by NIcholas, and was now working at Juicebox.cards, but it was not yet finalized because there was still some work in progress as he needed to rewrite the contract to implement some more things.

Juicebox.cards website

Nicholas had been working on a Juicebox metadata updater. As the metadata of a Juicebox project is generated onchain, its values change over time. But when these NFTs are shown on OpenSea or other sites that relying on OpenSea, their metadata won't be refreshed real time, but rather with their cache stored in OpenSea. This Juicebox metadata updater helps updating the metadata of these NFTs on OpenSea so that the metadata shown there are always up-to-date.

Also Nicholas launched a fundrasing round on Blunt, to check if there would be enough interest in generlizing this product for all other 721 projects on OpenSea.

OpenSea Metadata Refresher Blunt round

Delegate Hackathon Callout by Filipv

Filipv was coordinating with Austin Griffith from BuidlGuidl to host a new hackathon on Juicebox. The plan was to make use of the leftover funds in BuidlGuidl's Juicebox project from their last hackathon, and some grants that Filipv had the thought of applying from JuiceboxDAO for support, and to implement this event as a joint effort of JuiceboxDAO and BuidlGuidl.

This hackathon is aimed at building new Juicebox delegates and/or data source for the use in the Juicebox ecosystem, and the draft game plan of it can be found here.

In the Town Hall, Filipv called out that folks with ideas about funds delegates or data sources can come forth and share them in our Discord.

Delegate hackathon with BuidlGuidl

· 6 min read
Zhape

Town Hall banner by Sage Kellyn

Croptop Updates by Jango

The development of Croptop had been close to its final stage, things were really starting to shape up, and Jango were eager to wrap it up and see how it unfolds.

To try to play with the current version of Croptop, you may go to croptop.eth and follow the steps there:

Croptop.eth.limo instructions

Jango introduced that there were a Fork button at the top right corner on any site that is running with Croptop template. By clicking it, people can try to start using Croptop to post and mint contents onchain in a decentralized way in the following steps:

Croptop instructions for people to fork this fundraising solution

  1. Choose the chain that you want to deploy your project. Right now, it will be only available on Goerli testnet, but Ethereum, Polygon and other L2 deployment will be coming soon.

  2. By click the "Make a new Juicebox", there will be a shortcut to quickly launch a Juicebox project, where people can pay you to record content onchain. You will need to set the name and symbol of the NFT collection, as well as the owner of this Juicebox project. And the Minimum price, Min total supply and Max total supply are the boundaries set for posting on your project. When people post specific content on your project, they can set their own parameters for prices and supply, but those parameters must fall within the boundaries set originally by you, the project owner.

    Croptop shortcut to create a Juicebox project

  3. Next step will be giving permisson to Croptop contract to post on your Juicebox project on your behalf, as an operator. After deploying the project in the step before, you can get its project ID and fill it in so as to give Croptop contract the permission to post NFTs on this project.

    Croptop to give permission to post

  4. Last step will be optional, setting the addresses that can post to your Juicebox project via Croptop, and also the category of NFTs that will be allowed to be posted.

    Croptop to set allowed list for posting

Right now, we were still using the Planet App to implement this Croptop fundraising initiative, but Jango said we would soon have a dedicated Croptop Mac App, which should be more straightforward and easy to use.

So if you're on a Mac and you want to make use of your ENS name to run a personal fundraising site, this is going to be a really good way to tell stories about what you're working on.

Defifa Updates by Jango and Kmac

The Defifa team had been planning to host a tournament for the NBA finals, but their plans had been delayed quite a few times, mainly due to a lack of devs taking care of the front end stuff. Jango was very grateful for Aeolian to show up recently in Defifa and help cleaning stuff up, which made a tournament for NBA finals very likely now.

According to Kmac, the Defifa code base had got a total refresh and the create flow finalized with the help of Aeolian, giving the team the ability to actually go discovering some games in a light way. Their first goal was to set up a few self-hosted tournaments, making sure that everything is working fine before the create flow is officially open for public use.

Jango reiterated that the cool thing about Defifa is that, we don't really need an official oracle to define the games for us, but in stead we can make whatever rules and distributions that we want, allowing for some very cool and creative outcome.

Peel Update by Tim

There were two major work projects underway in Peel team at this momentl: the project page revamp and the project settings improvement.

For project page revamp, Peel was starting on a new trajectory in terms of project page layout and what could be done, as well as introducing some new features such as a cart to support adding multiple NFTs or collections.

And for project settings, there was already a delegation page live on the project setting home page, which was an easier navigation page. Peel had split up some items in the settings and made them more user friendly and easier to navigate.

Delegation page on project settings home

Next, they would be focusing on the revamp of Cycle configuration and payout components in the project settings page.

Project NFT Theme and Juicebox Cards by Nicholas

Project NFT Theme

Nicholas developed a TokenURI resolver contract a little while ago, which lets project owners to tweak the metadata of their projects, or totally replace the project's default metadata by setting their own custom resolver. This function had been officially integrated into the project settings on Juicebox.money website, and now available to use for all project owners.

Project NFT Theme setting page

Juicebox Cards

Nicholas also wrote a Juicebox project cards contract, an ERC-1155 NFT contract that lets users mint an NFT replicating the metadata of any Juicebox project and keep it in their wallets, making it possible for them to stay updated with any changes of that specific project.

Nicholas had been absent from this Town Hall, so he asked Matthew to concisely introduce this product in the town hall, and help calling out people to go to the Beta site of Juicebox Cards and give it a try. Any feedback on that would be highly welcome.

Juice Cards beta site

Juicecast Updates by Matthew and Brileigh

Matthew and Brileigh announced the release of a new Juicecast episode, featuring Livid from Planet, the App that recently Jango had been using to push his Croptop efforts.

In this episode, they talked about:

  • How Livid had been building V2EX, one of the most active communities for Chinese devs;
  • Planet, an open source tool helping people build decentralized ENS websites;
  • Planetable Pinning, the project Livid created on Juicebox as the infrastructure of pinning services for decentralized websites;
  • Croptop, an experimental Planet template that he helped developing in collaboration with Jango;
  • Livid's personal passion about retro games and the game database built from Internet Archive.

Prop House and MCSA Updates by STVG

STVG joined the Prop House Twitter space today, talking about the process of getting JuiceboxDAO's approval on the proposal to fund more Juicebox Open Rounds on Prop House. He was planning to host 3 more Open Rounds respectively on June, July and August this year.

Proposal to fund more open rounds on prop house

And in the same cycle, he also submitted another proposal to sponsor T-shirts for water polo events, which had been approved by the DAO too. These sports events would be hosted by the non-profit Juicebox project MCSA created by STVG. He felt that the sponsorship on these events would help promoting Juicebox to people in real life, and also he expressed his gratitude to community members in supporting his proposal.

JBX sponsorship in water polo T-shirts

· 5 min read
Zhape

Town Hall banner by Sage Kellyn

Defifa Demo by Kmac

Defifa is a project that received grants from JuiceboxDAO to organize a game for the World Cup at the end of last year. The tournament game was highly successful. Following that, they also arranged a tournament for NFL playoffs in early 2023.

During this process, the team realized that the concept of creating tournaments should be accessible to the public, not just limited to their own use. This led them to explore the idea of developing a protocol and platform for creating money games and delivering an arcade-like experience.

Kmac took the lead in applying for grants with Seed Club and Base Ecosystem Fund. Additionally, they were preparing to submit a similar proposal to JuiceboxDAO in the near future.

During the Town Hall, Kmac presented the game flow of a Defifa tournament using an example game he created. This particular game focused on the top Spotify artists for June 2023. Participants could mint NFTs representing different artists to contribute to the prize pool. The distribution of the prize pool was designed as follows: 50% to the player who selected the most popular artist, 30% to the second most popular, and the remaining 20% divided among the third to fifth most popular artists.

The tournament followed a structured flow, consisting of the following phases:

  1. Open ceremony: A minting phase where participants could mint NFTs of their choice. They had the flexibility to quit and receive a refund at any time during this phase.
  2. Refund deadline: Participants had the opportunity to review the minting status of the game and assess their odds of winning. They could choose to leave the game before the refund deadline.
  3. Kickoff: The game officially started, and the pot of funds became locked. Refunds were no longer permitted.
  4. Final whistle: The game concluded, and all players came together to validate the final result on the blockchain. Based on the outcome, the funds in the treasury would be backing the winning NFTs. Those NFT holders had the option to either burn and reclaim the ETH or retain the NFTs and trade them in the market.

The Create Flow of Defifa

During the town hall, Kmac provided a demonstration of the new create flow of Defifa, outlining the two steps involved in game creation.

  1. The first step entails setting the name of the game, the duration for minting NFTs, the refund duration, and the start and end times of the game.

Defifa create flow step 1

  1. The second step allows users to customize the NFTs for the tournament, including setting their prices and allocating a reserved rate to a pre-defined beneficiary.

Defifa create flow step 2

While the create flow was still a work in progress, Jango highlighted two noteworthy features in the contract that have not yet been supported in the UI:

  • Distribution limit: This feature enables a percentage of the game's treasury to be allocated to a charity or another Juicebox project. Once the game starts, this allocation can be distributed, while the remaining treasury is utilized to run the game.
  • Splits of reserved rate distribution: Users can designate a reserved rate beneficiary for each tier of the NFTs or each team of a competition. For example, a certain address could receive one out of every ten NFTs minted for one team, while a different address could receive the reserved rate for another team.

Jango expressed interest in exploring how the contracts work, how users perceive them, and the potential patterns that may emerge from their usage.

Furthermore, Jango emphasized that the artwork associated with the past two tournaments held significant value beyond the treasury backing the NFTs. These expressive playing cards could have a lasting presence in people's wallets, and it was exciting to consider how they could attach to emerging tournaments and amplify their significance.

Lastly, Jango mentioned that all the components on defifa.net should be compatible with juicebox.money, allowing users to play the game on either platform. As long as the platform recognizes the Defifa delegate and creates an adapter that can interpret the NFT view, cross-referenced games accessible from different front ends with standard interactivity and interconnectivity could become a reality.

Visibility Updates by Matthewbrooks

Matthew and Brileigh were preparing to interview Livid, the developer of Planet APP and the Juicebox project called Planetable Pinning, for an upcoming episode of Juicecast. You can learn more about Planet at Planet and explore Planetable Pinning on Juicebox.

In addition to that, they will also be having discussions with the team at CryoDAO.

To provide more helpful resources, they had recently published several videos and blog posts with guides for various purposes. These valuable resources will be showcased in our upcoming Town Hall next week. Stay tuned for more updates and exciting demos!

analysis between Kickstarter, Indiegogo and Juicebox

L2 and Croptop Updates from Jango

We had seen some great progress in the Bananapus staking component thanks to the efforts of both 0xBA5ED and Viraz. We would be excited to have an update in the upcoming week.

Regarding the L2 deployment of the Juicebox protocol, there had been a slight delay. The team had decided it would be more efficient to organize the repositories separately. This means the Juicebox V3 repository will remain as it is, while a new repository will be created specifically for multi-chain purposes. Once the new repository is up and running, we will proceed with integrating it into Defifa.

In recent weeks, Jango had been actively working on updates for the Croptop templates. Additionally, he had launched an experimental Croptop Publish Network project on Goerli test net, which serves as an unowned central hub for decentralized posting and minting of P2P distributed contents.

Croptop Publishing Network project on Goerli

· 6 min read
Zhape

Town Hall banner by Sage Kellyn

Meme Coin Fair Lunch with Blunt by Jango

Blunt is a project that has been supported and funded by JuiceboxDAO to experiment some niche features of fundraising's first rounds. A Blunt round can be created with very tightly scoped preconfigured rules, such as a funding hard cap, funding target and a funding deadline, etc. For example, if a fundraising campaign doesn't reach its target within a deadline, a funding cycle #2 will be automatically configured to open the refunds for everyone participated in the Blunt round. If the fundrasing ends with success, then the ownership of this project will be automatically transferred to the pre-defined owner's wallet address, and the project will be operating onward, same as an ordinary Juicebox project.

Fair Lunch is a project that aims to help people crowdfund to create a meme coin in a fair and decentralized way. When funding is closed with success, the new meme coins and funded ETH will be used to start a liquidity pool on AMMs automatically at a proportion defined in advance, so as to ensure a fair launch of the meme coin, lunch served!

In the Town Hall, Jango demonstrated how to use Blunt to create a Fair Lunch funding round. When this fundraising ends successfully, then the ownership of this project will be transferred to, intead of a pre-defined owner. but the Fair Lunch contract, which will in turn schedule a new funding cycle immediately that allows owner's token minting and distribution of all ETH in the project's treasury to Fair Lunch contract. Then the meme coins will be paired with ETH at a certain ratio and added to a liquidity pool on AMMs.

From a pattern's perspective, we have this hook onERC721Received, which is the standard hook for ERC721s, and it will be used to detect when the project ownership on Blunt is passed to the Fair Lunch contract and trigger the actions thereafter.

There are two parameters to make a new fair lunch and describe a particular Fair Lunch contract, the Multipler and the Splits.

  • The Multiplier sets the initial price that the tokens will be offered in the LP. A multiplier of 1 basically means mint exactly at the token/ETH ratio specified in the Blunt round to start the LP. A higher multiplier will make the token price better in the initiation of that LP.
  • Juicebox Splits can be set so that as soon as the Blunt ownership is transferred and so are the raised the funds, some of the funds can be split off and routed to a list of beneficiary addresses, while the leftover funds will be used to kickstart the LP.

Croptop Contract on Planet by Jango

Planet App is a decentralized solution for users to run their websites on ENS domains, they can locally host the contents which will be pinned to IPFS and referenced to an ENS through IPNS address. The contents are distributed through a peer-to-peer network without relying on servers or other centralized services. Once distributed and collected by other users, the contents will no longer be removable by their original publishers.

Croptop contract is a Planet template developed by Jango, to help make this a fundraising tool and let people post the contents onto a Juicebox treasury and make them available for minting as NFTs.

To try the Planet app with the Croptop template, here are the steps to be followed (only available in Mac right now):

  1. Download Planet Mac app from here;

  2. Create your own Planet by clicking "Create Planet";

    create your own planet

  3. Set Croptop as the template of the new Planet;

    set croptop template for your planet

  4. Right click the created Planet and copy IPNS;

    get the IPNS of your planet

  5. Go to ENS app to edit records for your ENS name, paste the IPNS into the field of Content Hash and add a prefix of "ipns://" in front of it.

    referencing IPNS in ENS name's Content Hash

  6. After the planet is propagated through the peer-to-peer network, you can visit your Planet with your ENS name by going a corresponding address like jango.eth.limo in the browser.

  7. Go to the template setting and your can set the Juicebox project ID that images on your Planet will be posted and minted from.

    croptop integration of Juicebox project ID

  8. Juicebox.money front end will soon support the Juicebox project owners to set the Croptop contract as an operator in the project's settings, to post NFTs on the project page on their behalf.

If you are interested in how to collect a image from an ENS website and post it onto a Juicebox project, please jump here to check what Jango and Livid introduced in our last Town Hall.

Though Planet allows people to host the contents distributed peer-to-peer, propagation in the peer-to-peer system might not very fast at this stage. Planet has a Juicebox project called Plantable Pinning which offers a central pinning service to make the propagation a lot faster, people can choose to mint NFTs on this project to have access to this pinning service.

Anyone who is interested to know more about Croptop is welcome to join the Croptop Discord.

Peel Updates by Tjl

Recent work by Peel:

  • Peri had been doing a lot of work under the hood on Apollo and subgraph and making a better developer experience and performance.

  • New NFT contracts was live on Goerli testnet, they should be ready to be in production by next week, pending some collaboration with the contract crew.

  • There had been a relatively big bug with Edit payouts section which turned out not being structured the right way, it had been fixed by JohnnyD.

  • We now have a new ConnectKit wallet in our Connect section, to provide a much smoother UX, especially for people who don't have wallets. It looks really nice on mobile.

    connect wallet interface on mobile

On the Town Hall, Tjl also walked us through Canny, which is essentially a tool that allows people to add a feature request idea or some feedback, and also allows people to vote on it. Peel team had been using this in front end work for a while. Nicholas suggested that we should expand this tool outwards and allow anybody in the DAO to post in Canny our updates, ideas or feeback. So, now anybody can come here to post their ideas or feedback, vote on them or add some comments.

It will probably be a very good way to get a temperature check on things that community members care about or are interested in.

Canny for idea management

· 17 min read
Zhape

Town Hall banner by Sage Kellyn

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.

app framework blog post

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

app framework 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.

mockup of app store

Opportunities

What Tjl saw as the opportunities of take this initiative:

Opportunities

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.

Project cards

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.

tokenUriResolver in project setting

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.

custom price by ppl posting NFT

NFT posted on the project page

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.

· 3 min read
Zhape

Town Hall banner by Sage Kellyn

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.

JBDAO homepage

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.

New template of proposal

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.

New landing page for Juicenews

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.

Thirsty Thirsty Season 1 treasury and NFT

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.

NFT Brazil proposal

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.

· 9 min read
Zhape

Town Hall banner by Sage Kellyn

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.

New homepage

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.

Eventive platform

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.

· 11 min read
Zhape

Town Hall banner by Sage Kellyn

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.

Bananapus steps to be taken

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.

Blunt create flow

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.

New About Page

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.

New About page - 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.

New About page - contributors

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.

· 19 min read
Zhape

Town Hall banner by Sage Kellyn

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.