Art by Sage Kellyn

Specifications 3.1 by Jango​

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

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

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

Controller​

You can check full code difference here.

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

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

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

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

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

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

Payment terminal​

You can check full code difference here.

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

Specifics​

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

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

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

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

New event signatures​

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

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

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

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

Tiered 721 delegate​

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

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

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

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

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

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

Ticket To Space Update by Kenbot@StudioDAO​

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

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

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

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

Drip Box Update by Mieos​

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

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

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

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

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

Art by Sage Kellyn

Versioning / Postmortem Update by Jango​

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

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

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

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

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

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

Peel Update by Aeolian​

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

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

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

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

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

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

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

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

SVG Template by Nicholas​

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

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

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

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

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

Reflection as a DAO contributor by Jango​

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Discussions in the town hall​

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

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

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

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

OpenGSN explainer and demo by 0xBA5ED​

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

There are a few reasons why this would be useful.

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

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

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

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

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

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

Forming Plug by Darbytrash​

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

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

Banny Valentines by Matthew and Brileigh​

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

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

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

Art by Sage Kellyn

Postmortem Update by Jango​

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

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

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

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

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

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

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

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

Banny Valentines by Matthew and Brileigh​

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

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

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

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

Ticket to Space on Juicecast by Kenbot@StudioDAO​

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

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

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

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

Forming Plug by Germs​

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

Merch Squad by STVG​

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

Art by Sage Kellyn

V3 JBX Deployment Bug Postmortem by Jango​

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

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

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

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

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

How you will be affected​

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

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

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

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

Current situation​

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

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

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

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

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

Lesson learned​

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

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

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

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

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

Takeaway​

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

Dripbox Update by Mieos​

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

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

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

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

Projects Update with STVG​

AgentHQ project​

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

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

Merch Squad​

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

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

Updates by Nicholas​

Office Hours Promo​

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

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

Galaxy Brain Ads​

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

Gabriel Haines Frontend Open Call​

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

ComicsDAO Nouns Comic Book Ad Page for Juicebox by Gogo​

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

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

Forming Plug by Darbytrash​

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

w

Art by Sage Kellyn

JBX: January 2023 by Jango​

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.

Jango put up a proposal to update and re-ratify the foundation of JuiceboxDAO last week, encouraging how we might create a sturdier DAO ecosystem so that we can tend away from more day-to-day responsibilities. This proposal has been approved by the DAO lately.

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.

Current Strengths​

• Prevents capture by speculators.

  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.

• Cost-free voting

  A huge plus to get participation up in proposals.

• Redemption

  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.

Current Fragilities​

• We depend on 9/14 multisig for execution.

  Presence and loyalty of delegates are required.

• Voting tokens are fully liquid.

  Decision can be made to appease momentary price swings.

• Issuance price to fee payers and reserved rate beneficiaries is mucn lower than the open market price.

  Projects are overpaying for their JBX and reserved rate beneficiaries are receiving less-than-ideal issuance, and the market demand to sell JBX at a certain price is unmet.

• Reserved token distribution prioritization.

  It's impossible to determine the fairness of reserved rate distribution as the network grows, yet the reserved rate is a key piece of the DAO's immune systems against speculative capture.

• JBX governance process.

  Currently there are relatively few holders with over 10m JBX who participate in governance, and proposals often require explicit support by a subset of these members to pass a voting quorum.

We're at a good place but these fragilities still have risk and they hold us back from our maximum productivity.

So we should probably consider this upcoming time budgeting some time and resources to create a less fragile and more catalyzing JBX foundation.

3 Proposals To Address Fragilities​

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.

• Reasons

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

• Tradeoffs

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

• Risks

  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.

• Reasons

  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.

• Tradeoffs

  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.

Revised reserved rate allocation strategy​

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.

• Reason

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

Discussions on the town hall​

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.

Comms Update by ONNI​

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.

Visibility Update by Matthew and Brileigh​

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.

Office Hours Update by Nicholas​

They've moved the Office Hours from its prior time to 4:20pm EST on Wednesdays.

This week will be the #3 episode of this Office Hours, to talk about NFT tokenomics and smart ways to launch Juicebox projects.

The prior episodes of #1 and #2 can be found on the Juicecast page.

Art by Sage Kellyn

Office Hours Plug by Nichoas​

Nicholas would be hosting an NFT Tokenomics Office Hours together with Jango in Twitter Space. They would be talking to jin, one of the metaverse OGs, about openvoxels, and to Ibn Inglor from DangerZoneDAO, a musician who has toyed around with the idea of creating a Juicebox project.

Also Nicholas was experimenting the idea of letting folks to reserve a priority spot to talk about their projects by minting an NFT on the Office Hours project.

The purpose of this Office Hours is to discuss about NFT tokenomics or membership tokenomics to help people create projects with great membership dynamics.

Jango also said that we had been wtinessing treasuries that are more fundrasing oriented in the past year and a half, and also there was this impression that the same might continue and be our bread and butter, but it would be very interesting to pose the question of how we might create stronger and more sustainable business models for organization that aren't just asking to pitch in for the sake of governance or collective actions.

Also Nicholas had launched a Juicebox project Web3 Galzxy Brain for his Twitter Space and podcast, selling 5 seconds worth of advertising on his show for 1 NFT minted on this project. This is also one the experiments to hopefully find something interesting that people can make use of in the future.

Merch Demo with STVG​

STVG had been working on some merch stuff, trying to create an opportunity for people to sell merchandise and route the income to their Juicebox projects.

The way he managed to achieve this is to set up a slice on Slice.so, which connect to an API of Printful, an on-demand printing service provider, then products purchased will be made and shipped from Printful to buyers, while some of funds getting sent to The Brigade projoect on Juicebox. He did a quick demo of buying one OG Juicebox hoodie on the town hall.

STVG was also working on another option of making the purchase same as minting an NFT on ordinary Juicebox projects, where a pop-up window will come up after the purchasing for buyer to put in their information, so that seller can pick up the information and put order in Printful.

Filipv suggested that he put together a guide for the project creators to do this themselves.

STVG said he was working on that right now. And he was also working with SharkDAO and Bankless project management guild on how they can make use of this model.

Jango was a bit skeptical about the needs to hop around between Slice and Juicebox, and thought that we might need to find a way to improve this experience.

STVG said if the model tried on Slice is working, maybe Juicebox can also integrate with some on-demand API to provide for project creators to also sell merchandise, which may be helpful to build those communities or fan base.

DAODenver Discussion with Steve from DAOPlanet​

Steve shared a draft of proposal in the town hall, proposing Juicebox sponsorship of DAOPlanet's DAODenver.org, a ETHDenver side event. He hoped to get some feedback from our community, so as to make sure what they were doing was something folks would be interested in.

He also said that they were going to move their legacy V2 project to V3, mint their native tokens and distribute them to people who have supported them in the past.

Abraham Eden Demo by Jmill​

Jmill was working on a project called Eden with his friends Gene and Alexander. This project acts as a generative art API for Stable Diffusion and other models. They're trying to build the Eden project into a generative art social community, while using NFTs as API credits.

In the town hall, Jmill did a demo with his Juicebox project on Goerli testnet, where he paid the project and minted the NFT on Juicebox, and get a corresponding API credits in their ecosystem.

But right now, the actual credit record isn't on-chain yet, which he would be hoping to hack on in ETHDenver, building a truely on-chain credit system with some layer 2 claim on L1 NFTs and a relayer to pay the gas.

Also their project is open source, so anyone wants to use Juicebox NFTs as payment for their APIs also, their GitHub repository will be available to be used.

Jango thought the Banny AI generator in our Banny Warhol channel made by them is working great, and he was excited to figure out how to play with business models in this respect. Jmill suggested that maybe we could integrate Banny Warhol AI generator into Juicebox's create flow, so that when project creators want to deploy an NFT but they don't have a JPEG, they can describe something and get a Banny version of it throught the AI generator.

Jmill and Genekogan came to our town hall introducing Banny Warhol last December, read here.

Contest by Felixander​

And the correct answer is ... defifa.net.

Gabriel Haines Project Plug by Nicholas​

Gabriel Haines is a KOL on Twitter with 43.9k followers. He has been famous for making videos of himself shirtless yelling and waving a machete in his backyard.

Nicholas was working with him to create a new Juicebox project, where Gabriel Haines will be selling NFTs and doing roast or pep talk for the minters of those NFTs. By the time of this town hall summary, this project has been created successfully and has recieved quite a few payments.

And Gabriel is no stranger to Juicebox either, he was sent to the Bahamas to search for SBF in a cowdfunding in another Juicebox project last year.

Visibility by Matthew and Brileigh​

Matthew and Brileigh had an video interview with the above-mentioned Gabriel Haines here

And they also just released an Juicecast episode featuring Chris Blec, who is basically doing research and writing really critical articles about some DEFI protocols, and publishing those articles on his website blec.report. Chris Blec also created a Blec Report project on Juicebox to support his work.

Tiny Dino Show by Cheugy​

Cheugy is one of the founders of a project recently created on Juicebox. Their project is called Tiny Dino Show, which is an NFT project and one of those CC0 (Creative Commons Zero) licensing projects that had recently emerged, and is dedicated to making a show with the free IP Tiny Dinos.

They decided to use this Juicebox project to make a campaign for donations to support the production of the show. Also they have just won the prop house round in their own Tiny Dino community and will receive 2 ETH of grants to support the show. The grants will also be routed in this Juicebox project that they're currently running, to get validation from their community.

The Tiny Dino Show is an educational show for kids and young adults. They plan on making some scientific contents about climate change, preserving the planet and new ways to create and store green energy, etc.

Cheugy thought the model of Juicebox is very suitable for projects that may want to implement their governance at some point. He would be looking forward to learning what implementations Juicebox will have later on when it comes to governance.

Art by Sage Kellyn

Emergency Procedure, Opsec & Security by Filipv​

Filipv recently wrote two documents concerning the emergency procedures that we may want to set up in advance, so that if anything does happen, we will know what we should be doing.

The first document is the Juicebox Emergency Procedures, which covers what we should do if something does go wrong.

The second one, Contributor Operations Security is more a general security guid for DAO contributors

Any feedback to these documents will be warmly welcome. And Filipv was planning to put up a proposal in the next governance cycle to ask the DAO for permission to use these procedures if something does go wrong in the future, so that our multisig can have the ability to make necessary updates and changes in that situation.

Protocol Analytics by Filipv​

Filipv made a dedicated version of dashboard for purpose of protocol analytics in the town hall here.

He went over and introduced all the items on the dashboard, which covers things like number of projects created, fees paid, payments by projects, recent Juicebox payments, number of active projects(with volume > 1 ETH), and recent issuance and redemption(burn) of JBX, as well as the cashflows of various JuiceboxDAO terminals, etc.

Qwestive Referral Program Demo with JZ​

JZ used to be a contributor in JuiceboxDAO, and he is now working in a team called Qwestive which is a dedicated referral platform in Web3. He came to our town hall with the thoughts that a referral system might be useful for Juicebox ecosystem and he wanted to give some explanations to that by doing a demo in the town hall.

Why referral?​

According to JZ, referral has been a proven process for acquiring users in web3 these days, letting people who believe in a project help driving in more users.

He tried to prove his point by making two examples of Web3 projects which have made a huge success in using their referral programs to drive in new users and funds, GMX.io and Rango Exchange, respectively.

In conclusion, he thought that the referral system can actually drive in quite significant volume.

Why Juicebox?​

Since December last year, JZ has been in touch with STVG who has spent a lot of time onboarding projects and driving project growth in Juicebox. From his former experience as a contributor here in Juicebox, JZ thought that there would be a really good case for Juicebox to do the referral program, either for being a very strong community and a great product in the Web3 world. He also thought that there would be a huge amount of growth that can be unlocked if we set up a right program to incentivize community members and partners to drive traffic.

Also JZ pointed out that the role of Juicebox is not only about getting projects onboard, but also helping them to get successful, which requires quite a big amount of work to get things running. If we could put the right incentive structure aournd it, it could probably help making people who are onboarding projects more responsible and more incentivized to help those projects really get successful.

How?​

JZ also did a demo showing how Juicebox can make use of the Qwestive platform to set up a referral program. Here is the demo video JZ made for a Juicebox referral program.

As a choice, we can let anyone create their referral links, or if we choose to, we can scope down to a specific list of people who either holds a certain amount of JBX tokens or is on a whitelist for partners.

And the reward structure can be pretty flexible, either by a fixed amount reward in ETH, JBX or NFT, or by a tier-based with different reward amounts for various referral outcome, or even by a dynamic standard where the referer can get a certain percentage of fees that Juciebox collects from projects created.

And also the program can be defined to allocate rewards to the referee, people who click the referral link and create a project in this case.

Discussion in town hall​

Filipv thought a referral progam would be a great way to encourage more people to get involved with onboarding, and also a good way to align incentives with people who are working on content creation, visibility and project onboarding, etc.

For Jango's question of whether the events tracked are on-chain ones or just website activities, JZ explained that they actually tracked the on-chain data by capturing the wallet addresses of people who click on the referral link and create a project.

Nicholas agreed that this referral program makes a lot of sense, especially for project creation. Also we could set up a different referral program or maybe a tool that can be offered to project creators for use in their own projects.

At the end of the discussion, Jango brought up a quick thought about allocating a chunk of the reseved rate towards referrals and then sending it to a contract or a responsible entity to manage the JBX distribution. That way folks have a token that's backed by the treasury, as JBX gets issued when payments come in. We can fit the referral payout to the reserved rate structure, start with someone who is willing to be responsible for dispersing, and work towards some automated structure in the future.

Juicebox 2022 Year in Review with Nicholas​

Nicholas was collaborating with Matthew and other members on the Juicebox 2022 year in review. He made a list of important events happened in our ecosystem during the past year, and called on people who have suggestions come forth with them.

Defifa Update by Jango​

On the day of this town hall, the Defifa Ballkids team just deployed a new Defifa game that accompanies the NFL Playoffs this year. The team is trying to iterate as quickly as they can, so that they can study the games and play with different ideas.

They are also trying a couple of new things this time. Firstly, a better attestation process. The timing of the last Defifa World Cup was a little bit awkward, so this time they will try to start the voting for the attestation of a scorecard when the Super Bowl happens.

Secondly, there will be short redemption time window between the end of mints and kickoff of games, so that if people are unhappy with the distribution of all the NFTs, they can get refund by burning some of the NFTs they have, while no one will be able to mint extra NFT to form an outsized arbitrage value at the last minute.

Thirdly, there will be no trade deadline this time. All the NFTs will be normal tradable items all the time.

KMac gave some shoutouts to people who have been involved in the work for this new version of Defifa. Mieos and Sage did a great job in art work, Blaz did most the thing in front end, and Jango, Viraz, 0xBA5ED and Dr. Gorilla were the contract crew who makes this game happen.

Jango said we were also brainstorming how to leverage this tournament style mechanism to actually help other communities fundraise. For example, in the case of StudioDAO, they can frame a competition around some category of the Oscars or some movie festival where folks can play. We are definitely looking forward to the vision of how we can really use this formed factor to add an auxiliary component to any fundraise in art and cultural alongside.

Jango also mentioned that the team is planning to do the Defifa for March Madness. We created this concept of Defifa Ballkids who write the games, but Defifa is an open DAO, and our thesis is that those who play a game are probably going to be encouraged to join and take responsibility for organizing next game. The organization of Defifa is really meant to be open and we're trying to decentralize it with on-chain governance as soon as possible.

Blunt Finance by Jango​

Blunt Finance is another project supported by JuiceboxDAO, and it has seen some really fascinating evolution in the past several weeks. Jacopo has been the main dev both in the front end and contracts for this product.

We've simplified it quite a bit to really narrow in on a specific use case, which is to set the target of fundraising ahead of time at the stage of creating a funding round.

A project creator, blunt round creator in this case, can set the fundraise parameters such as fundraise duration, funding target, hard cap and project owner, etc. If the funding duration ends and the fundrasing reaches its target, the project ownership will be passed to the preset project owner and runs just like a normal Juicebox project thereafter. If the target is not met when the campaign is over, the contracts will automatically schedule a funding cycle #2 with refunds to donors.

It's lower risk in onboarding when it's way more simpler with just one prompt. Hopefull we will see a lot more projects spinning up and trying to meet a goal. Folks can contribute to these project with less risk, without having to worry about changes around here and there.

We'll see this project playing out as an experiment. If it works, Jango was pretty sure that Juicebox.moeny would want to incorporate it into the create flow to provide as an option for folks who maybe looking for a similiar mechanism .

We're just playing with these ideas of contract owned projects that can really narrow down what a project should or can be to start off, both in the front end which anyone can do, and also in the contracts which actually reduces risks dramatically.

Nicholas was pretty excited about the blunt mechanic, especially this stripped down version. It is quite similiar to the mechanics of Kickstarter where contributors can get a refund until the crowdfund reaches its goal. He thought that this could be super powerful.

In Jango's point of view, if you get a contract that owns the first funding cycle, you can then pass ownership, in the case of successful fundraise, to a contract that will manage how a second funding cycle goes. You can then create this chain of passing along projects to acutally fulfill a life cycle and maybe even have a conclusion, without any individual or multisig or on-chain governance contract ever really touching them, which is basically what Defifa does. He hoped that it opened up our minds to other opportunities and definitely wanted to encourage everyone to play with those ideas.

Jango really liked the idea of smaller chunks of responsibility that run smaller codebases to try things out, so that as they bubble up to place where people are, the risk is at least known a little bit better.

NFT Tokenomics by Nicholas​

NFTs have dropped with great success on Juicebox, and we have many interesting projects coming into existence. But so far we haven't really seen very hot NFTs, or any obvious secondary market activity for any NFTs originating from Juicebox ecosystem.

For this reason, Nicholas had the idea of helping projects create mechanisms around their tokens. He thought that for the majority of projects, membership tokens or other kinds of tokens that they can sell directly inside of Juicebox ecosystem are with huge opportunity and under exploited. So far, we haven't yet witnessed any mechanism that has really taken off in a wild way, like for instance an NFT collection born on Juicebox getting really popular outside of Juicebox ecosystem. Nicholas has been talking with folks about other models for doing more than just popping up a JPEG and hoping that people will contribute for it.

One idea that Nicholas has benn thinking about for the past couple of weeks, is that low cost NFTs can have a single use voting purpose. NFTs that are really cheap or at least affordable give everyone who purchases them an opportunity to vote in a single proposal round to decide how to distribute some or all of the funds, while a subsequent round starts with similar mechanics and entirely new NFTs which will be used to vote in this new round.

Basically, Nicholas hoped to establish mechanisms that can work as play books for Juicebox projects to generate recurring revenues.

Jango declared that we still have a few contracts that NFT controls yet to be exposed in the front end, which he had been working with JohnnyD and Strath to make sure those become available to folks in an elegant way. These new functionalities include reserved NFTs, NFTs as governance tokens in the format of tier based governance, on-demand minting of NFTs by project owners, etc.

ComicsDAO Promotion with Gogo​

Gogo announced that finally they had the arts made ready by Sage, which are some amazing masks, and they are going to start new funding cycle with the new NFTs deployed which will help a lot to achieve what they've been planning.

Last year has been an amazing for ComicsDAO. For this year, they are planning with some really big things, such as starting some AI comics and some other things. The development of ComicsDAO is a fun way to reward people that funds them.

Art by Sage Kellyn

Protocol Analytics And New Projects by Nicholas​

There is not much activity in the last week. We have 62 ETH in payment on the protocol, but this includes the payouts to projects like Peel, which are only inter-project payments. And we only have 2 new projects created last week, mabye due to holiday season.

History cashflows of Juicebox:

Highlights of some projects:

• The EmpireDAO 2023 Membership Drive

  EmpireDAO is a co-working space in New York and they are now having a bit problem with their lease. This project is fundraising to help them stay in their current space and avoid personal bankrupt of the founder.

  

• Lenster

  Lenster is one of the front ends for the Lens protocol. This might be a project they're using to experiment with Juicebox.

  

• Twitter DAO Energy Gauge

  This is a project created by Jango. The idea came from recent discussions around whether Twitter should tend towards more Dao-ish, so Jango created a treasury where people can safely deposit their funds in and get the funds back any time they want easily.

  

TokenURI Resolver Update by Nicholas​

Basically, the tokenURI resolver V1 is ready to go. Once the proposal put up by Nicholas to extend the permission to the multisig for setting TokenRriResolver is approved by the DAO, we will be able to implement something without having to wait until the delay period. So maybe next week, we will be able to set up the first version of this token resolver.

DAO Foundation Reflection by Jango​

The Juicebox DAO foundation document can be found here

Jango though that now we have a cool opportunity to reflect on the commitments that we ratified a long time ago, and he was planning to put up a proposal in the upcoming governance cycle to update this document.

Jango has started to write and share some of his train of thoughts since the past month, and ultimately got to a few pieces that outline where we are with the many little pockets of opportunities.

Obviously everything all unfolds and it's a reflection of what's happening in the Discord and commitment we've been making in the proposals up until now. So this refelction is nothing new or far reaching, it's more just a way to find the right metaphors that can easily encapsulate what people are getting themselves into when they are thinking about launching projects, allocating money to projects or contributing to the DAO in various ways.

Mission statement​

What we currently set out to do is to "helps people confidently run programmable and community funded treasuries from startup to scale, openly on Ethereum".

There have been a lot of stress on the protocol evolution and security to make sure that it gets deployed and adjusted, and takes into account the risks that people are exposed to in interacting with these contracts.

Towards the end of last year, we've realized a more important need than "community funded", which is that we need to figure out how to increase the distribution of projects or help projects do that for themselves. And there is a need to help basically funding money through the system and give capital allocators more confidence when engaging with Juicebox projects. Although it will be easy for us to allocate a little bit of ETH here and there to projects that have potentials, it will be a lot harder for capital allocators, either as individuals, as VCs or whoever they might be, to make a confident bet that can prevail over time.

So maybe there is something that incorporated in our current mission statement, but that seems to have been more pronounced at the end of last year, and into this year.

There's been really cool research done last year about the potentials of L2s, but every time we tried to push an idea forward, either a bridge or token choreography, we ended up coming into roadblocks that become familiar. Jango suggested that we move forward with the cool ideas we have, while being at peace with the fact that there might be roadblocks and things could emerge, and with less perfection in mind and more expermentation encouraging attitudes.

Values​

Jango suggested to leave this part to the proposal thread discussion.

Focus Areas​

Filipv thought that our way of operating had changed a little bit since there were originally written. He felt that we're operating less on a per focus area basis and more on a per project basis these days. In Discord, for example, we've moved conversations from these general focus area channels into specific project channels.

Jango agreed that it'd be a really cool idea in this next draft. There was a trend in the past year when Peel, WAGMI and several other projects emerged, some of them were never really incubated as individual focus area contributions to JuiceboxDAO, but more in a way that people started working on a certain direction and then developed systems that could have some self-sustaining future.

Jango thought maybe some of the items on Focuse area are no longer something we want to emphasize in line with others, so might be worth reducing from this list. It is also good to recognize what we are actually focused on, or if there is anything to be added here, or how to reframe some of these items.

The governance, for instance, it's something that DAO is still focusing its resources on. It will be up to us, as the DAO stewards of the treasury, to really figure out: " Are we spending on governance for our own sake, or because we're trying to make some bet on some projects that maybe have a life outside of JuiceboxDAO?" And if so, how are we structuring and thinking about that?

Talking about projects, Jango thought maybe the biggest assets of JuiceboxDAO don't lie in its ETH or JBX holdings, maybe are instead Peel tokens, WAGMI tokens or Lexicon Devils tokens, those of every project that we have started to put resources into. He wondered how we might actually think about those and create tools to really structure them and reflect on how those bets are going, not only in terms of them providing services to JuiceboxDAO, but also us all the individuals helping to support them to really thrive on their own.

And for the protocol, Jango felt that we're in the final bits of defining what we need to be responsible for in the protocol level. There has been a lot in this regard this past year, we definitely don't want to keep doing a lot of that over time. It's cool to offload that responsibility to stuff like Defifa, some other projects that can expand to other L2s, Nance and etc.. But at the same time, monitoring and documentation might be something that's worth attending to, although it's not clear whether they will be individual contributions or a collective JBX responsibility. There won't be payouts for these work, so the DAO is not focusing its resources on the protocol anymore. It's just something we care about and maybe it's not best expressed in this format here.

Even if the proposal to update this document doesn't get ratified or even go to Snapshot stage this first time around, it would be cool to have a few versions of this information that we can really reflect on. It will be probably less useful going through each of them and more interesting to talk high level that anyone can have other things to offer.

KMac suggested that we should pay more attention to the security of the protocol, which is something really important in terms of having it audited and deciding who can maintain and what to be maintained, as well as how permissionless that process will be.

Filipv thought that along with developing front ends and good clients for the protocol, it would be a good focus to work on various integrations for the protocol, such as what can we do to make Juicebox work well with WordPress or with Lens, do we have rpm packages, do we have PHP library to interact with Juicebox, so as to make it as easy as possible to use Juicebox in as many different places.

Filipv also suggested that maybe we should include discoverability and curation in the focus area.

Nicholas said we can really make sure that when we do things in any of these focus areas, the areas are just to help us think about all the various things we should be doing. We are not doing them because they're on that list, but doing them to achieve that mission statement.

Jango thought the cool thing for JuiceboxDAO is we have been pretty steady in the way we are thinking about our infrastructure, about our mission, about what projects we probably care about and why we care about them. It in some sense pierces throught a lot of the momentary noise and created these more longer term trends. Jango hoped that we can keep continuing it, while at the same time listening to our intuition along the way.

Membership​

The last one of the list we have membership, which is JBX and voting. Jango said he was really excited about expanding in this respect later on this year. We will bring ve tokens back into conversation, get all the way through to V3 and reactivate redemption value. So we'll revisit membership with stuff to add this time around.

It has been cool to have governance process evolved around this membership structure, and it feels pretty sturdy and we can offer it to other Juicebox treasuries. It's all decent to consider it a membership to the treasury where we all have collective ownership resposibility over the treasury that we're working to figure out how to better create opportunities for other folks contributing both to JuiceboxDAO and other projects.

Jango thought that our mission statement going foward is not the DAO's mission statement only, but from the product perspective, instead of just providing programmable treasuries, whether Juicebox would be really strong suit to provide money and membership coordination for projects, whereas the tokens are some means towards some sort of membership, such as membership to the treasury, to a club, to some obligation, to a game like Defifa, to a non-profit. We have a lot of examples and a lot of case studies that we can pull from to make clear Juicebox projects, money and membership coordination for all these different types of organization, either on-chain or off-chain.

Forming Update by Darbytrash​

Darby urged us to do the RSVP on Forming homepage for the Fomring X Songcamp collab event, so that we can be eligible for wearables airdrops by Lexicon Devils.

Also, as Forming project has migrated to our V3 protocol, they have deployed the Forming official Juicebox unlockable NFTs. All the funds raised throught these NFTs are going to be allocated to the artists selected for this Forming X Songcamp performance. For each Forming event, all performers will be set as distribution beneficiaries on the Forming project, so that when the event ends, they will all be automatically distributed proportionatly with the funds raised in that period of time.

Darby was so excited about the NFT functionality of Juicebox that he wanted to give hats-off to the devs and everyone who made that possible, as he felt this could be a game changer in this world.

Jango suggested that we put up the tutorial video made by Matthew and Brileigh about how to create NFT on Juicebox in our lounge in the Voxels, so that folks attending the Forming events can learn how to set up their own NFTs on Juicebox also.

Darby also announced that Lexicon Devils had the plan to hold a live Forming event in New York for the NFTNYC this year, they are willing to discuss with folks in the Juicebox community to brainstorm the details on making this real.

Matthew and Brileigh has also released a new episode of Juicecast featuring Darbytrash, covering how Forming got started and its past and future events.

DAOPlanet Update by DAOofSteve​

Steve from DAOPlanet said they were moving their project from Juicebox V2 to V3 protocol with the help of STVG, and was hopeful that they can get the project up and running by the end of the week.

Steve also said that they are going to hold the DAODenver event this year, along side the ETHDenver build week. This time they are moving to free tickets for everybody going to DAODenver, so they anticipated having a lot more people to attend their event this year. Steve also introduced their hotel accommodation packages and the partnership with CityDAO etc.

Jango thought it would be great idea to make the length of the week more accessible to folks, and maybe folks in our community could help to build some momentum for the DAOPlanet project.

Defifa NFL Update by Jango​

The first version of Defifa has finished successfully, which is super exciting.

We are going to bring along with a few folks contributed to the first round and some new folks interested in going forward, to do another iteation of Defifa on the upcoming NFL playoffs.

Jango said we were almost at the point where we had the artwork all done and only some last minute things on the contract with smalll adjustments, and he felt pretty good about this new game.

FIlipv suggested that we make a concerted marketing effort for the Defifa NFL playoffs, with Discord servers, Twitter, Telegram to maximize the engagement, or possibly run ads as well.

KMac responded that we will have a very short mint window for this iterated game for NFL playoffs, which is only less than a week between the announcement of playoffs participants and the kickoff of the playoffs, especially taking into consideration of things like contract deployment etc. But he was very willing to try some actions of ads together. He thought that it would be easy to figure out what the breakeven might be on ads. If we treat ballkids' mints as revenue, we can figure out if that makes sense. It feels right from a mechanics perspective.

Art by Sage Kellyn

Juicebox Analytics Update with Nicholas​

Last week we had 15 new projects, and 5 ETH paid into the protocol. And the number of projects with more than 1 ETH in volume in last 30 days is at the highest level since April this year. The number of projects created wthin last month is the highest in the past three months.

One of our community members KMac suggested that there are some statistics we can track on a regular basis. Nicholas also proposed that maybe we should make a segment of our town hall to figure out the healthiness of Juicebox protocol by looking into these metrics frequently.

Filipv thought that we can pin down some of the focused areas so that they can be consolidated into certain dashboards dedicated to be used towards Juicebox analytics on the town hall.

Defifa Attestation with Jango​

We're wrapping up this Defifa game and learning a lot as we do it. We inherited a lot of properties from the governor voting system from the Governor Bravo contract.

Users can start voting one week after the last World Cup game, and the voting duration set in the contract is one week, so once a scorecard is uploaded, there'll be a week's time for folks to vote on that scorecard and ratify it. So the next week if we can get up to 50% of NFT holders in the attestation of scorecards, we could end the game in a few days and get this thing finalized and behind us, then we can focus on iterating for the next round.

And Filipv helped to demo how to attest the scorecards on defifa.net.

The next plan for Defifa is to create a game for the NFL playoffs in January next year. The idea isn't to iterate too much stuff into the NFL game, it might need some new arts but will keep using the contracts and frontend as much as possible along the lines of defifa.net/nfl2023 or something like that.

It will be good to have another go-around and make some small improvements under our belt, while also planning ahead for other competitions later on in the next year, where we can experiment with some more new things along the way.

We currently have some interesting ideas with regard to how we might improve inter-game play or how to build minter confidence, but we'll first see how that plays out this time around for the NFL playoffs.

Updates on Gnosis Safe, project search and SEO by Filipv​

Juicebox has been not been a default APP on the new Gnosis Safe app because of some problems with auto connection. Filipv has created a PR to the front end, and once that gets approved and merged, we'll auto connect to Safe and be a default APP on Gnosis Safe again.

For the project search feature based on Sapana that Filipv demonstrated last town hall, there's an outstanding PR for it that put together by Peri and added with some final things. Hopefully this project search will be implemented in the front end soon as well.

We have a local PR for some of the SEO stuff we've been discussing, thanks to the works of Acidicsantana and Filipv. With that, the SEO on docs.juicebox.money should be improving slowly, so should that of our main Juicebox.money website.

Forming update by Darbytrash​

Lexicon Devils will be hosting a Forming event with Songcamp on Jan. 6th, 2023, with the performance lineup of Songcamp OGs announced yesterday .

Also they are doing RSVP on Forming homepage, and the applicants will be eligible for the wearables airdrops by Lexicon Devils.

Jango wondered how many submission were made for this event and what was the process to choose the artists that will perform on Forming, and Darby said they received 8 - 9 submissions, the Songcamp community made the final decisions in choosing performers, with Lexicon Devils being responsible for editing and curating the contents as usual. Also there's a criteria for applying for a Forming performance, which requires the contents to be filmed exclusively for premiering at the Forming events.

Lexicon Devils' Forming project on Juicebox has also migrated to the V3 protocol lately. They will be putting up some different tiers of NFTs on this project later this month.

Two truths and a lie with Felixander​

Felixander gave 3 clues on the town hall and asked the audience to pick from the list of persons who is the one telling those clues.

Clues:

1. I raised money from a former chairman of FASB, a former SEC commissioner and an electronic spreadsheet pioneer, and then lost it all;
2. I played basketball against Isaiah Babyface Thomas;
3. A book I wrote sold over 1 million copies.

The correct answer was ... KMac.

And the one lie is No. 3.

End of Year Thoughts and Reflections​

Jango: I think a lot of new amazing contributors lingered throughout the year, and that's a long time to be contributing to something and figuring out new ways to participate as things that were messy continued to become a mess only maybe with a little bit more organization over time. That's certainly worth celebrating.

I am looking forward to finding out how the community exists in the next year. It's been a cool year and I've had a lot of fun and been very grateful. I am stoked for so many things that might fall into place in the next year.

Also shoutout to Jigglyjams for making the Nance in this year, which will be super exciting for the next year especially to really stabilize it and make it the governance backend that will be tied to a lot of Juicebox processes.

The podcasts made by Matthew and Brileigh gets better and better in quality, too. It's cool to have this cadence of publishing, while tweaking the style and gear as it's moving forward.

Nicholas: Also Matthew and Brileigh have been doing a great work in Juicenews which is a great resource for keeping people up to date about the Juicebox ecosystem.

Shoutout to ONNI who created the Marfa Giant project in a small town and tried to figure out how to bring the people there onto web3 verse and accomplish the value of Juicebox. Recently he also has been involving in the marketing efforts of JuiceboxDAO.

Jango: Huge shoutouts to everyone who worked on the versioning stuff this year, from writing and testing the V2 contracts, then finding some small issues through Code4rena audit, to developing this V3 new contracts instead of patching the V2, and figuring out some interoperability standards. So next year, we'll get to build all these really fun and flexible toolings on top of it. For all the contract folks, yes, it's been a heck of a year, wild and frustrating many times, but with so much fun.

It's pretty wild. This is like everyone is on some significant spectrum of foundership of Juicebox. It's amorphous and defined just by what folks want to do, build and try to make these regenerative moments happen. I'm curious how to maintain a Discord in a governance system, or in the next a few years, given the potential of thing. I'm very excited about it.

There're some really good ongoing conversations happening, which are open, complicated and requiring our coordination ability and potential. Myabe we have a lot more answers than we had last year, but also have probably disproportionately more questions now open for exploration.

Darbytrash: I just want echo that this year has been so much fun and crazy that it's one of the most creative and rewarding years in my life. I owe a lot to Juicebox and I am really grateful to be a part of this community, be here with you all. Thank you!

Art by Sage Kellyn

Reserved Rate Discussion Callout by Nicholas​

This conversation started around the beginning of Dec, when Jango had thoughts on the ways to redistribute some JBX to contributors on the reserved token list.

And Nicholas put up a proposal, Distribute 15M JBX to Reserved List addresses, in a hope to suggest a way to distribute some amount of JBX to JuiceboxDAO contributors. This proposal came under very heated discussion in the temperature check stage of JuiceboxDAO's #38 Governance Cycle. Commuinity members expressed their different ideas on this topic. The discussions evolved from whether or not it would make sense to distribute JBX tokens to contributors on the reserved list uniformly, to if we should even reconsider the meaning or purpose of a reserved rate.

Nicholas called on community members to join the discussion that will be expected to follow after the New Year, when we are looking at having a proper discussion about how we want to think about the reserve rate.

Jango said this discussio of how to get JBX outward to both incoming members or folks who have been contributing, is somewhat a macro question which is solved well by reserve rate at least in the beginning of the treasury operations. But at a certain time, we also do have to be reflective over the tools we're using, not only for ourselves, but also for the broader Juicebox ecosystem, because we are offering these tools to others, to both solve their community initialization process, and their scalability as well.

Juicebox Analytic Roundup by Nicholas​

Using the dashboard created by Filipv to compare projects that are receiving payments between different version of Juicebox protocols, we can see that V3 protocol is having a very healthy trend of adoption, while V1 and V1.1 is tending towards zero, espcially as projects like Lexicon Devils which are some of the last active ones on V1 have already moved to V3.

Talking about different versions of protocol, Jango said that the versioning nomenclature discussions had been very interesting for him this week, which was brought up by Nicholas and Peri about the usefulness of scoping down how the juicebox.money website references versions of protocol because it can be confusing sometimes. Jango also said he was grateful to the versioning effort for getting us to a place where we feel comfortable iterating on otherwise fixed smart contracts, while giving other communities the option to move over as well. He thought that if we could do this versioning efforts over again, there may have been some nomenclature things that we could improve. This definitely encourages us to be open-minded abou how we go from here. A lot of treasuries have evolved over to V3, but we might still want a lot of that versioning infrastructure to create some path forward, given the risks or features that we find compelling enough to do.

Highlights on new projects​

• Salman Needs A Job is a citizen journalism project exploring the World of Work in Web3.

  

• The Chinese Juicebox project created by Zhape, in an effort to extend more support to projects in the Chinese community inside the Juicebox ecosystem.

  

• The Juicetool project that Twodam launched to fund the running of Juicetool website.

  

• zhougsoft created by zhoug who is a member of the mfers community.

  

Current status of some projects waiting for V3 before​

1. Abraham Eden project that Jmill and Genekogan have been working to spin up a custom NFT strategy. They have been waiting on V3 to be able to sell NFTs which would act like batter packs that users can use for AI generation events on their machine learning service.
2. The Thirsty Thirsty, a community of wine and food enthusiasts, is actually going to implement governance on a weekly / bi-weekly cadence to broaden the decision making in its current NFT holders. Folks that starting to empower the community are thinking about proposal for the community to deploy a Juicebox treasury to orchestrate its sense of purpose. This is a pretty cool, long-term oriented project that's trying to play with a more sustainable regenerative business model alongside the governance and treasury dynamic.
3. The Shiba and the Whale - A Doge Anime, a project that dedicated to making a film. It is really cool model for other artists to complete things like this through Juicebox projects.

Status of Defifa by Jango​

World Cup is over and the Defifa tournament turned out pretty fun and encouraging. Now we're planning the next step of this Defifa experiment, to run some competitions in 2023, iterate on something that seemed to work well and reassess some opponents that didn't work well.

Meanwhile, we're wrapping up the current instance of Defifa. From now until December 25th, folks can start submitting scorecards of what happened. Then from Dec. 25th, people who are holding the NFTs can vote and attest a correct scorecard. After the attestation, the treasury will unlock and folks can burn their NFTs to get their portion of the winnings depending on how their team did over the tournament and how many folks have the same NFTs.

There's a lot of stuff that we can make up for it to iterate on for experience in this upcoming year. We can basically play any points distribution game between mint and attestation of the scorecard.

We will try one for NFL playoffs, which starts mid January of next year, to iterate on a few parameters. And we also are sketching out 5 or 6 tournaments next year across domains, like League of Legends, March Madness or Women's World Cup, etc.

It will be cool to start digging ahead for some of these. We can really try experimental point systems and things within the Defifa structure. Then hopefully, we'll soon have a pattern that feels good and safe enough to make a Defifa create flow for folks to create and run their own competitions.

Another cool callout for Defifa this time around is that the ball kids minted one of every 10 NFTs for the ball kids treasury. Give the amount of tokens minted and the fact that the tokens are redeemable in the treasury, it ended up being a pretty successful experiment even monetarily for actually being able to support this next wave of development.

We need to reassess the model for continuing the sustainability of the project and make sure that we keep things tight. But this has a chance of being very scalable and can be applied as a fundraiser for other arbitrary projects.

There're all kinds of ideas we can iterate on. We should definitely dream big, but it's also exciting to stand on some solid ground and be able to iterate one thing at a time from here on out.

Demo of GasWoman and Juicy Spider by Filipv​

GasWoman​

Currently when members of multisig execute multisig transactions on Gnosis Safe, there might be some gas fees incurred in those executions. There are needs to refund those members who executed for the multisig. GasWoman is a generic tool Filipv created that fetches all of the Gnosis Safe transactions and build the transaction to do the refunds. This is a pretty simple tool but it might be useful for some people and projects.

Next, Filipv is thinking of doing the same thing for project taps, which can be triggered by anyone as a public transaction to distribute payouts from Juicebox projects. It will be cool to also find a way to make reimbursements to people who triggered those project taps for those gas fees paid.

Jango also reminded that there's also a functionality in the contracts for payouts, which allows people to route some of the payouts to the person who clicks "Distribute" and triggers that distribution transaction. So actually projects can bake that into the payout directly to incentivize people or MEV bots to click and trigger that transaction.

Juicy Spider Project Search​

Up till now, Juicebox.money only suppors searching with project handles, which is not very convenient. Recently Filipv has been in contact with Sapana to find a better solution to it.

Sapana is a service that does backend search management for Dapps. Juicebox was recently added to the closed beta of Sapana, so Filipv used it to build a simple indexer and a client for it, allowing us to search metadata and other aspects of projects on Juicebox. The repo of it can be found here.

This Juicy Spider project search tool that Filipv created basically crawl the projects on Juicebox and generate the API for search, and Peri is now working to integrate it into Juicebox.money website, so that there will be an open access API endpoint on juicebox.money for folks to use later on.