Skip to main content

· 9 min read

Town Hall banner by Sage Kellyn

Feedback on Documentation by Hackathon Participants

Nowonder, one of the the hackathon participants, suggestted that we have a visual material about the payment terminals, possible delegates and options of all possible configurations, which helps with the understanding of all the process, and reduces the friction of having to go over all the section of documentation.

Actually we had released a video of going through how to start a repository of delegates, which was considered very helpful by certain participants. But as it was not posted on the right pages in the docs, it didn't reach some of the participants, and Filipv promised to solve this problem.

Jango thought some of the hackathon submissions with videos or solid readme file might might be useful for other folks in the future. He also suggestted that we keep an index of these open source delegates written by the participants with links to the authors, so that if audited or reviewed by the community, we can promote them in a different section.

A Runthrough of Hackathon Submissions

1. Instant Swap Delegate

Submitted by: Aeolian

Description: A Juicebox protocol pay delegate for automating treasury token swaps.



Team Juicebox project:

Instant Swap Delegate

2. JuiceTable

Submitted by: LJ

Description: A version of Juicebox Protocol integrating with EthSign TokenTable, allowing projects to have the functionality to customize token unlocking schedules for project token distribution, while still raise funds through the secure Juicebox Protocol.

Repo (smart contract):

Repo (frontend):


Team Juicebox Project:

JuiceTable delegate

3. JBStraws (Merkle Root Whitelist)

Submitted by: nowonder

Description: A data source which functions as a whitelist, allowing the project owner to upload new merkle roots over time. Includes access control via JBOperatable, which allows admins to set a new merkle root and enable/disable the whitelist.

Repo (smart contract):

Repo (frontend):


Team Juicebox Project:

JBStraws delegate


Submitted by: Meme Man

Description: A simple and highly configurable delegate to allow a project owner to give a bonus (or reduction) in tokens received for contributing to a project based on how much ETH is sent in that contribution.



Team Juicebox Project:


Submitted by: Armand

Description: The main juice of this project is adding a JB project option to use a dominant assurance escrow contract that quadruples as a JB Data Source, JB Pay Delegate, and JB Redemption Delegate. The escrow contract features Alex Tabarrok’s “dominant assurance” contract idea, which tries to minimize the "free-rider problem" by rewarding early pledgers with an owner-deposited refund bonus upon a failed campaign/cycle. If the funding target is met, the pledger's pledges turn into payments that fund the project, and the project owner withdraws their original refund bonus deposit from the escrow contract / JB Data Source. This alternative mechanism can be extended to fund any type of crowdfunding campaign or public good.

Repo (smart contract):

Repo (frontend):


Team Juicebox Project:

DominantJuice delegate

6. JuiceboxDataSourceAggregator

Submitted by: weaver

Description: A project aiming to provide simple data aggregation for Data Sources. It features practical examples showcasing the utilization of average weights derived from multiple sources, as well as the implementation of multisource allow lists. Simple interfaces and implementations to be extended for further use.


Team Juicebox Project:

Thoughts on Front End Support in JBM

Jango thought it will be great to consider adding an optional datasource address in the create flow and reconfigure flow of to folks who are deploying these delegates and want to provide a create flow throught JBM.

Filipv agreed with this, and said that more tightly scope and generic front ends will be very nice to have, such as a dedicated hackathon front end repo as a template for working with Juicebox contract specifically.

Buyback Delegate Proposal Introduction by Jango

At the time of this town hall, A proposal to implement the buyback delegate on JuiceboxDAO submitted by Filipv was under governance voting process.

Proposal of implementing buyback delegate

Jango thought that a lot of things were waiting on the deployment of this buyback delegate, and it would be exciting on many fronts. This governance proposal to implement it would help prepare ourselves for the outcome of this product.

This proposal also requires a migration of current buyback delegate version from 3.1 to 3.1.1 for JuiceboxDAO, which has the implication of incurring fees for JBX redemptions from JuiceboxDAO treasury. As this extra fees for redemption will have 1% negative effect on redemptions, Jango said this migration would be just for dev convenience to update to the version in conformity with our development goal.

Jango said the first step of execution of this proposal would be the migration only, and after we experiment successfully with lower risk project like Defifa or Croptop, our contract crew would advise the DAO to reconfigure it to the JuiceboxDAO project.

For the buyback delegate to be effective, we might also need to create a liquidity pool for a ETH and V3 JBX pair and add funds to it. Jango expected that there would be higher trading volumes for JBX on Uniswap.

Overall, Jango thought the deployment of buyback delegate would be a move with lots of risk. If this proposal gets approved by the DAO, it also means the DAO acknowledge the risk and is willing to go forward.

Dev Oriented Videos and Juicecast by Matthew and Brileigh

Buyback Delegate Introduction Video

In the video recorded by Matthew, JuiceboxDAO contract crew, including Jango, Dr.Gorilla and Viraz gave a walkthrough for the buyback delegate contract and explained the working mechanism of it.

This is one of the efforts to provide some more developer oriented content. Also they were planning produce another video with Peel, to go throught the Juicebox interface, problems solved and subgraph queries, etc.

New Episode of Juicecast featuring Nicholas

They also released the last epidosde of Juicecast with Nicholas. In this episode, Nicholas talked about the onchain SVGs, Juicebox metadata contracts, token URI resolver, the Juicebox cards project, and his ETH Waterloo project with the new ERC-6551 standard.

EthCC Guide by Bruxa

Thristy Thirsty would be hosting an event during the EthCC, and Bruxa used the Croptop template to make a guild to this event on their ETH domain name website thirstythirsty.eth. They would be releasing this guide to community members and allowing them to collect the content as NFTs without having to token gate any of those content.

Bruxa said this method of propagation feels very good to direct sponsors or clients to pay to their project, which in turn pays their people on the ground providing services. They plan to use this way to demostrate their transparent treasury and hopefully attract sponsors, partners and ultimately members to their community. She was excited about this experiment and grateful to launch it with Croptop and Juicebox.

Thirsty Thirsty event guide

Retailism by Jango

Retailism is a concept that Jango proposed recently in the process of thinking about the treasury designs of Defifa and Croptop. For those projects created with these frameworks, instead of various Defifa games and Croptop collections are independent treasuries from an application perspective, but rather those applications take fees into a singular treasury, such as Defifa network treasury and Croptop network treasury in a way that there would be incentives to encourage developers to develop and network to network in peace.

Essentially retailism, in the background of Juicebox protocol, depicts a way projects are built, where its treasury doesn't have any outward payouts, any funds that come into the treasury emits tokens outward, and the only way to access funds in the treasury is to burn the tokens to redeem from it.

In this framework, how do developers, who often need cash flow to do certain things including paying themselves, get paid? how to build confidence in investors so that they are willing to invest and understand what the investment means? How to balance the necessary energy to push the projects forward?

Up till the moment of this town hall, Jango had written 4 blog posts to express his thoughts in this concept.


The first one is an overview to this concept, explaining the What, Why, Who, When and How this framework of retailism will apply and outcompete within a broader capitalist marketplace and avoid retail extraction of generations of participants.

Retailism blog post

A Retailistic View on CAC and LTV

Different from the business model of profitting from the difference between CAC (Customer Acquisition Cost) and LTV (Lifetime Value) in the traditional Software-as-a-services business world, retailistic software distribution encourages growth differently by presuposing a networked environment where participants share the things they like with one another, help one another learn how to use things, and troubleshoot problems together.

A Retailistic View on CAC and LTV

Modeling Retailism

This post describe the rules to shape a retailist network, a different combination of these variables might determine the different trajectory of these networks. And also the way these rules affect the network's growth rate and exit rate might give rise to some tensions.

It also provides a spreadsheet to play with different variables to feel various trajectories of these retailist networks.

Modeling Retailism

Retailism for Devs, Investors, and Customers

The last post analyzes why a retailist network will be productive certain groups of network participants and why not for others.

Retailism for Devs and Investors and Customers

The last thing missing in this concept will be the buyback delegate, which helps easing the price fluctuations over time between the entrance rate (issuance rate) and the exit rate (redemption rate). Once these last contractual components fit together, we will have some experiments in practice through Defifa and Croptop. And we will study them live and find out what works and what does not, evolve them further, before forking the framework for different kinds of software projects.

Peel Updates and Demo by Tjl

Peel team had pushed a new feature to the project page on, which allows project owners to add updates for a project so as to keep their communities informed of latest changes, such as announcements, events, partnerships, development milestones etc.

The updates will also show the time of posting and the wallet address that posts it. And the project owners can delete a certain update and add another one, but they won't be able to edit the posted updates.

new feature of project updates

· 6 min read

Town Hall banner by Sage Kellyn

Juicebox 2nd Anniversary Reflection

Development history

At the beginning of this town hall, Jango reminded us that, July 15th this week marks the 2nd anniversary of the deployment of the Juicebox protocol. It was an excellent opportunity for us to reflect and share our feelings about this journey.

Jango appreciated how this community tended to manifest mostly on GitHub in general, which has been a theme since the beginning. This, along with propogating Bannys, had been our two primary modalities. However, he suggested we consider how we might relate more to the events in various local communities, and to ourselves as individuals spreading around the world with our own respective local communities. As we shift towards more application-oriented development, building stronger relationships will play an very important role.

The consistent cohort of individuals who feel a sense of agency over their contributions has been impressive. It's inspiring to witness organizations like Krause House building projects on Juicebox which are relating back to their own DAOs. We had been exploring our role as a Juicebox community and whether we should define it with specific objectives, or keep evolving organically.

Jango prefers that we take a flexible approach to our general value sets and our goals, while revisiting and discussing them on a week-to-week basis without rigid constraints, and being open to critiques along the way.

The Juicebox protocol started with a finite purpose, facilitating fundraising. And then that played itself out in the first year with some early research into how it might evolve.

In the second year, about this time a year ago, we were working on the early prototypes or pre-prototypes of the NFT delegate. We had the idea about what V2 would be and how it should evolve from V1 to support those open-ended delegates, so people can pursue more open-ended projects. And then we created projects such as Defifa, Croptop and Blunt etc. as pockets of experimentation, allowing users to express themselves creatively while exploring different treasury designs.

As a community, we'll reflect on other people's visions, support their concepts, and envision what challenges and opportunities lie ahead a year from now. Jango emphasizes that we have many expressions of treasury design that our users might appreciate, but we need to ensure they can easily grasp the possibilities and benefits.

While the base protocol offers infinite ways to schedule and structure treasury designs, Jango encourages us to remain open-minded and creative. As we continue this exciting journey, we look forward to shaping the future of JuiceboxDAO and embracing the ever-evolving landscape of decentralized finance.

L2 Deployment

Jango believes that there are clear market opportunities for Layer 2 solutions to build applications on. However, he recognizes that it would be challenging for a centralized entity like JuiceboxDAO to deploy across all these networks. Addressing issues like documentation and project owner relations would be very complex.

In his view, Ethereum is the most challenging environment, and he wants to ensure it is deployed correctly on the mainnet before rushing into other networks. The true value of Juicebox lies in creating organizations that are truly owned by their users. If it succeeds on the mainnet, it should succeed on other networks too.

Currently, there are no blockers preventing Juicebox from deploying to Layer 2 solutions. The team's focus is directed elsewhere at the moment. However, once other aspects are ironed out, and the core protocol gains enough traction, it would be beneficial for all applications to deploy on other environments in Layer 2 and make them accessible from there as well.

On the Upcoming Year

Jango pondered on the possibilities for the upcoming year and wondered if the focus would be on Layer 2 and technical solutions or on integrating existing tools to unlock new opportunities. While he recognized the importance of Layer 2 solutions, he was more intrigued by the idea of organizations acting as intermediaries between Ethereum, Juicebox (as a database), and users.

He saw the next year as a time to bridge the gap between real-world users and use cases, moving beyond building generic infrastructure and sculpting it into specific and enabling toolsets that people could readily adopt for their projects.

Mieos expressed his belief that our current economic system was insufficient for a better future for people and the planet. He foresaw a significant shift in how businesses and innovation revolve around economics. He was particularly excited about Juicebox serving as a toolset ready for a cultural shift, empowering new ideas around economic models, business strategies, and user incentivizations.

Jango shared Mieos's enthusiasm and saw Juicebox as a programming language for money, allowing users to create new relationships between customers and producers, ushering in a promising era of possibilities.

"Year of the Dev"

Jango looked back on the blog post Year of the Dev that he wrote about a year and a half ago, realizing that its essence still resonates strongly with the community today, despite some changes. He cherished the fact that we are a developer-oriented community, where individuals build with their unique perspectives and support each other throughout the process.

As diverse individuals, we bring our own artistic approaches to making things happen, with values that may differ but contribute to our collective growth. Jango emphasized the importance of learning from one another, as well as from the diverse experiences and viewpoints beyond our commonalities, which continuously drive us forward.

blog post Year of the Dev

Jango expressed deep gratitude and excitement for the past year of building, acknowledging that it came with its fair share of challenges. However, the team successfully navigated through those obstacles and embarked on a journey of showcasing new aspects of the project. They highlighted their tasteful discoveries and emphasized financial value sets that held great significance to them.

With confidence, Jango believed that these developments would propel the project forward for many years to come, and he felt a genuine sense of excitement to be actively involved in its ongoing development.

· 11 min read

Town Hall banner by Sage Kellyn

ETH Waterloo Updates by Nicholas

Nicholas attended the ETH Waterloo last week and gave a speech on this event. The speech was about the token URI resolver and how users can make their own resolver with on-chain metadata.

And he also made a hackathon project with on-chain SVGs which won a prize among the 11 finalists projects selected from this event.

There were quite a few sponsors on ETH Waterloo, such as Gnosis Chain, World Coin, Polygon, Sismo and Hyperlane etc. which had been pushing for narratives of Zero Knowledge or Cross chain. Nicholas thought sponsoring this type of event can be very ROI positive to help propogating use of protocols or APIs. Maybe we could think of sponsoring on similar events and make the requirements more specifically so that participants would make more use and dive deeper into our Juicebox protocol.

Jango agreed with that, and said even from an auditing perspective, we could gain a lot from the points of contact, feedback and iterations in these events. So it might be worthwhile to have many people try to build stuff on our protocol, which would help us to improve the documentations and developer experience.

Nicholas thought that the biggest challenge for us would probably be getting technical people on site to both support during the hackathon and judge after it, which would be very helpful for users to integrate our protocol with what they aim to develop.

He also thought that ETH Global is a great event for us to partner with, and as ETH Global have almost one event every month, we don't need to wait too much time after we decide what we should do.

Delegate Hackathon Updates by Jango

Our Delegate Hackathon in collaboration with Buidl Guidl would start this week. Jango would like to go through the process alongside anyone else who wants to hack on delegates, which are basically pockets of codes that get triggered whenever a treasury receives a payment or someone tries to redeem from a treasury.

He thought that it'd be cool to see some folks who are more used to working on other bits of the ecosystem to try their hands on some contract codes. The delegates could be something you do either for some non-programmatic purposes, or for fancy programmatic initiatives.

Earlier, TJL had asked about how we were going to do with front ends for this hackathon or whether everyone would need a Juicebox project to try it out. Jango thought that there would be a lot of Goerli projects made in the next week through this hackathon, some of which might end up feeling strange because they only have some half-baked delegate attached. When there were interesting cases that front end could help with, we would definitely want to call those out. But in general, the current front end will trigger all the delegates anyways.

It would be hard for the to know what would happen during this hackathon. If a project has a data source or delegate that it doesn't recognize, they will still get called. So that folks can still just make payments and know for their own sake that they're trying out a prototype of theirs.

Jango thought it'd be cool to consider supporting some of these projects with light weight, one-screen UIs that are more use case specific, but it's not a must. He pointed out that we could always make use of Etherscan in a worst case scenario, with some good documentation of how to format all the parameters.

Bananapus Demo by 0xBA5ED and Jango

Jango introduced that Bananapus is a project focused on L2 developments and trying to experiment how to make Juicebox function well in L2s. The major part of that lies in making cross chain operations workable and sensible for a group of people who share an interest in a certain token or an organization.

The pre-requisite of this system is to have a staking component for Juicebox project tokens. Although these token might have other use cases, it would be really useful to get us to L2s with these cross-chain capabilities.

The staking of Bananapus works in a way that instead of having NFTs denominated in ETH, it is going to use a payment terminal denominated in an arbitrary ERC-20 token of a Juicebox project, for example, a JBX payment terminal. The mental model of staking for Bananapus is that users can pay some ERC-20 tokens to a Juicebox treasury to mint an NFT, and also can redeem this NFT to get their tokens back from this treasury. We can reuse the UI and all the fuctionalities of a treasury to model it.

Once the users have one of these NFTs minted by staking their ERC-20 tokens, we can add more functionalities into the NFTs, one of which is rewarding funds from the reserved rate of another project treasury to the stakers. For instance, we can allocate 10% of reserved tokens of JuiceboxDAO to be shared between everyone who has currently staked their JBX and hold one of these NFTs.

On the Town Hall, 0xBA5ED demoed some NFT artwork that had been done recently. These were randomly generated onchain SVGs which will contain some information from the blockchain, such as the tiers and the cost of the NFTs.

Bnanapus NFT of onchain generated SVG

These NFTs were the default of Bananpus, so anyone can easily deploy staking solution for their project tokens and start routing rewards to it.

Contract wise, minting and redeeming from an ERC-20 payment terminal had been basically ready to deployed and used, but it would still need some front end efforts to help supporting this ERC-20 payment terminal in the UI.

This would be our first scoped use case of an ERC-20 terminal, Jango suggested that we probably should consider working together to integrate the JB ERC-20 Terminal to one project (Bananapus) first, and testing if it would be working as expected, before adding it to the create flow and making it available to all project creators. After that, we could also have a project deployer contract where it just easily deploys a full-fledged project that has a staking solution baked in, so as to narrow all the parameters of creating a project down to just what's needed to run the staking stuff.

Buyback Delegate Updates by Jango

Jango extended huge shoutouts to Dr.Gorilla for cleaning up the codes after the Code4rena audit contest, and to Viraz for writing some of the final tests to solve really edge cases.

There were a few deficiencies that the contract crew had been pushing towards, generally making this class of payment delegates easier to use. It would be much easier if the data source has access to pass information to the delegates it calls, so the team lately had been sprinting to put up a payment terminal version 3.1.1. They were at the final stage of wrapping that up and putting it on Goerli before running some tests again.

As buyback delegate is a core function of how tokens will work, Jango thought it was worth being more careful about those deficiencies and with the experience in developing it so far making sure that this piece of code would be cleaner for folks to understand and build similar things.

Also in exploring the treasury design models of Croptop or Defifa, which will be both unowned projects and won't have outward payouts, but instead making use of redemption mechanism more heavily, as redemption rate can be deemed as a small tax on redeeming token owners and also leads to outflow of funds from the ecosystem, Jango was thinking the legitimacy of charging same 2.5% Juicebox fees for redemption oriented projects similar to Croptop or Defifa when they are setting a redemptioin rate lower than 100%, and piping those fees through this buyback delegate.

LJ had been working together with Filipv on a legal template website, where basically will have a template library to curate some legal templates after they are reviewed and audited by a law firm.

Also they want to make this a more collaborative effort, so they would create a GitHub repo where people can make a PR if they want to submit a template. After these templates are reviewed and approved by a certain committee, they will be published on the GitHub repo as well as on the template website, so that people who do not know how to navigate around GitHub can go there and download the templates they need to use.

Some project creators who may not know what kind of templates they need, can go to the site and check in the different categories, such as employment contracts and investment contract. Currently what they have are mostly commercial and company-to-company contracts, later they would want to provide more formats such as those for freelancers and folks who work in workshops, such as advisor agreement or service agreement.

The legal structures in the tradition world, like those regarding legal wrapper that helps DAOs to create a set of entity depending on different needs in different jurisdictions, will be their next step after this template space is successfully established.

LJ also said that it would be even more cool to have a coded contract that can enforce the legal temples, which will be also on their horizon so that they not only have paper contracts but also a smart contract which will be able to collaborate or sync with the legal contracts.

Croptop Template Updates by Jango

There was a new Mac App released for Croptop available right now. Go to and follow the instructions there to try the "Self-serve personal websites accessible from .eth addresses, with content feeds and revenue streams baked in".

instructions to make use of croptop

There's a Goerli version of the Croptop Publishing Network, which is the master network project taking fees from folks who minted on sites that they forked.

And owners of .eth websites can create their corresponding Juicebox project by clicking the "fork" button on any sites created with a Croptop template, and then give permission to the croptop contract to mint to their Juicebox project on their behalf. They can also set the parameters under what conditions NFTs can be posted on to their projects.

Defifa Updates by Jango

During the town hall, Jango shared some exciting developments about Defifa, which is more focused on treasury management, specifically regarding a redemption oriented treasury. He had been exploring ways to handle it in a legally and accounting compliant manner, which has sparked curiosity and puzzle-solving discussions with some trusted legal experts.

Jango was excited about the implementing this concept in Defifa and Croptop, while ensuring it's defensible and by the book. If it proves to be successful, we would share the experience with our community, as well as projects like Blunt which are running more open-ended treasuries. We would always have the option to inch closer to something more automated, but for now we would be playing with these ideas.

In the meantime, Aeolian and Kmac had been working on some very exciting front end enhancements, and Filipv had done a fantastic job improving the how-to guide for Defifa and Blunt, making it easier for users to understand. Please visit to explore the current state of our prototype.

new homepage of

Both Croptop and Defifa requires a buyback delegate, which itself relies on the payment terminal as a pre-requisite. Our focus right now was to ensure getting those out the door, once those are in place, we can expect a lot of similar projects going to be created.

Use Case Video by Matthew and Brileigh

Matthew and Brileigh had released their second Juicebox use case video for charities and non-profit the same day of this town hall. And for next one, they were planning to make another Juicebox use case video for open source softwares.

State of Crypto Philanthropy by Bruxa

Bruxa introduced that she was producing an event called Sate of Crypto Philanthropy for Endowment, which had really been a pleasure for her as it was involving so many people across the philanthropic crypto ecosystems, such as those from Coinbase, Art Blocks, Change Gallery, Blockchain Association, Circle, Givepact and etc.

Bruxa said hopefully she would create a really intriguing dialogue about things such as actionables,data and forecasting for the rest of the year. She would love to invite people who care about that to join the event, which she thought would be relevant to literally anyone building and also an good opportunity to ask questions.

Cover Image for State of Crypto Philanthropy Digital Summit

· 4 min read

Town Hall banner by Sage Kellyn

Peel Updates by Tjl

TJl gave a quick overview of some changes that Peel had made to the project pages recently, which had been a common effort of the whole team.

Some of the main changes were to highlight the key statistics of a project, arrange other details into various tabs such as Activity, About, NFTs, Cycles, Tokens etc. A short link straight to NFTs and Rewards had also been introduced for purpose of user's convenience.

new project page setup

One of the biggest changes they made was a cart structure for the NFTs, similar to our mental model of purchasing something in real life, users now can add multiple NFTs to the cart and make a lumpsum payment for their choices of NFTs.

NFT cart payment modal

There would be some really great upcoming features in the next two weeks, which include the ability for project owners to post updates about their projects directly on the project page, and also that for community members to engage in comments on these updates.

Also the 'About' section would soon have a makeover with addtion of rich markdown function, users would be able to add headings and different stylistic text changes, images and etc.

Juicy Picks Poll by Aeolian

Aeolian made a poll in the Discussion channel of our Discord server, to let community members elect which projects should be put on the Juicy picks section on our homepage.

Juicy Picks Poll

Here under was the current layout of Juicy Picks, which would be rearranged according to the poll results above.

current Juicy picks

ETH Shanghai Meetup Updates by LJ

According to LJ, his plan to host workshops with other DAOs during ETH Shanghai would have to be cancelled, due to the fact that for some reason ETH Shanghai had essentially moved all the activities of this event online.

But expecting some people would still go to Shanghai in that period of time, he was planning to host a more casual meetup such as a IRL Juicebox happy hour by then.

Also LJ announced that he had been working with Filipv on some legal templates that will be provided to project creators to create their legal entities. They had been working on setting up a website where people can download a template and sign with their crypto wallet, and also building a GitHub repository where people can submit a template through PR and other people will review and accept the template if it turns out to be useful.

Speech at ETH Waterloo by Nicholas

Nicholas would be giving a talk at ETH Waterloo on June 23rd about the token resolver, Juicebox protocol metadata contracts. He also planned to talk about how the contracts work, introduce the concept of Juicebox cards as a very cool application enabled with onchain metadata, and share some of the template contracts that people can easily fork and write their own metadata.

Nance Updates by Nicholas

Nicholas introduced that lately the Nance team had been making lots of improvements to, our custom website for governance.

One of new features is the “Fork Proposal", which allows people to literally fork an arbitrary proposal and make a similar one very conveniently.

jbdao fork proposal

And another feature was to allow authors of proposal to add actions for a certain proposal, with the onchain transactions or reconfiguration parameters, etc. which are supposed to happen on the blockchain once the proposal is approved. These are structured data parameters that will show up at the top of a proposal, and in the future iteration of Nance, these actions will be propogated into a new interface where people can reconfigure a project directly without needing extra efforts to manually construct a reconfiguration, and in turn lowering the risks of errors might be incurred.

add an action in a proposal

· 6 min read

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

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

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, 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. 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

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

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 should be compatible with, 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

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

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.


  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.


app framework suggestions


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.


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


What Tjl saw as the opportunities of take this initiative:


What do we need to make this work?

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

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

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

  • And cooperation from existing JB-funded projects.

  • And Contract crew development support

  • Documentation from Filip.

Discussions On App Framework

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

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

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

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

NIcholas: To get that process started, it would be interesting to have a single front end which is compatible with separate work streams, updateing them at the same time. If Blunt is something that can be executed inside of an optional add-on tab instead of a project, then a handful of devs, internal or external, Peel or non-Peel, can start working on that. And it can be integrated into 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.