The JBX V3 migration is on the final finish line. Jango has moved some of his tokens into a vault to test stuff out.
We are just wrapping up a very clean and safe UX for the migration purpose. Next week we will have more to announce together with the actual instructions to migrate tokens. Huge ups to the versioning efforts, and shoutout to Aeolian for his great effort in putting all this togerther.
Peel is working to enhance the functionality of our juicebox.money homepage by placing greater emphasis on project creators, and by making it easier for users to discover relevant projects in different categories.
They have redesigned the main navigation bar, reducing it to three items with subcategories, placing greater emphasis on the "create a project" function and simplifying options on the right-hand side.
Peri's project tags will be prominently displayed at the top, significantly enhancing discoverability of relevant projects.
In the central section, they have incorporated project cards that will showcase trending projects.
They are also planning to feature a 'Success Stories' section that will showcase case studies of previous projects. Rather than linking directly to the projects, this section is likely to provide information about the successes of each project. The team may use Filipviz's excellent work on case studies for this purpose.
And an area for docs:
Additionally, they plan to introduce a new section called 'Juicy Picks', which will feature the most popular projects as voted on by the community on a monthly basis through polls hosted on Discord. These results will be displayed on the website using an exclusive project tag named "Juicy Picks".
Lastly, we will have exploration section by categories:
Peel is currently completing updates to several pages on the website, including the home page, the About page, and the DAO page. They plan to unveil these changes over the course of next week.
In addition to these updates, they will be revamping the project page to better cater to contributors and project creators. They will be rethinking the design from the ground up to display more relevant information and attract more contributions.
Previously, the project NFTs representing ownership of projects on Juicebox had no metadata. However, Nicholas has recently developed a TokenUriResolver that provides dynamic and customizable metadata for Juicebox's project NFTs.
This token resolver comes with several features, including the ability to view live project stats in an on-chain-generated SVG, customize colors for a project's metadata, and use a custom metadata resolver contract to replace the default entirely.
For more information on how this token resolver works, you can check out the documentation here.
StudioDAO plans to sign a contract between StudioDAO Backlot LLC and Tiket to Space LLC to establish an investment relationship and downstream revenue stream for both the DAO and Backlot.
Meanwhile, production for the Ticket to Space film has recently begun, with Fernando, the director, and Pablo attending a Blue Origin event in Orlando. There, they obtained behind-the-scenes footage and interviewed several executives about the prospect of sending someone from China on a Blue Origin spaceflight.
STVG has launched an open funding round for Juicebox on Prop House, inviting anyone to propose ideas that they believe will benefit the creator ecosystem using a Juicebox programmable treasury. Once submissions are closed, JBX holders will vote on the proposals, and the top three will be awarded 0.3 ETH each in funding.
In mid-April, they plan to launch a competition for the NBA playoffs, along with a create flow that enables anyone to design their own tournament game. Mieos and Sage are developing exciting ideas for the NBA competition, including the use of canned beverage artwork to represent each NBA team.
Presently, when DAO contributors are deploying Juicebox contracts, distributing JuiceboxDAO payouts, and distributing reserved JBX tokens, they have to pay the gas fees incurred in these transactions on their personal account first and apply for reimbursement from the DAO with individual proposals.
Filipviz recently submitted a proposal to authorize the reimbursements of these payments by the DAO's multisig, and this proposal has been approved by the DAO earlier. But fetching all those transactions and the addresses executed them and organizing the reimbursement details before queuing the transaction manually can be a very annoying and backbreaking work.
So Filipviz developed a Node.js application caledl Juicy-reimburser to help facilitating this task. With this tool, user can specify a Gnosis Safe or any Juicebox project and a time range, it will grab all the relevant transactions from them and build them into two files, one being a JSON file for Gnosis Safe Transaction Builder and the other one a regular CSV file. Users can use these files to execute transactions to reimburse those gas fee with a Gnosis Safe or some APP like the Disperse.
On the town hall, Filipviz demontrated how to build these files with Juicy-reimburser and use the JSON file to queue a transaction on a Gnosis Safe multisig.
Felixander came to our town hall and shared some of his thoughts and plans about a project temporarily named as EduDAO, and wanted to get some feedback from our community regarding the governance models of this project.
The concept of this project is to ultimately create a network of schools that shares an open source curriculum that is blockchain oriented and allows anybody to create a school and make use of the curriculum. And this is also done in an attempt to make changes to the education system and the accreditation system, which in Felixander's view had been broken for quite some time.
According to Felixander, there will be 3 phases to accomplish the high level goal of this concept.
Setting up a tech lab in a public school. This something Felixander had managed to accomplish by coming into agreement with some school in Los Angeles, the 2nd largest school district in U.S. The tech labs are meant to teach technology and innovation.
The next phase will be create some kind of after-school program.
At the last stage, it would evolve into a full blown school.
Felixander expected that it might take about one and a half to two years to ride through these three levels, with all the necessary funding and support in place.
He thought that it would be more appropriate that the EduDAO doesn't directly manage or get involved with the funds, but to focus on the development and curation of curriculum instead. And he's trying to figure out a tokenomic system where educators who are putting more efforts into this DAO will have more decision making power.
In terms of the targets of EduDAO, although Felixander has mapped out from K to 8th grade, but the plan would be a full school system covering K through 12th grade. He also introduced some expected results of students from this education system by giving a rough example about an 8th grade might be able to do.
STVG is currently also working with GeniiDAO, which has a plan to set up a project on Juicebox, on something to a similiar effect. They are discussing about some ideas of DE-SCHOOLING and open source curriculum resources. They thought maybe they might to able to share thoughts and work in collaboration with Felixander in this respect.
ComicsDAO recently started an open edition NFT mint of Nouns Comics #1 Generative Cover, at the time when they are about to publish the physical comic book for Nouns DAO, and all the proceeds from this sale will be used to purchase physical comic books which will be donated to children's hospitals in North America.
We are adding a new data structure to projects which allows project owners to tag their projects with up to 3 tags from a list of 10 different pre-set tags available. This will open up some possibilities for actually discovering projects in Juicebox.
Right now, the search function on our "Explore projects" page is quite simple, supporting searches only by project handles. We have recently overhauled the search function using Sopana, so that the searching experience will be greatly improved, especially when we have tags in place as well.
We'll be able to highlight projects in certain categories across the APP, so as to make it a lot easier for people to create projects on Juicebox and get them exposed to their potential supporters.
Last week we shipped the function to support editting user's profiles, where people can add their profile picture, bio, Twitter handle, website and etc.
Another useful function that we are going to integrate is the association between email address and wallet address of the users. This function, which will hopefully be shipped within this week, supports the event notification of projects, so that if someone pays a project, they will be able to receive notifications of any future "pay events" happen in that project.
All new projects will be created with JB3.1 contracts. And NFTs will be deployed with new NFT contracts, which will also support NFT collection category and royalties, the two functions yet to be exposed in the Juicebox.money front end in the near future.
Also Aeolian will be coordinating with the contract crew and some other contributors to work on the token migration process, where eventually we will need to migrate all the tokens from V1 JBX to V3 JBX.
At the beginning of February, when WAGMI Studios renewed its recurring payout, their proposal was not approved by the DAO. But due to some following bookkeeping error, they were mistakenly paid according to their last approved proposal for another two cycles.
Both for a purpose of crowdfunding to return the funds back to the DAO, and for a purpose of experimenting an open edtion NFT mint with Sage Kellyn's new artwork, they set up a Juicebox project called Cosmic Bake Sale.
The Peel team has been working on a brand refresh project recently, in collaboration with WAGMI Studios and others. Today they have collaboratively designed and shipped the new brand and our juicebox.money website.
We should shout out to Strath for leading this effort, to Sage for the incredible illustrations, and to the rest of the team, especially JohnnyD and Aeolian. All of them has done an amazing job together. This is absolutely a tremendous effort from the entire team. It was only two weeks ago that we started to discuss and work together on this direction. Then in this period of time, the team managed to define the direction, collaborate with WAGMI Studios, make the entire brand refresh, get it approved by the DAO and finally publish it on our website.
Hopefully we will get some comments and feedback from the community around the new brand refresh.
Not just the home page, literally the whole APP is taking on a very different look, in areas such as create flow, project discovery, project pages, etc.
Not only have they shipped the brand refresh on the website, but they have also been very busy working with some other features that will be shipped soon.
Profile settings, wallet auth and email engine by Wraeth. He has done a really fantastic job of actually linking the user's profile pages to their wallets. Now users can connect their wallets and then essentially personalize their profile, where users' email address can be added and in turn be used to kick off some product-based email marketing at some stage later on.
Project tags. This is a feature that Peri has been working on lately, which will enable us to tag different types of projects such as Art, NFTs, Games, and so on.
Leaderboard and announcement notifications. Products also developed by Peri. The headboard is going to be visible in the new footer on the homepage, while the annoucement notifications on the top right with messages letting users be informed with the updates in our ecosystem.
JBController3.1 and JBETHPaymentTerminal3.1 support by Aeolian. After the Multisig signing a transaction for the migration of these components , the front end support of these new versions of contracts is currently at a testing stage and will ready to go very soon. Also as result to this upgrade, the gas fees of NFT deployment in Juicebox protocol will be lowered dramatically, thanks to the efforts of our contract crew.
During the past few days, there has been some hefty gas spikes, moments when the protocol felt very unusable, which is something we have always known to be true, it's the trade-off the Ethereum Mainnet.
Just like we'll figure out how to operate organizations with independent treasuries on mainnet, it has in some sense been an open question revisited over the past couple of years that we may need to have separate treasuries and memberships across different chains. This question is now being heavily discussed in the thread of # Juice Distributor under the Protocol channel.
Essentially in the next stage, we will try to run a new treasury on a L2 network, to experiment with a few different things and attempt to take on a strategy that won't overburden Juicebox or the organization that runs on this treasury right now.
Over the past while, we have noticed the tax that it takes to do versioning and migration work on the core treasury. Even if expansion in other L2s is something that JuiceboxDAO might want to adopt in the near future, it makes sense to de-risk by running a separate treasury with its own incentive structures which is related to JuiceboxDAO through the regular Juicebox treasury components.
Jango wrote a blog post to summarize his string of thoughts about this matter derived from the recent discussions. There's not much specifics at the moment, but he hopes that he will be able to share them on a more regular basis, when they are available in the near future.
If people prefer their own image setup, they can also go to the token resolver contract, which is like a main registry contract. Project owners can set their own token resolver, which will entirely generate image with whatever contract they want, on the condition that a few codes of solidity will be needed.
The setup is very nice because the token resolver contract points to the default token resolver contract, in which case we will be able to change what a default resolver looks like, to add metadata or to improve other details, without overwriting what has been made by the project owners with their own token resolver.
ComicsDAO x Juicebox Art Reveal by Nicholas, Sage and Gogo
Here is the artwork delivered with the efforts of WAGMI Studios and Nicholas. It will be submitted to ComicsDAO and printed on the first edition comic book of Nouns DAO.
Through the QR code on the bottom, people will be linked to a Juicebox project and can mint a limited edition NFT of this artwork. The proceeds from this NFT sale will be split between WAGMI Studios (50%), ComicsDAO (25%) and JuiceboxDAO (25%), which is also a good way to showcase the distribution mechanism of Juicebox protocol.
This artwork went through a lot of different iterations, they came to an agreement that we should try and create some Sage Kellyn art that brings the Juicebox and Nouns communities together through a fun scenario. And NIchilas thought that we had learned a lot about the creative process of doing a more involved illustration, hopefully some of that experience can be taken forward into future projects.
In the process of deciding which Nouns characters to include in this image, Nicholas suggested that we choose those Nouns whose owners are active and relatively more influential on social media or Twitter, so that they will be more emotionally involved in this artwork.
At the request of Nicholas, Jonathan Mann aka the SongADay man, made a song all about Juicebox.
Like all the other songs he produced, this song was put on auction as a NFT on the website of SongADAO here. So Nicholas created a Juicebox project to crowdfund and use the raised funds to successfully bid the NFT, which in turn was transferred to the multisig of JuiceboxDAO.
Nicholas also thinks it extremely interesting way for an independent musician to fund a whole NFT DAO platform, and the mechanics they are using might also be informative for Juicebox projects.
Over the last couple of weeks, we've been talking a lot about the Juicebox brand, moving into some new audiences and really building the trust with them. We've come to a conclusion that if we want to grow, build trust with new audiences and get bigger project etc., we will need to think of building a brand that is more aligned with those audiences and can be perceived as trustworthy and super top tiered.
The goal for this brand refresh: Give Juicebox a refreshed look, while paying tribute to our creative and unique origins. Make Juicebox feel easier, more familiar and more enjoyable to use. Creating a strong brand presence and building trust among new audiences and verticals.
The No.1 thing that we want to be is trustworthy because people are exchanging a lot of money here in Juicebox, but we also want to bring the fun, cheeky human element into it, especially with this brand refresh to keep it clean while still having that bold and cheeky Juicebox vibe that we all know and love.
For the logo, we are giving Juice a fresh, clean and unique feel while keeping true to our roots.
Thanks to Sage, the current logo has been serving us really really well. And the refreshed logo is quite similar to the old one, basically just taking what we had and making it able to be scaled, able to be used on different color backgrounds, pair a little bit better with different fonts, etc. We're just tidying it up a little so that we can use it across a broader range of use cases.
As we don't have an official logo lockup yet, what we've come up with is like this:
A comparison to other industry standard branding. It sits really well next to some of these tech companies, but still holds its own unique and interesting feel.
This is obviously very important for us. Strath wanted to go with something that really fits Juicebox, inspired by tropical and good times. The new Juicebox color palette conveys our playful nature while building trust and setting us aside from the crowd.
There has been a lot of contention around this topic. Obviously it will be a very big choice to shift from DM Mono, which we have been using all along and has served us very well. But it's absolutely time to move to a new typeface.
Agrandir is a contemporary sans serif that celebrates the beauty of being imperfect. It was designed to be a brave antipode to the nuetral modernist font. Agrandir accepts its own shapes as they are, unaligned, quirky and funky. It celebrates humanity, not machines.
Another thing that will obviously get refreshed as we go into the brand refresh. Our icons need to be fun, playful and modern, bringing the interface to life for informing the users. It's a fairly easy switch, but definitely makes a difference.
In a lot of the user interviews that Strath has done, people said they'd love to see more visual representations, because there're quite many reading and complex terms. He thought that we can use the illustrations to pair with the iconography to really bring some of that to life and make it easier to use.
With the help of Sage, we will be using the same sort of stuff we've had before, but bringing a little more or a playful, fun, funky vibe to it. Also having some fruits and interesting Web3 Juicebox related objects around throughout the experience will work very well.
This is where we create the super unique identity that nobody can copy.
There'll be a phased rollout. We will have a very structured plan of how we are going to phase the branding in, updating the type face, rolling out the new colors and then starting by slowly redesigning some of those UI elements. It will seamlessly migrates over to the refreshed brand.
Jango: Super sweet. Lots of work goes into this, big shoutouts for pulling it together end to end over all these time.
Strath: Really appreciate it. Though it only looks like just some new colors and stuff, a lot of research and work goes into coming up with the ideas and refining it all. It's not just some random choices as well, but very specific choices to move us into this direction.
Also big shoutouts to Tjl for some of insight into where we're heading and how we want to position ourselves, which was really helpful. And also to Sage and WAGMI team for bringing the vibes.
Jango: The thing that's going to really tie together for me will be those customized illustrations by WAGMI that define the edge and ride that line, which is how they serve in the current site. And there's definitely a version of those that fit really nicely with this aesthetic. It still pulls towards that edge and that line which set the tone for use.
I think the last piece of feedback I have for the broader group is that the current juicebox.money in some sense rides this line somewhat awkwardly, between the more dev-oriented aesthetic with mono font and maybe data forward, and the fun aesthetic that this version pulls more heavily towards.
It's kind of an awkward pilgrim to seeing that you will go and bring JBM in this direction. I think it's necessary to really explore in earnest what this means and there will be a massive audience that feels home and comfortable here. But it will leave that opportunity for the other client or other kind of aesthetic to maybe find some foothold within more of a developer community or something like that. That's totally ok.
I think both of the things can, and maybe even should, exist at the same time, but it's just awkward to try to do them both at the same time in the same interface. So we are going to double down here and give this our go.
But I also want to acknowledge that the alternative side, which is more computer, more mono and more straight to the point, is still valid and may have some visibility at some point. And it's going to be really really cool. I think both can borrow a lot from each other while also catering towards specifi audiences, specific tool sets, etc. But from a perspective of project owner and payer, I think this is such an exciting direction to try.
Strath: For sure. There could be the more developer-esque side of things, but I think as we move more into growth, having something that both sets of users can use and enjoy in going to be really crucial for that.
Peri: Thanks, Strath. There has been a ton of work into this and it's looking great. Thanks for such a thorough presentation and a breakdown of everything. Echoing Jango's sentiment here, I think it definitely makes sense right now to be optimizing for what we try to improve. I think everyting that you've done is going to make the site look a lot more approachable to people who come to the current site and feel that it's a little overwhelming or not meant for them for one reason or another. This is going to serve those people really well.
If there's a future version of the UI that is much more dev-oriented, I could totally see a home for that. But I like where our priorities are right now, and I think we are making good progress towards it.
Ticket to Space Juicecast Episode by Matthew and Brileigh
Matthew and Brileigh just released a new episode of Juicecast about the Ticke to Space documentary of MoonDAO.
MoonDAO last year held a contest of randomly drawing a winner of its Ticket to Space free mint NFTs, the winner will be sent to space on a Blue Origin flight. A MoonDAO member from Beijing won this contest and is going to be sent into space. There will be a documentary made about the journey of this winner, and the film is going to be made via StudioDAO.
Matthew and Brileigh recently had a conversation with Kenny and Rachel from StudioDAO, and the two filmmakers, Susie and Fernando, as well as Pablo, one of the founders of MoonDAO. They had a roundtable discussion about this Ticket to Space documentary, which will be the first one ever being made about a DAO.
Also StudioDAO is going to launch a Juicebox project to support this effort, and people will be able to buy a Ticket to Space NFT to sponsor the production of this film.
The Krause House 50pt Game Charity Bounty is a Juicebox project created by Acidicsantana. This project is crowdfunding and offering its treasury to a NBA player who scores more than 50 point in one single game. The eligible player can unlock the funds in this Juicebox treasury and have them sent to a charity of his choice, by interacting with this fandom project as outlined in the project description.
Nicholas is very interested in the overall mechanics and he thinks there are couple of takeaways that are worth thinking about for future projects.
First of all, it's a bounty. People are fundraising for a bounty, with an explicit goal stated upfront and its mechanics made clear in the project description. Nicholas thinks that it will be more interesting for people building projects or helping people build projects to take a little more inspiration from what works for traditional fundraisings in Kickstarter.
But even more than that, when the project reaches certain goals of fundraising, it will unlock other things such as raffling off an NFT randomly to a lucky contributor. This is getting closer to what really works for Kickstarter, which is the benefits for donors.
And Nicholas thinks that cumulative sum of the treasury unlocking other features or actions can also be motivating to get people to donate and participate. In the case of this project, a fandom is collecting their funds until they have enough money to attract the attention of somebody more influential and has more reach on social media.
There are some elements of this project that are worth repeating in future projects. And he encouraged folks to take a closer look at this project.
Tjl presented a roadmap for Peel and juicebox.money last week on our town hall.
He thinks Peel is making quite an effort to move towards our goal in a project-based working style, while giving clarity of where they are along the way, just like they did in the brand refresh presentation today.
The roadmap they build now lives in Linear, anyone who wants to keep track of the project management can apply for an invitation. This will help a few folks, like WAGMI team, Brileigh and Matthew to work in coordination to make some marketing materials so that we can have a deeper connection and relationship with end users and our community members by giving them updates about the progress of this roadmap.
Tjl was doing a roadmap presentation on the town hall, which is realistically a guiding force for those in Peel so that they can make progress and track against it and work towards a unified vision and goal.
The full version of this document can be found here.
As a very high level context, this product framework by tjl has been pulled together through a series of workshops, some front end analytics, on-chain and off-chain analytics, as well as the user testing and interviews by Strath. Thanks for all the efforts by everybody involved, which has been the premise of building all of this.
According to this roadmap, which is supposed to be with a trickle-down effect, we will start from the top of the vision to enable creators of tomorrow to launch, fund and manage the boldest projects on the internet.
We are on a mission, there are some of the numbers we're looking to work towards. Even if we only achieve 10% of those, that will an absolute win for us.
Some of the product goals:
Create the easiest way to get your thing funded online;
Encourage everyday dreamers to launch their thing and make it successful;
Create the world's largest network of contributors;
Connect contributors to projects;
Make it simple and straightforward to contribute to projects;
Introduce the benefits of transparent funding to the corporate world;
Create much trustworthy and reliable Web3 platform.
Some values we're working towards are trust, transparency, reliability, fun and exciting, community driven and customization and control.
Refreshing the brand to commuicate to a wider audience.
Phase 2: Engaging users.
There are a couple of different features here, such as introducing profiles and linked email communication.
Shoult out to Filipv, Mathew and Brileigh for their previous effort in the area of product marketing.
Phase 3: Expanding verticals.
Breaking into and expanding our reach so that we can capture new parts of the market.
Phase 4: Optimizing the reach
Overhauling the project display and discoverability features to increase contribution participation and expose us to new opportunities.
Phase 5: Increasing engagement
We worked really well at the early part of the user journey, which is launching and getting the project funded. But, there's so much to do after that, where Nance and a few others have been doing some great work, to expand the juicebox.money engagement through and post the early stages of the user journey.
Phase 6: Supporting and serving
Trying to introduce new support services.
Phase 7: Expansion of large-scale experiments
The items in this graph are pretty much categorized into the above phases, with some milestones in between. We have given these objective quite conservative estimations, so very likely these will be happening a lot sooner.
Firstly there will be the brand refresh, launching a beta program, making some updates to the website, and including case studies on the website.
We're going to jump into project page, make a small refresh on the project page, get into the user profile setup.
Then we will be moving back in the create flow and expanding the capabilities,
Next will be some features around project discoverability:
giving project updates, making it possible to discuss on project pages;
ability to message project owners;
project discoveratbility platform;
ability to watch projects and subscribe to them;
revamping the setting.
At the 6 Month Milestone, we will be looking to increase the engagement features, such as proposal creation and voting, project verification, etc.
The phase after that will be all about the reliability, introducing platform status features, developer elements, diversified payments, and so on.
When asked by Filipv when will we sunset V1 protocol, Aeolian explained that the only real delay in the V1 sunsetting right now is the availability of the token migration to let V1 projects migrate their tokens to V3, which will be coming in the next couple of days. Once that's done, we can probably broadcast the end of V1. He also thought that we would always maintain read support for V1 projects so that folks will be able to visit the original Juicebox project and ConstitutionDAO project. We're just going to probably remove all the edit functionality from it, but if V1 projects do need to edit their projects later on, we can look at making some V1 sites available later on.
The day before this town hall, some contributors from WAGMI Studios and Peel had a very good call to discuss about the branding efforts, which is the first project on the roadmap, in order to refresh the identity to expose us to new opportunities.
They came to agreement and essentially approved the branding brief. In two weeks' time, we'll have a very solid foundation for a new brand to be shipped.
Cover image. Projects can now add a cover image on the top of their project page.
A tutorial of adding cover image made by Matthew and Brileigh:
Project page tabs. The infomation of projects such as funding cycles, payouts etc. will be neatly displayed in different tabs, instead of cluttering together in one place.
ENS avatars. We will show ENS avatars next to the addresses in the activity feed of the project.
Personal profile page. Every user will have a profile page of their own, showing the Juicebox projects that they contributed or created, and the activity feed of this particular address is yet to come later.
MP4 NFTs. Now Juicebox will support using video files to deploy NFTs.
The tutorial of deploying video NFTs made by Matthew and Brileigh:
In our current create flow, funding target and payouts are two separate steps where they have to be set individually. But as the funding target of a Juicebox project is actually the distribution limit of its certain funding cycle, which is also euqal to all the payouts added together, so we are now going to consolidate the two steps into one Payout tab.
In the new Payout tab, instead of setting a separate funding target, all you need to do is choose among the options of Limited, Unlimited or None.
Limited means the project will have a specific distribution limit, which is the total of all payouts added together.
Unlimited mean the project will have a infinite distribution limit, while all payout recipients will share by percentage splits.
None just literally means the project will have a distribution limit of zero, there will be no funds distributed out of the project.
Bruno is the founder of AgentHQ, which is his attempt to make building AI enabled tools easy and fun so that people who are non-technical can build tools that leverage different language models.
AgentHQ lets users build an AI agent in their browsers, and it also has a lot of built-in tools that the users can lean on, such as text summarization, text generation, interfacing with APIs, pulling and pushing data from APIs, even connecting to users' emails.
STVG created the AgentHQ Juicebox project and handed it over to Bruno, in a hope that Juicebox will be leveraged to support his effort in AgentHQ.
ComicsDAO is going to publish a printed comic book for Nouns DAO, and they are offering an Ad page for Juicebox for thanks for the support and help from JuiceboxDAO when ComicsDAO was launched.
With the efforts of Sage and Nicholas, we've come up with a page which Nicholas shared on the town hall to see if folks have any feedback on it.
The QR code on the image will link to a Juicebox project, where limited edition NFTs with this same artwork will be available for minting.
NIcholas thought that this would be an opportunity to speak to the Nouns audience, as well as to cross pollinate, as Nouns is playing in an overlapping space with Juicebox, both communities are actually compatible to explore more development possibilities.
You may also check the full version of this report by Jango here
Here are the changes made to the three malleable surface components of Juicebox projects:
Every project uses the same contract but accesses it via their project ID, and then every project gets to choose one of these canonical controller contracts to use. The controller contracts are stored in this contract called the JBDirectory, which you can ask what current controller a project is using and it will return the current address of the controller.
This controller has permissions to mint tokens on behalf of a project, burn tokens and keep track of a few other things. It also has exclusive access to do a few things in the fundingCycleStore and the tokenStore on behalf of every project.
The changes that we've made to the new controller, which project can choose to migrate later, are two reserved token oriented function interfaces, the reservedTokenBalanceOf and totalOutstandingTokensOf. This new version of controller won't be backwards compatible with old versions payment terminals, so projects that are going to implement migration will have to move both controller and terminal to their new verions. The same for new project creation.
Essentially it's just a very simple and small change, which just changed where the distribution limit of a project is accessed. Before, you access it directly in the controller withcontroller.distributionLimitOf, and the project would return what the distribution is set and properties such as which terminal it applies to, etc. Same with overflow allowance by overflowAllowanceOf. But now, these are accessed in a separate store called fundAccessConstraintStore which fixes the problem that we experienced with payouts when we did the first patch migration.
And then there are some changes to how reserved token balances are accessed. The amount of reserved tokens outstanding is no longer a function of the current reserved rate, as now reserved tokens get tracked automatically when payments come in. You can just get from the new controller the reserved token balance of a particular project ID, and it will give you the full amount. The same with totalOutstandingTokensOf.
These are all very small and very inconsequential changes made to the controller, if you are not depending on this original interface explicitly. But if you are, you will need to figure out how to connect with these updated APIs.
You can think about the payment terminal as where funds are stored. It accepts new payments on behalf the project, allows token holders to redeem tokens to get their share of fund, and allows anyone to trigger the distribute transaction of funds.
Payment terminal is changing very slightly but meaningfully. As we had to publish a new terminal to be compatible with the new controller, in so doing we are also fixing the problem that we noticed a few funding cycle ago, when we tried to pay a grant to Defifa project which had its payment terminal paused, the entire transaction of distribution got reverted.
What we did was to wrap a functionality to catch that error coming back from trying to pay a project or an allocator and dump the funds back into the paying project's terminal, so that other payouts in that transaction still go out and any reverted ones will be negated. Then we emit events so that subgraphs can check if there is any reversion happening.
Another change in the payment terminal is of the addToBalanceOf call, which used to automatically bypass minting tokens when funds are injected into project's treasury by calling this function. We have been refunding any held fees by this call. If projects chose to hold fees when they were sending funds out of the ecosystem, they could deposit any amount distributed funds back in to release a proportionate fees back to the project.
Now the addToBalanceOf call will not do so automatically any more. There is a separate addToBalanceOf overloaded call that has a Boolean parameter requirement. If projects intend to refund any held fees, they have to pass that parameter as True in the transaction.
The distributePayoutsOf function used to emit a memo, which is kind of pointless since it is a public transaction. So we replace _memo with a _metadata parameter which allows callers to send their project ID in that first chunk of metadata, that way we can use events to attribute which projects are responsible for these value adding actions in the ecosystem.
distributePayoutsOf is important because it's the one where fees actually get accumulated and registered.
useAllowanceOf, we don't even expose this in the client yet, but we probably should consider doing some version, or at least alerting in the project page when there is an allowance in the contract, even though the UI doesn't facilitate it.
Its API is also changing to include the _metadata parameter alongside _memo. As this will only be called by the project owner, so it's usefull to keep the _memo there.
The tiered 721 delegate is an extension that projects can use for their NFTs.
There are some new properties in the create flow concerning NFT functionality:
Project owners now can specify a royalty rate and a royalty beneficiary. These get exposed in a standard way that some marketplaces listen to.
There are categories as well so project owners can add tiers that are organized by categories. They can get NFTs by particular category and start to create a new organizational traits around these tiers.
Project owners can also set the metadata of tiers after they have been made, without having to deploy a tokenURI resolver. They can just upload the encoded IPFS hash and then the metadata of NFTs will get uploaded and changed.
Obviously the NFT stuff also needs to correspond to the new controller and terminal, so new projects will use all these new contracts instead of the old ones.
Also, as the NFT deployment is now using a proxy deployer pattern, the cost of deploying an NFT contract will be much more cheaper than it used to be, which is a very big win.
Hopefully we're inching towards a more resilient place where there will be few risks that projects owners need to know about, and adding a few different opportunities for features along the way.
Ticket To Space is a documentary that StudioDAO will be partnering with MoonDAO to create to document a Ticket To Space winner's journey and story.
StudioDAO is about to launch a funding process for Ticket To Space, which Kenbot thinks a big win for MoonDAO, for Juicebox and for StudioDAO. He also thinks with a lot of creative energy that can be deployed through this effort from people such as Matthew and Brilleigh, Jango, Mieos and Aeolian etc., we will be in a good moment where some of the big corporate companies are working that well.
He is very interested in terms of how they can do some NFT drops, more in a form of open editions and potentially with some burn capabilities. He is going to make use of the functionalities of Juicebox V3 protocol and offer different tiers of NFTs to supporters.
On one hand, they will have some high end NFTs which will cost 50ETH or 10ETH each. For example, he is going to put up a proposal in Nouns DAO to get them buy the NFT of 50 ETH in exchange for a credit in the creation of this film. But on the other hand, there will also be the open edition ones that will be more bottoms-up driving force to engage hundred of thousands of people around the project.
Drip Box is a project that Mieos launched to try to sell some NFTs and comes with them some mystery boxes of merchandise.
People can mint the NFTs and go to another website and have their holdings verified so that they can leave their physical addresses to have the mystery boxes sent to them later. After the selling phase, with all the cost and proceeds deducted, the project treasury will be open to NFT holders to redeem their share, in a sense giving buyers some discount or refund. The logic is, more people buy the NFTs, the more the purchasing cost of merchandise and operational overhead will be spread out and lowered, and in turnthe leftover funds to be redeemed gets bigger.
Mieos thought he would need to figure out how to work on marketing and build some traction for this project, in order to scale it properly so that it would be possible to get bulk discounts on the merchandise.
And he has spent much time researching some best-in-class items for the mystery box, and this first NFT drop will becalled the bug-out bag, which is a collection of goods that people would want to have at any given time and comes as a pack people can grab and run out the door feeling well set up to encounter things in the world.
Also Mieos and Jango discussed about the possibility of offering some producer NFT to give some potential sponsors a choice to put their brands on the products.
Three week after the original JBX V3 contract was put up, we've put out the V3.0.1 JBController and migrated to it, which caused another bug in how payouts are distributed as we had scheduled that distribution from the previous V3 JBController.
So the impact is folks on the payouts won't get their distribution in this funding cycle, as we need to go through one transaction to swap the controller back to the old one, distribute the payouts and swap back to the new one again. This process is outlined in this proposal, which is currently up for voting. If this proposal is approved, we can mitigate this bug and fulfill the distribution of payouts within the next governance cycle.
And our next steps are to fix a few other things that we've noticed over the past several months. One of them is when you are trying to make a payment from one project to another project which is paused, the whole transaction will revert.
We're looking forward to this kind of more permanent migration verion, which is also in the abovementioned proposal, it should take effect in the next few weeks if the proposal is approved. If it all goes well, at that point we'll have actually done migrations in the system to the extent possible. Although it has added complexity and bugs in the meantime, but given the current state of things and the product in the pressure, it's actually nice having this dogfooding process go through.
Shoutouts to contract crew for helping out in the past week really focusing on making sure this migration stuff goes well, to the frontend team for dealing with the controller routing and soon-to-be terminal routing so that projects can make use of the best and most reliable versions going forward.
Next few weeks hopfully we'll see new versions. There's very little risks in the system for what were exposed, which are very well known and articulated, but the versioning is really just to reduce the risks for future projects that maybe will be running without us or without knowing they ever existed, and may not look through the documentation as closely as we would recommend.
It has been a while since last time Peel gave an update on Nov. 15, 2022.
Aeolian started by acknowledging some of the growing pains we've had recently, when we had a few reasonably critical bugs pop up over the last few weeks. Although these bug got squashed quickly, we've recognized the need to definitely improve on this font.
A lot of versioning stuff is being worked, as certain parts of the App were revealed to be in need of improvement, which is a good segue into versioning. As a lot of stuff goes into versioning, there are also a lot of different parts of the UI that need to evolve to support multiple versions of these particular contracts.
Great progress is being made, with a UI coming up soon for other projects to upgrade to new versions of controller and ETH payment terminal, after which point other projects should be able to start their token migration process as well.
Also there are some exciting new fuctionalities available with the efforts of Peel:
Video NFTs. This will be shipped at the end of this week. Projects will be able to deploy NFTs with MP4s;
Multi-selection of NFTs. People can now select multiple NFTs before they want to mint, this feather was pioneered by folks in the Defifa project;
Diff view in project's Safe page on Juicebox.money. Multisig members can go there, review transactions and compare the difference before signing them;
Search feature is also coming along, and Peri has been working on that. This is really another big pivotal change in the APP that has a lot of moving parts, so Peel team wants to take the steps slowing so that they can iron out the details before putting out in the wild.
Also Aeolian reminded us to keep looking out for the changes made to the create flow, because projection creation is always evolving and iterating with new feedbacks.
Recently Nicholas has been cleaning up some stuff for the token resolver, and Jango needed an on-chain SVG solution for spinning up SVG metadata for Defifa, so Nicholas created a repository of SVG template which might be helpful to other people as well.
On the town hall, Nicholas did a demo of using this template to generate an SVG. Other users can make changes in the SVG.sol to write their own SVGs. People can use this template to make their own on-chain SVG metadata for NFT rewards, project, or whatever they are interested in, and it comes with the Juicebox contracts built-in.
And then in the project-handle branch of this repository, people can call a slightly more complicated test to load Juicebox project handles in the SVGs.
Jango had been playing with this template this week. He wanted to make it an auto generating terminal for Defifa NFTs, so that anyone can use and create their own tournament. We can start showing data on the NFTs and customizing it with Peri's on-chain fonts. He thought that it is a very cool and useful tool, especially on a data heavy protocol as Juicebox, quickly visualizing data on the NFTs will be a great default for many projects.
Nicholas added that it will be also really cool for NFT projects to be able to have their token metadata directly served from blockchains, so that if Juicebox.money or whatever stops pinning their IPFS, the NFTs won't disappear. It will also be super cool for projects that want to be more autonomous or founders that want to keep their anonymity.
Last week Filipv reported and shared some things in our announcements channel, about a former JuiceboxDAO contributor, tankbottoms. Last week some people on the MovementDAO multisig contacted Filipv to say that they had discovered that Tankbottoms was convicted of fraud in 2010 with a number of PDFs proving it. And he also exfiltrated millions of dollars from the MovementDAO multisig.
JuiceboxDAO has no connection with MovementDAO aside from some contributors work at both entities and MovementDAO forked some of open source code of Juicebox.
Taking a step back from this particular instance and reflecting on how as a DAO member sees with this proposal and contributor cadence that we're currently accustoming ourselves to, Jango wanted to reflect on what had happened and how it had happened, then to reflect on what we can be doing to learn from things in order to avoid things bad happen to us and to recognize things that going well and looking good.
Jango thought that he tends to over-index on being trusting and enabling to people, and open to whatever happens with a diversity of outcomes, not really with the strong opinion what these kinds of accompany and what happens along the way. This can be abused. He felt very disappointed at what had happened, reflecting on how he relates to that kind of enabling energy.
He thought enabling certain ideas or energies in some degree feels like enabling of things, which tends to be not good, but instead doing so can be hurtful and disabling to others who may have a different approach or different engagement with that energy. There's something to reflect on as a kind of loose social orientation observation, but valuable nonetheless.
He thought that people can behave very differently with one another 1:1 in a DM format. It's interesting to see how different perceptions can be made depending on which conversations you're having and how they're being approached.
Good communication is very important obviously. It's very important as a DAO. We can address and observe periods of miscommunication and reflect on their shadiness and how we might improve those, so that we're at least more consistently understanding the current context that we find ourselves in, so we can think about an approach to move forward.
The 7-cycle recurring payout term that we have developed precedents for does seem to limit risk, which is something to look back on and be happy about. In his perspective, that system somewhat evolved from the void of systems altogether in the beginning. Recurring payout proposals can cause moments of reflection that can lead to inflammation and more difficult conversation, which then puts pressure on contributor's expectations -- both social and technical -- and shifts leverage a bit more into JBX community's value set. This value set is always changing and hard to get right because there's no right or wrong and this is the product of the people that are around.
Contributor and JBX holder skepticism is really necessary to the DAO's health, but being the contributor that instigates the inflammation can be risky and hard to do. Jango thought that we should try to figure out how to allow skepticism to occur, to support it and to actually figure out forums or venues to make some certain things actionable. This can be taken in various degrees.
The DAO's values outlined in the Foundation that we confirmed a few governance cycles ago, does leave room for interpretation. A lot of it talks about finding balance between urgency and patience, what kind of things that make our process tick or of particular value. It's a good thing that we do have the room for interpretation. It's not clockwork rules that you either adhere to or break, but a great set of values to reflect on and really figure out what does pulling towards balance mean when stuff like last week happens.
A strong DAO immune system that minimizes bad risk and maximizes good risk over time takes attention and taste. Taste is a hard thing to get right, because we're an evolving community that has a Venn diagram of overlapping interests, tastes and tolerance. A lot of it does come down to the gut feeling or taste, and a lot of it technical, we have to be open and accepting of folks who are different from ourselves and may be providing new points of view. It's the balance, but it takes attention and taste, and we have to trust each other with the stuff we delegates to each other.
There exist specialized viruses which is just part of building the system that we're building in. It's an adversarial environment. There're also designed viruses to attach these systems and figure out how to ride that way. To some extent the risk mitigation that the DAO has already pronounced is pretty cool, but there's obviously work to do.
Developing an efficient and consistently sensible mechanism for moving JBX to productive workers and productive funders over time is a priority. It's a tricky thing. The buyback delegate will start, but that's something we talked about recently with the JBX strategy. There are more objective token things that we've already talked about and we're already aware of on the horizon from a technology and governance perspective. We'll hopefull have to take a consideration of the broader social environment that we exist in.
It's unfortunate to give a lot of chances or open space for something to exist, many times things blossom from that, but sometimes things just occupy that space and cause pressure to the actual fun beautiful things that are being worked on in blossom along side. The whole journey is just part of this dance and it's cool to be part of it, but it also takes these heavy amounts of reflection and actually feeling the consequences that can sometimes play against the general train of optimism towards actually creating cooler world of more open finance.
Aeolian: Thank you Jango, those are really good. One of these points you made has been on my mind and definitely on people's mind for a while, which is that being the contributor that instigates inflammation can be risky.
I don't know what the solution is. Folks who have pushed back on proposals know that it's very hard to do so from a number of levels, which is emotionally taxing having to be involved in proposal and takes time to do. Obviously the risky part is that suddenly you publicly state your disagreement with someone's payout essentially, which can be risky for yourself. But folks who are willing to put in that effort, passion and care to push back where is appropriate on proposals because it's obviously really important and probably would have gone some ways to preventing this scenario that we found ourselves in.
Filipv: I certainly agree. I think that's a great point. Not just in proposals, but also in everything we do as a DAO. There's a tendency to want to agree on everything, which is human nature in some ways. If you're in a small group, you depend on these other people's approval to get things done. It can be hard to disagree with people, but we all need to continuously remind ourselves because there's that natural bias.
It's okay to express our opinions and hopefully we can come towards the right anwers even if no individual has the perfect answer all the time. Hopefully we can more towards it on the aggregate.
OpenGSN is an open gas station network, it essentially allows you to make transactions without having to pay the gas for them. You don't actually perform the transaction yourself, you just sign a message, which gets sent to a decentralized network of relayers that in turn put it on the chain for you.
There are a few reasons why this would be useful.
To improve the UX for projects. When projects want to onboard new users, those new users need to create a wallet and maybe go through KYC procedures, before they can fill the wallet with ETH through onramp. Then they have to perform the actual transaction when they get confronted with the need to pick a gas price and go through the rest of the entire flow.
To incentivize users to perform certain actions, by projects paying the gas for them if they do this or that.
It's also useful to automate tasks that need to happen, so that contributors don't need to do it manually.
0xBA5ED made a demo of minting an NFT on Juicebox without needing to pay gas or make transaction himself. Here is the link to his experiment on Goerli testnet.
For people who may find this a bit scary, 0xBA5ED also added and option of "Mint with burner wallet", which would just create a burner wallet in the browser and then perform the transaction with it. Nothing need to be signed in this case.
This is a good example of how the distribute function on Juicebox could work. Currently the distribution of payouts on Juicebox projects need to be triggered by someone clicking the distribute button, and this person will have to pay the gas of this transaction and may or may not get refunded from the project treasury later on. By this "Mint with burner wallet", in theory someone can just click distribute, the browser will make a burner wallet, sign the transaction and send it to a relayer to put it on-chain, at the expense of the project treasury.
0xBA5ED wrote a pay master which allows owner to set which addresses are allowed, which contracts are allowed to be called, which methods allowed to be called, and also to deploy system contract to verify the calldata.
By doing this demo, he wanted to give us some idea about what openGSN is and how it could be useful in lowering or reducing onboarding barriers for Juicebox.
Lexicon Devils will be holding their next volume of Forming in collaboration with Emanate on Friday Dec. 17th.
There is another very exciting thing revealved in the Forming Juicebox project, an idea that Lexicon Devils have been toying with for a while. From this volume on, they are going to launch the new Forming Record Store NFT collectibles every month, which will be the personalized NFTs for each artist going to perform in the Forming event of that month. And as usual, all the artists on the event will be set as the beneficiaries of distribution, all the funds in Forming project treasury will be distributed to the artists after the event.
Matthew and Brileigh created a Banny Valentines project in collaboration with Sage, putting forth some Banny Valentine's Day NFTs.
If people want to buy one of these NFTs and have it sent to someone else, they can turn on the option of "Custom token beneficiary" in the pop-up payment window and put in the intended recipient's ENS or wallet address. After the payment is made, the NFT will end up in the hands of that recipient.
And we've just implemented a new functionality in the front end. If the custom token beneficiary is enabled at the time of payment, the caller and the token recipient of that transaction will be both shown in the project's activity feed.
The governance proposal to migrate JBController V3.1 has been passed. Big shoutouts to Dr.Gorilla, 0xBA5ED and Viraz for helping test and publish this latest version of JBController, which is used to fix some reserved rate accounting inefficiency that exposed during the JBX V3 deployment.
Once we have the transaction queued by Dr.Gorilla and checked by Jango to especially conduct this migration on JuiceboxDAO, we will verify and sign it. By then, we will have the first principle things out of the way with a process agreed upon by the DAO. There is some ambiguity in the proposal because we had some last minute building, so we published the contracts and got their official addresses after the proposal was passed.
It also brought up a few other things so that we may want to look preventatively towards controllers, where a problem was exposed a few cycles ago when the payouts distribution transaction reverted because one of payouts recipient, the Defifa project, had its treasury paused. So we will be doing a quick audit of other components that we may look towards versioning. These components will just be controllers and payment terminals, there will be nothing that requires funding cycles reconfiguration or tokens like last time.
After this, we will be at a really good spot afterwards and having basically done all the versioning paths that available to us going forward in case of other risks that we may find, which hopefully will be very very far and few in between. And versioning should be kept very slim, because they are risks themselves when introducing some new components.
Big thanks to Dr.Gorilla, especially for helping to lead this process to get JBController V3.1 out there, as well as the migration components.
For project owners, they will soon have an opportunity on Juicebox.money to migrate controllers, which is just the contract that mints token on their behalf, listens to payment terminal intructions, etc.
And new projects will be created using the new controller. We'll have the actual UI components on Juicebox.money probably next week, as Aeolian is focusing on that work this week. Big shoutouts to Aeolian and the whole Peel team for working with project owners to really make sure the expectations are correct for them. Also we'll follow up with the instructions both in the form of documentation and some quick tutorials that our content contributors might help to create.
Thanks for everyone for moving very fast, it feels like we will be at a better place because of it. Despite the dogfooding having caused a little glitch and had us introspect a little bit and go through the process to learn from it, Jango thought that we might be better on the other side.
Matthew and Brileigh have just created a new project named Banny Valentines, which is an experiment in collaboration with Sage.
This project has deployed a few NFTs of Valentine's Day cards so that people can mint and send them to their friends or loved ones. So it is meant to be a fund little project to spread the meme of Banny leading up to the Valentine's Day. Matthew and Brileigh have the plan to send them out to people tweeting about this project over the next few days before the Valentine's Day.
This project is also a very good demonstration of how to use the function of custom token beneficiary, so just enter another address when you are checking out with the NFTs and then these NFTs will end up in someone else's wallet.
Ticket to Space is a documentary that StudioDAO is going to produce for MoonDAO, which will also be a independent project in the network of StudioDAO. Kenbot said part of the launch strategy for Ticket to Space and the funding of it will be to run a series of interviews with filmmakers who are associated with this film, other filmmakers who are doing other space related content, MoonDAO contributors and also some real life scientists.
So they are thinking of partner up with Matthew and Brileigh to make a theme Juicecast series for a deep dive into the Ticket to Space Juicebox project. It seems to be a good place where they can combine forces, get helps from some other DAOs to get more distribution.
Matthew thought the idea with the Juicecast series would be like some thematic episodes leading up to the funding events. Ken said as they were not expecting it to explode out of the gate, they would want to do it and feed it gradually. So maybe they should plan to do the first Juicecast up, have some good experience, and then follow up with other conversations with other people who are associated with the film in one way or another.
Ken said they would be making announcements about this next week, by posting on Mirror for Ticket to Sapce on the Valentine's Day.
Recently we have been going through the current strengths and current fragilities of JBX, meanwhile going through the last stretch of the V3 token migration, which we signed off on last Wednesday.
A few hours later, when Jango was checking the JuiceboxDAO V3 treasury page, he found that the numbers of reserved tokens were unjustifiably big. Jango immediately recognized that it was an inefficiency with how the V3 token was taking into account the balances from V1 and V2 token supplies. This was a design decision meant to make the redemption process smoother on V3, but it ended up exposing an accounting bug.
This issue was sort of delicate, if someone were to have sent the distribute reserved token transaction at that time, the big number of reserved tokens would have been distributed to everyone on the reserved rate list and we would have had a different recourse which would have been a little bit more annoying.
The governance cycle right before this happened, we had just approved an proposal for emergency strategy of JuiceboxDAO. Shoutout to Filipv for doing the research and Dr.Gorilla for helping that effort and everybody for approving it. We made use of it right away.
As the project owners can change where the reserved tokens are routed to during a funding cycle, we had the multisig set the reserved token splits to be the DAO's address, then distribute that big supple and instantly set a transaction to burn that extra supply. Thanks to the quick response of multisig team members, we managed to pull this off very quickly.
If you are a Juicebox project, you are unaffected. This only pertains to JuiceboxDAO treasury, JBX tokens and reserved token recipients in this case. If you're running on V3 protocol, you will probably be recommended to migrate the JBController to a V3.1 version.
If you are a DAO contributor, there is no reserved tokens on V3 right now, and that won't change for another few weeks until we're no longer printing reserved tokens unexpectedly.
If you are a JBX holder, the timeline to open redemption will be postponed a little bit longer. We currently have 0% redemption rate on V3, so let's take our first principles and then more forward with our previous plans.
If you are a multisig member, we'll probably still be receiving reserved rate issuance into the DAO's account and burning them accordingly. If someone wants to make a proposal to go in and make token distribution as if this never happened, that's certainly possible, just requiring more steps on the part of multsig and the DAO. We could do that if that's something someone wants to do.
As it currently stands, V1 and V2 tokens are minted when fees are paid or funds are put into the treasuries, together with some corresponding issuance of reserved tokens. So if someone pays in V1 treasury, V1 reserved tokens will be minted and the same on V3, reserved tokens will increase in both treasuries, which is obviously not what we want. Hence it will be the responsibility of the multisig to burn the extra supply on V3.
The next step is to actually fix this problem so that we can move forward, by putting up the JBController V3.1, which is just a small shift in how tokens are accounted for, but will be a lot sturdier and dependable.
If you choose to change your reserved rate within a different funding cycle but you haven't minted or distributed the tokens reserved according to the previous reserve rate, it will calculate with the new reserved rate based upon the current outstanding supply as if the old rate has not existed all along. This was the way the reserved tokens had been calculated, but we won't do that anymore, we will shift it over to JBController V3.1 to solve this problem so as to get reserved tokens up and running on V3 treasury.
And the reason why we choose the option of migrating the JBController to a new version of V3.1 is that it will allow us to keep V1 and V2 in place doing exactly what they're doing, and avoid the tradeoff of totally stopping V1 and V2 and no longer managing interoperable fee collecting treasuries, which was the big hypothesis of this migration strategy.
Once we have removed it problem from any immediate actions needed, we can assess what we have learned along the way, to prevent this from happening in the future or reduce is probability. We will need a stricter checklist to our GitHub repos, because theoretically V3 JBX migration tests should have been more broadly covered.
Also we have to do a better job of assessing ownership over different pieces of codes and projects, and keep aware that there are certain pieces of smaller, more passive codes that are greatly important and need focus and space, despite all the other exciting stuff happening in the surface.
There are also some thoughts, from the contract perspective, to evaluate tradeoffs between low probability unexpected behavior exposure and squeezing transaction costs down.
Jango thought that we would be in a much better place once these steps are taken, without this reserved rate risk looming over us.
We are thinking about reducing there risks and fragilities as much as possible in the name of building the stronger and more resilient JBX, as we talked about last week in the town hall.
If we all commit a week and a half stitching this together and documenting it as well as teaching people how to make use of 3.1, we'll now have yet another instance of versioning under our belt. In some sense, we have this implicit understanding that the payment terminals controllers do have this lighter weight migration path which will require stitching together a few more components to facilitate those. But eventually as things emerge as risks or very very pointed opportunities and there might be moves to make, it will be easier to do it now when there isn't a whole lot of on-chains governance process and weight on the core infrastructure. We should try them now instead of doing it out of choice. Given the current need, it makes sense to get one of these under our belt, let's record it, let's lean into the postmortem all the way through till the end so that we learn from it. Then if we need to repeat this in the future, there will be very clear steps. At that moment, let's get back to where we were, which should be a great place of building more surface level experiments and imaging how this thing can be extended to do new things.
Mieos launched a Dripbox project recently, which will be in conjunction with some arts by Sage Kellyn.
Dripbox will offer some NFTs which are mystery boxes. If people buying those NFTs want to find out what is inside that NFT, they can hop over to another website of dripbox and link their wallet to check their holdings of this NFT, and provide an address to have the mystery box sent to them.
The proceeds used to provide these mystery boxes will be deducted from the treasury of this project, while all the leftover funds will be redeemable for the NFT holder in a "Slurp Overflow" phase. So there's basically a bulk discount rate for these mystery boxes that using the treasury redemption mechanism in Juicebox。
This is a little fun experiment, and Mieos that he was planning to start with something chill and simple and see if they can get this exciting project moving on into the year.
STVG created this AgentHQ project on Juicebox, to help fundrasing and support the development of Agent HQ, which is a way to build your own AI info center basically by putting in some links or PDFs.
STVG has tried to created a “Juicebox learning center” using this Agent HQ, by putting in some of the links and docs related to Juicebox, . He demoed how the interaction with AI agent worked on the town hall. He thought that we could maybe do a better job of explaining some of the technical terms for project creators and eventually evolve this into something that people can ask questions about Juicebox before they want to reach out for help in Discord.
STVG would be attending the Office Hours of Nicholas and Jango to talk about some NFT drops along with pairing up the merch.
Also STVG and Justin Harder are talking about launching a project on Juicebox for a show calld Molarky, where they have the plan to do some NFT drops as an open edition for a week or 14 days, while buyers can get a Juicebox shirt or a shirt with the graphic of NFTs on it.
Nicholas is selling 5 second ad spots on its Web3 Galaxy Brain project on Juicebox, for his Twitter Space podcast Galaxy Brain. People who minted an NFT can let Nicholas to improvise in the show or read a specific text the minter leaves in the payment memo. This is an experiment of selling something practical through Juicebox NFTs.
Nicholas is working on the next version of the Gabriel Haines project, and they might be thinking of having a website to have some interaction with the NFTs of this Juicebox project and maybe also with 0xsplits or something of that kind. So he was thinking of inviting someone who might be interested in the frontend work to discuss together.
ComicsDAO Nouns Comic Book Ad Page for Juicebox by Gogo
ComicsDAO is making a comic book for Nouns DAO, which will be the first mass market comic book printed from a Web3 venture. As JuiceboxDAO had been very helpful when ComicsDAO created their project on Juicebox, they are happy to reserve one page in this comics book for JuiceboxDAO to promote itself or share something meaningful.
Gogo encouraged people to go to the thread of ComicsDAO Artwork to join the discussions, and share their suggestions of what would be cool to have on the Nouns comic book ad page for Juicebox.
Jango posted an article on his personal ENS address, where he goes through some observations and ideas that we've collectively been talking about passively and loosely through proposals or other forms for a while.
At this moment, we are about to deploy the V3 JBX on V3 treasury and start the migrations from V1 and V2, which is a really exciting milestone for us and also the last step on our versioning journey. From the contract perspective, holders of legacy V1 and V2 JBX tokens can send them to the V3 token address, which will mint V3 JBX in turn while holding the legacy versions inside of it, and report the total supply across all three version.
So the redemptions should be working again in a short period of time, which is very exciting. Redemption was a huge experiment we did earlier last year and before to test how redemption manage to keep a steady grasp on the treasury, so that JBX has some sort of floor and folks can choose to exit if they wish.
Jango thought it a great point to reflect more big picture about what's been working well with JBX, what are the points of fragility and how we can start workshopping what to do next. This is also coming off the back of a lot of product focus we've had lately, such as NFT work, versioning work, fixing bugs, to create a better experience for project creators and project funders.
When AMM price goes up, people would rather mint from the treasury, such that the recipients on the reserved token list can retain leverage.
Aggregate scheduled decision making.
We only have to make decisions and execute them every two weeks, as all spending and treasury dynamics are expressed in funding cycles.
A huge plus to get participation up in proposals.
There's constant productive tension between the urge to spend on network proliferation and to conserve. Because JBX is in fact backed by the tokens that we spend, members can exit when they're losing trust in how this tension is playing out.
Progress towards artful veNFT JBX on-chain governance of the Juicebox project ownership NFT
This means that JBX should control the treasury directly and it should also be backed by the treasury directly, in a sense preventing some of the multisig fragilities that we have seen.
There's still some questions around the specifics of the ve mechanism with regard to voting weight and time periods, etc, there's still more research to do.
How it works:
You would lock JBX for certain amount of time to mint an NFT that represents that locked JBX. So JBX is taken off of your wallets, off of the market, off of where is used to be and lock into the contract, instead you have this NFT. As prototyped, we have an incredible Banny collection to visualized these NFTs.
The NFT and its underlying JBX could still be redeemed against the treasury any time at its current redemption rate.
NFTs are transferable.
We want a situation where treasury decisions are biased by those who hold assets aligned with the network's long term financial and cultural value, as opposed to more shorter term myopic reason.
It's more automated and it allows participation to distribute with relying on multisig.
It signifies confidence in the current JBX token version, which falls on the shoulder of Jango and contract crew to really make this version of the treasury dependable and create confidence for experiments to live on top.
Despite being liquid, transferable NFTs don't contribute to a price-chart meme, and instead you can have value correlated to other cultural phenomenon such as provenance, voting history and art. Non-transferable NFTs would have too big of tradeoffs, so Jango has not found a good reason to start the conversation in earnest.
It allows proposals to begin leveraging these staked positions to distribute, while reducing the risk of JBX distribution being dumped on the market, and actually incentivizing participation and the culture.
We can ship it in parts, so we can do the veNFT and still use Snapshot governance with it. We don't have to go to on-chain right away.
The artwork is really interesting. Just reflecting on how Nouns has benn working, there's a massive potential to make governance more engaging and give it more character. If JBX holders get to choose their character, their artwork to participate in governance, there's a lot we can do and that will just happen automatically without any necessary product intervention.
Most day-to-day activities in smaller scoped experimental projects will move to cheaper execution layers, while main net JuiceboxDAO will manage less frequent and more consequential decision, making the on-chain transaction fees more worth it.(Not ve specific)
On-chain operations will likely broaden the interest in the JBX mechanisms and its governance. It will be way more interesting to get involved in the community that has its rules, opportunities and decision baked in to the chain.
Like lower voter turnout, mores steps in the UX to get JBX, then call another transaction to lock it and mint an NFT. Part of the heuristic designing is to make this not a big mental obstacle to understand what's going on. It's a balance between that and trying to find a decent mechanism that incentivizes the behavior we are trying to achieve.
Voting will no longer be free.
Subsequent token migration are much more difficult since we're locking the JBX.
Jango thinks that we have talked about it a lot and the contracts had been done. We need to review and audit it and probably make some changes. But it's someting we talked about and built last year, Jango thinks that it's time to revisit it as we go into this next chapter as a DAO.
Use buyback delegate on JuiceboxDAO treasury funding cycles
How it works
When the ETH / JBX exchange rate on an AMM is significantly better than the JuiceboxDAO V3 issuance, if someone is paying a fee into the treasury or just sticking funds through the pay function, route that ETH to the AMM, buy back the JBX and distribute to the payment beneficiary and reserved rate allocation, instead of taking the ETH into treasury and issuing new JBX.
The reasons here are pretty straightforward, mainly to get JBX away from those looking to sell and into those who are currently adding value to the ecosystem.
We won't be taking the ETH into the treasury as often, but we also have a lot of JBX held by the DAO, so issuing new JBX isn't in our best interest either. There's a more efficient way to move it to better holders.
Let's imagine we are sending 60% to the DAO, 30% to individual contributors with day-to-day responsibilities, and 10% towards a fee module where JBX ve stakers can weekly or some periods based on that period's growth.
By experimenting the 10% to a fee module, we start to distribute the network's growth back to committed network members, which might be the thing that makes most sense to tend upwards over time as the network spreads.
The idea here will be more proportional to amount of JBX staked than duration stake, so the ve might not be a right mechanism, but there's something interesting here where we incentivize the network to grow itself by routing some issuance to committed members.
We haven't experimented much with reserved rate, but it's probably the most important potential energy for catalyzing a lot of growth. It's where the DAO chooses to direct inflationary pressure, so it's important.
We're allocating to folks who do not hold a lot of day-to-day responsibilities in mamaging the DAO's risks and contributing to its opportunities, which eats into the allocation of those who do. This is a small thing, but a meaningful thing, especially as a lot of folks take on hefty chunks of responsibility as we still need to.
We should start considering developing a precedent for distributing the DAO's JBX on a per-proposal basis with the goal of proliferating the network.
Instead of the reserved rate being the end-all be-all, let's maybe consider starting to add JBX distribution as part of a proposal or actually invite people to do so.
The reserved rate should replenish this supply, hence we're increasing the DAO's share here to something more like 60%.
A JBX payment terminal would really help here so that we can budget, schedule and automate distributions on a per-funding-cycle basis, just as we do ETH. We can imagine having an ETH and JBX funding cycle distributions to pre-configured addresses.
There's massive opportunity in fee-distribution modules to encourage new proudctive behavior while rewarding loyalty, participation and risk taking.
Obiviously these will make their way into proposal form in the upcoming governance cycles over time and we will talk about it. If we're going to tend towards smaller operations so that we can each focus on subsequent experiments built on Juicebox, we need to create a stronger, more automated foundation that is self catalyzing and less fragile.
Kmac: The JBX payment terminal, if that gets implemented, does that effectively mean JBX can be used to pay into any project in the network?
Jango: When I'm imagining JBX payment terminal, I'm thinking less about the pay functionality. Theoretically you could add a pay functionality to other projects, but if we were to scope it down, it will probably revert on the pay function and just be used for distribution. So the DAO could use the method of add to balance, which moves the JBX into funding cycle program that can just be scheduled and distributed as ETH is right now.
But theorectially if you're another project, let's say Peel, and you do want to accpet JBX and you're willing to give out 10 PEEL / JBX, you could also incorporate it in that way.
Jigglyjams: Just a question on that payment terminal, it's as if you want to distribute more than what's coming in from the reserved rate, is that right?
Jango: Exactly. We could route the reserved rate allocation directly to the terminal, and we could also inject what the DAO is holding into the terminal, so the terminal can use it.
Nicholas: Do you imagine after a shift to on-chain governance that we would rely more on automated funding cycles, or we would still be programming new configurations every two weeks?
Jango: I have no idea. I think two weeks feels like a good time period to take in new ideas, but it's also pretty exhausting if we're counting on each of us to go after new opportunities and risks with subsequent projects which will grow and have governance needs themselves. More brain free JuiceboxDAO is more enabling for everyone contributing.
ONNI has been assembling some documents that make is easier for us to put stories about Juicebox to media, also these documents are equally useful, if not more, for project creators. He will be uploading them in the next few days.
They are going to have a meeting on Friday, to talk about how to put together press releases, how to approach media with hopes of getting them to cover your project, etc.
We have a newsletter that Matthew and Brileigh put together, and we have an email list of people who subscribe to that newsletter. ONNI thinks the email list is an asset of Juicebox, and stronger that email list is, the stronger Juicebox becomes.
ONNI will be reaching out to project creators over the next week, with the hope to tap into some of their project memberships to receive the Juicebox newsletters. He thinks it will have benefit of making Juicebox stronger, increasing the value of JBX tokens, helping ensure survival and strenghening projects by giving them deeper involvement.
Matthew and Brileigh have started making tutorials for various Juicebox related functionalities, such as setting up a project handle, V3 migration, setting up a payment address for a project. Also they started making more general overviews of Juicebox's complete create flow.
Along with those tutorial videos, they are also writing corresponding articles, as some people will find it easier to follow along with an article that goes step by step.
Matthew said that people who has needs for some particular thing can always go tag them in the visibility channel, and they will try to make tutorial for it.
Also they're going to make use case videos, such as Juicebox for open source software projects, Juicebox for content creators, etc.