Nance Updates by Jigglyjams​

Jigglyjams introduced some of the new features on Nance for proposal actions, which help specifiying the execution details of proposals. If a proposal gets approved, its actions will be easily queued as onchain transactions to be executed by multisigs of DAOs, which is very helpful in avoiding possible miscomprehension of proposal details, as well as saving overhead burden of the multisig.

• If payment or transfer is mentioned in the body of a proposal and no action is added to it yet, there will be a pop-up window to remind users to do so. Although users can choose to override and submit a proposal without an action, this serves as a good reminder.

  

• If an action is added to make transfers from the Safe wallet of the DAO, Nance will show the balance of assets holded in the Safe wallet.

  

• And now Nance also supports actions with custom transaction, either by manual input of transaction detail or pre-defined interactions with embedded DApps.

  

As many DAOs are now using Discourse to build their communities, the Nance team is looking at the possibility to create a fundraising campaign to help fund the integration of Nance with Discourse. Jango and Jigglyjams both agreed on the direction of making Nance a upcoming Revnet network to support its future development.

V4 Updates by Jango​

At this moment, the Juicebox V4 protocol is going through the last round of audits. The team has finished iterating on the Nana-core repo where there is only one remaining PR need to be merged, and it is now rating two audit reports for Suckers repo and the 721 hook repo respectively. We are working on an upcoming testnet version that will be likely be the production candidate of it since there is no forseen changes left to be made thereafter. Then efforts will be made to actually put some activity on this testnet to see if we catch anything in this post-audit phase.

Proposal to integrate V4 on Juicebox.money​

During the current governance cycle, Aeolian submitted a proposal to fund the the integration of the V4 Juicebox contracts on juicebox.money. This proposal didn't pass the temperature check of this cycle, but Jango felt that, since we are putting quite much weight on audits and getting things tightened before launch, it might be worthwhile to revisit this proposal sooner rather than later, to at lease let juicebox.money play on these testnets in a more experimental environment, although probably not servicing it to users as yet.

The discussions of this proposal have also brought up many questions about how $NANA token relates to Juicebox or $JBX, what the relationship between these economic networks will be, etc. According to what Jango said on the townhall:

• $JBX will not be the fee collecting token on this omnichain Juicebox V4 network, but it will continue collecting fees from the current V3 protocol;
• $NANA tokens will be collecting the revenue of V4 protocol;
• $NANA tokens will be owned by $JBX via the reserved rate allocation and an initial pre-mint;
• $JBX will become the only governance body of Juicebox.

Interfaces of Juicebox V4 protocol​

At this stage, we have several interfaces to interact with the Juicebox V4 protocol:

• revnet.app
• juicebox.money
• juicescan.io

Juicescan.io, developed by Aeolian, is a very simple interface to check the full spectrum of details of projects on Juicebox protocol, which is a burden that juicebox.money has had to do for V3 protocol and all the versions till this stage. Juicescan.io can prevent juicebox.money from being too feature specific and focusing on less interesting details about a project which relate more to risky than informative value. With Juicescan.io, juicebox.money can take a stronger position as to what it's now trying to offer.

Although juicebox.money will support deployment of a project on any chain, if various treasuries in different chains were to be owned and managed by an entity, it will be very hard to coordinate these treasuries to communicate with each other and keep them in sync. Revents, on the other hand, are specialized Juicebox projects that are contract-owned, which means they will be deterministic once they are deployed and can be kept in sync across several chains.

So revnet.app will be the primary interface if folks are doing crosschain or omnichain things, it will be the place where people interact with the omnichain capability of Juicebox protocol, where projects can operate and manage token issuance and redemptions on any chain.

Jango indicated that Juicebox protocol is very open-ended, people can choose to express it on different front ends, like revnet.app, juicebox.money or many different little websites that do specific things, while using the same database underneath, and can also choose to expose different features of the protocol that they feel appropriate for specific purposes on those interfaces.

Bannyverse Deploy Script Updates by Jango​

Jango has been working on the deploy scripts for Bannyverse lately. Bannyverse is the surface level project that ties together everything we've been working on. It's very cool in that sense, but there are also a lot of components, such as the 721 hook which is the standard JBNFT, the buyback delegate attached through revnets and Juicebox V4 protocol, and also some Croptop elements alongside, basically with everything integrated into this one project.

Jango introduced that in the Banny contract, there is one component that Bannyverse adds for its specific use, which is the 721TokenUriResolver. This token URI resolver takes NFTs in various categories and stitches them together to make a Bannyverse. It allows us to dress the Bannies we own, by showing the token URI, the SVG data and the outfit IDs of a naked Banny, realizing the visualization of dressing naked Banny with different outfits.

In the town hall, Jango went through the deploy script of Bannyverse line by line, sharing the efforts that the team had been making in the last period of time, and also letting other community members try to look at things from the programmers' perspective. This deploy script is still waiting for the last two very important components, the Cross-chain Sucker and the Swap terminal, which will be added in quite easily when they are ready.

Chain identification​

First, we need to figure out what chain we are on, because Bannyverse can be deployed basically onto any chain.

Dependency repos​

All the contracts from these dependency repositories are as follows:

Load the addresses​

Then we will get the addresses for multi-terminal, rulesets, buyback hook, NFT hook, hook store and the revnet Croptop deployer.

Top level metadata​

We are going to define some top level things which include logo and all the metadata stuff that shows up on front end website like Juicebox.money.

Tokens to accept funds​

Here is what we are going to set the terminals that the projects will accept funds through, and we will set it to accept the native token of that specific blockchain. In this case, ETH on Ethereum mainnet or anywhere else.

This is where we would add other terminals to accept funds in other tokens, the upcoming Swap terminal will fit in right in this part.

Revnet stages​

We are going to configure the stages for Bannyverse revnet, which is going to have 2 stages pre-set at its official launch. Both stages will set their respective start time, operator split rate, initial issuance rate, price ceiling, price floor tax intensity, etc.

Revnet configuration​

After sticking the stages in the main revnet configuration, we set the base currency, pre-mint amount and the initial operator.

Buyback hook configuration​

Then we are going to configure the buyback hook, setting the parameters that determine the prices to implement buyback. We will define the pool and the TWAP parameters as well.

Down below, we will keep a reference of this buyback hook configuration, while also specifying the address of the buyback hook contract.

Tiers of NFTs​

We are going to preload 4 naked Bannies with 4 tiers each at different price points, different supplies, etc.

Croptop parameters​

These parameters are to allow people to post their own outfits onto NFT collections. The project owner does not have to be the only one that has permission to post items into the Bannyverse, it can eventually grow into a world where anyone can post collectibles onto the Bannyverse.

Broadcasting onto the chain​

Now that we have everything properly set up, we are going to broadcast this onto the chain. We will send two transactions. The first one will be deploying the URI Resolver, which will be the custom Banny resolver contract. And the second transaction will be deploying the revnet, throught this deployCroptopRevnetFor() which will set the project in motion, passing in everything makes croptop, such as the name, the symbol, the project URI, the revnet configuration, the terminal configurations, the buyback hook configurations, the NFT hook configurations and the Croptop posting, etc.

---

Once we run the script, we should have a functioning Bannyverse revnet that is selling naked Bannies ready to go, as well as with the support for Banny outfits in the future and other normal Juicebox components.

We will also use a similar script for the Bananapus project, which is the fee collecting project of the protocol, but without NFTs or Croptop features.

Background of Bannyverse by Jango​

Aesthetically, Bannyverse is being reborn from a rich set of assets that we put together about one and a half years ago.

Originally these assets were meant for purpose of a more governance oriented project, where $JBX holders can stake their tokens and get veBanny NFTs in return to vote in governance with the weight proportionate to the duration and quantity that they have their $JBX locked away. That project had never been put into production for some reason.

In that period of time, JuiceboxDAO had been pursuing the prerequisites for sturdiness of the Juicebox protocol, such as protocol versioning, security related work, risk mitigation work, and recently the Revnets, there had been somewhat more prioritized prerequisite that put this Banny art project to the back burner.

Jango, Mieos and Lurkmoth met and decided that it's time to pull Bannyverse out and re-apply it for the current moment. They started to broom over how Banny might live on screen in a less Web3 NFT specific environment, but rather as a relatable character to help tell the Juicebox story. The current efforts are focused on how things can be weaved together, which have been refined and discussed in the form of a proposal with JuiceboxDAO over the past few cycles.

The Bannyverse will start with the manifestation as a collection of naked Bannies that people can mint on Ethereum mainnet and Optimism, which hopefully in the future we can scale it up into any number of chains.

Four tiers of naked Bannies serve as the base character with different rarities, and Mieos will lead the effort of curating various Banny outfits and other fun things in the future, so that owners of naked Bannies can buy accessories and dress their Bannies as they like. These collections of Banny will be accompanied by the animation series produced by Lurkmoth, and together they are going to get the words out for the Bannyverse.

Thankful for the support from JuiceboxDAO, the Bannyverse will hopefully have a good starting point, but we also expect it to create a virtuous circle and bring attention back into the Juicebox culture, along with more contributors, new projects and new ideas. We are open to the unknown future of whatever happens.

Unit Test for Juicebox V4 Updates by Nowonder​

Nowonder has been working on unit tests for Juicebox V4 protocol, by basically covering all the logical branches of each contract in the most minimal way possible, which basically means deploying a single contract that will make other calls to other contracts, mocking those calls and returning data to make sure that all of the logic makes sense. And given Juicebox V3 protocol being a concrete piece of software, he expected that what to be found will at most just be a few optimizations. But he also said that when changes are made to the implementation in the future, the unit test will help inform exactly what has changed, so that we can be sure those changes are safe.

Jango expressed his gratitude that this kind of work had been the only reason that we can play at these higher level of artful abstraction, because we have this splendid community of contributors doing a lot of under recognized work behind the scenes. It's a really important piece of work to allow us to play these artful abstraction.

Nouns Proposal 493 Updates by Matthew​

The Nouns proposal 493 to donate 40 ETH to the Free Alexey & Roman project to support the legal defense of the two Tornado Cash developers has been approved by a high margin. This is the first proposal that has ever been passed to actually pay a Juicebox project directly from the Nouns DAO treasury.

Unfortunately, due to some bug in Nouns's governance front end, the transaction to execute this proposal failed. Although a fix has been deployed to this problem, the proposal still needs to be re-submitted and voted for another time. Matthew said that he was not worried about going through the process again as the votes for the last one were overwhelmingly in support.

Matthew and Brileigh thought that they could convince other DAOs to support Juicebox projects if they are good and have potentials, and it was just a question of making the right inroads with the communities and the right people over there. They will be trying to run the same strategy with larger DAOs like Arbitrum and Optimism, etc., hopefully to get more DAO treasuries to interact directly with Juicebox protocol.

Deploy Plan Updates by Jango​

Bannyverse​

The pieces that we now need for the deployment of Bannyverse revnet include media content, naked Bannies, outfits of Banny, education materials, as well as some more efforts in the respect of outreach, social media and marketing.

The timeline for Bannyverse's deployment will be:

• Target testnet production candidates will be deployed on Ethreum mainnet, Optimum or even Arbitrum around February 12th;

• The production deployment will be February 17th - 20th.

There are a lot of prerequisites and other things that make up this release, so it will be a coordination amongst lots of people and lots of delicate pieces of infrastructure. The timeframe above will be 3 weeks away for the team to really push this project through the finish line, getting all the things deployed on testnets, well tested and looked over as many times as possible, before officially launch this very scoped experiment.

The idea of Bannyverse being the first project stems from the consideration that Banny can probably do a better job than any of us in explaining what is going on with Revnet and Bananapus. Through the Banny NFTs and this cultural tidbit, and a matter of engagement with the art and a few buttons on screen, we can hopefully convey to new users all the powerful tools which can then be scaled to solve arbitrary other problems in this ecosystem.

At this moment, the team is still working on some early prototypes of what the experience of interacting with Bannyverse will look like.

Revnet​

Currently Aeolian is working on the development of the website of Revnet, revnet.app. There might still be some framework things to get right, get tight and get ready.

And from a UX perspective, we need the support of setting different stages in a revnet, which is the only things holding Revnet from being able to support Bannyverse into production.

The specific websites revnets like Bannyverse will be trying to tell their own different stories, but they will also have links back to revnet.app if people are more interested in the financial models of those revnets, or if they have $BANNY or other tokens and they want to access the revenue of those networks.

$Bananapus​

From a Bananpus perspective, we need fee-collecting project No.1 on Ethereum mainnet, Optimism and/or Arbitrum, wherever we want to deploy the protocol. We need the fee-collecting treasury to work and be there.

There is this swap terminal developed by Dr.Gorilla, which helps a project to allow anyone to pay any token to it, while swapping into the token in which project's accounting is based on. With its deployments in multiple chains, Bananapus needs a swap terminal because it doesn't know what tokens people are going to paying their fees. It might not always be ETH, but rather the native tokens of those different chains. So we want to make sure that Bananapus, as the fee collecting project, has a swap terminal attached to it and can scale to accept fees in various tokens.

Another piece of infrastructure we want for Bananapus is the Cross-chain Sucker, which is mainly developed by 0xBA5ED. A project would take in revenue on any chain, and then that revenue and the token issuance will get sucked down to the main network where the project's token is being issued. Obviously this infrastructure is necessary for selling Bannies on multiple chains, as well as Bananapus project's fee collection on multiple chains and having them all puddle back to the $NANA tokens, where JuiceboxDAO will have its main exposure after the deployment of Bananapus.

Other less technical but more social things that we could get a step forward on, would be the partnerships with other chain environments, such as Optimism, Arbitrum, Base, Zora or any chain we end up going. We will bust through the front doors, they can have a headsup and do whatever they want, if they want to help drive traffic at that point in time.

We will put a lot of efforts in testing out Bananapus. When we scope Bananpus down to revnets, we basically will remove 3/4 of the Bananapus code base from an attack surface perspective. By starting with one project, we can really focus the tests down the line to make sure this works well for all other revnets.

Others​

Most of these pieces have been pretty much lined up, and it's just a matter of getting them through the door, making them look nice and fit in with everything else, making them easy to read and be documented, etc.

During this cycle, Jango submitted a proposal which suggests JuiceboxDAO to pay 40 ETH in the upcoming Bannyverse revnet and get some naked Banny NFTs and $BANNY token. Jango also said in the town hall that, whether or not the proposal gets approved, JuiceboxDAO will have skin in the game from a perspective of a brand equity, and from the scheduled allocation of some pre-mint $BANNY tokens for JuiceboxDAO's early investment and support in the development of Banny.

Filipv suggested that we should have someone to write the grant proposals to different L2 chains such as Optimism or Arbitrum for Bananapus and Revnets, which can be a time consuming effort as those L2s might have different in-depth procedures to go through. Jango said that we should focus our efforts on Optimism in the beginning, as that's where Banny NFTs are going to be sold first. Matthew and Brileigh both have some experience making grant proposals and they were going through the process to help the project Free Alexey & Roman gain more support with Arbitrum, they expressed their willingness to help out in this respect.

Nouns Proposal Updates by Matthew & Brileigh​

Matthew and Brileigh managed to get a Nouns proposal for the Free Alexey & Roman project, which is to support the legal defense for the two Tornado Cash developers, submitted in the Nouns community and it advocates NounsDAO to pay 40 ETH for this project.

Matthew called on our community members who might have any connections in the Nouns community to help get more support for this proposal. He said that it would be a huge success to see the Nouns community to come together to help defend the right of publishing code and privacy, and also it would be very cool to have the Nouns treasury actually pay a Juicebox project for the first time and interact with the Juicebox protocol.

Matthew also shared a voting note written by a dev called brennan.eth from the Nouns community. Matthew expressed his great recognition for this article, that it articulates very well some of ideas at play, and shows that people really do care about what we're working with the Alexey and Roman campaign.

V4 Naming Changes Updates by Jango​

The fork of Juicebox V3 protocol by Bananapus has been officially cleaned up, the only thing left over is the language touch-ups pull request. This pull request covered 95 files with renamed words, and there is no implementation changes in the contracts.

This has all been the hard work by Filipv during the past several months, and the changes have also been reviewed in our previous town halls and relevant discussion threads.

During this town hall, Jango introduced some of the top-level changes that have been made in this pull request, and said that he was quite certain that we would run into these changes as folks start integrating with the experimental V4 protocol over the next few weeks when the protocol is deployed on testnets.

Rulesets​

Funding cycles are now changed to rulesets, so we can talk in terms of what the project's current ruleset is and what the queued rulesets are.

Now the V4 protocol supports multiple queuing of configurations, project owners can queue multiple different rulesets over time, for example, they can deploy their projects with clear instructions on how the rules should change over the next year in various different ways. Jango was very excited to see what folks might end up building with this open-ended feature.

Tokens and credits​

We used to make distinctions between the different states of tokens by unclaimed tokens (those tracked and accounted for within the protocol) and claimed tokens (ERC-20 tokens under the custody of their holders), but we now instead calling them credits and tokens respectively.

By default, when projects receive payments, they will distribute credits in return to the payers. If project owners choose to issue an ERC-20 token or bring their own tokens later on, then the credits can be claimed into those tokens.

Decay rate​

We now use decay rate instead of discount rate to describe the decreasing cadence of token issuance of a project over time.

JBPermissions​

We change JBOperator to JBPermissions, where project owners can delegate other addresses to manage vaious parts of the contracts on their behalf. Also a root permission is introduced into the contract, so that project owners can give someone else permission to do everything on their behalf, including adding other permission for different operators.

Game Plan for Bananapus by Jango​

When the merging of the language touch-up pull request is done in a short period of time, Jango will deploy the V4 protocol on Ethereum Sepolia testnet and Optimism testnet, which means deployments on both an L1 and an L2 blockchain.

The game plan is that every week on Sunday night, Jango will collect all the approved changes that have been workshopped during that week, and redeploy the contracts if necessary, so that every week we will basically start clean and iterate on the latest version.

There will be some PRs that will be created throughout the weeks, things like language related touch-ups, small implementations, or other optimizations that have been on our minds, will make their way into the contracts. We will be playing the role as incubators of the deployments on testnets, and we can make the change logs very clear on a weekly basis about what has been changed.

We will also be continuing to add a lot of tests to make sure the contracts are as good as we can get them, together with a documentation of very high quality.

And then every week we will add one of the new features that we have been working for the last several months, bring them into production and fold them into the protocol. The addition of features will be carried out one step at a time, according to the plan shared by Jango in the discussion.

Swap terminal is a component that allows projects to receive payments in any cryptocurrency. The received cryptocurrencies can be swapped into the project's treasury asset currency, which will be great for collecting fees in various tokens.

The sucker facilitates cross-chain token transfers between projects, using a messenger for communication and a redemption mechanism for token exchange.

Revnet Testing Sessions by Jango​

As there are many people want to run revnets for their projects, and we are also preparing for the first cohort of revents, so Jango expects that we will be doing more testing sessions for revnets. We will get together and start to workshop how to configure a revnet and test it, which will be a reciprocal situation, as it also can be very helpful in improving the language of cntracts and the overall fuctionality of V4 protocol.

Hopefully towards the mid or end of January next year, we will have a production candidate that can be used by various potential revnets, such as $NANA, Revnet, Defifa, Croptop or Juicecrowd, for purpose of testing or experimenting their own projects.

Project Updates by Filipv​

Filipv said that the CryoDAO project was doing some pretty exciting stuff, and he encouraged our community members to join their Discord server and get more involved.

The Roman Storm project is planning to launch with the next week. And Rene from Artizen is also planning to do a launch essay and promotion for the Artizen project in the same period as well.

Telegram Group by Jango​

Jango introduced that there is a Telegram group now live for $JBX discussions with more inclination toward token trading matters. Jango said that as he had got off the recurring payroll from JuiceboxDAO recently, he would be willing to get more involved with he JBX storytelling and education work over the next short period of time.

And he thought that when folks are asking good questions, it would always be nice to show up and answer them in an honest way and reveal the right risks, while at the same time introducing the right opportunities of the things we had been working very hard on. We will all acknowledge how powerful $JBX can be.

Juicecrowd Updates by Matthew​

The Juicecrowd Dapp has been deployed and running for several weeks. And the Juicecrowd team, Matthew, Brileigh, TJL and other Peel members have launched a Juicecrwod program to assist projects with a Web3 or blockchain vision in organizing their funding campaigns, enhancing visibility, and catalyzing community growth.

As of now, the first cohort of Juicecrowd projects have all been meticulously crafted and put into operations on the blockchain.

The Juicecrowd team has also offered some incentives for early project supporters, which include an exclusive airdrop of commemorative NFTs made by Sage and Strath, along with an opportunity to participate in a raffle for 250,000 JBX. The deadline for early supporters has been extended to Nov. 08, 2023, making sure that more people can engage with and contribute to all the JC01 cohort projects.

Matthew called on our community members to share out the projects and spread words for them. He also introduced that the team would be working closely with these projects to amplify their outreach, so as to get more support or even secure grants from other platforms.

Filipv thought that a lot of the projects in this cohort seemed to have great potential, and he was excited to see which projects could gain their momentum and realize their growth in this program.

Bananapus Fork Updates by Jango​

All the open changes that we are merging and getting ready for the Bananapus deployment in testnets have all been consolidated onto the main branch of its GitHub repository.

Presently there still remain two pull requests open for merging. One involves the language adjustment scheme that Filipv has been working on for a while. These changes have also been reviewed on our previous town hall sessions.

The other pull request focuses on enabling meta transactions on payment terminals, which essentially allows clients to have more flexibility in choosing their relayer nodes. With meta transactions, an end user can sign a message indicating their intent and pass it to a relayer, which in turn submits a transaction and pays gas for its execution on behalf of the end user, while contractually all of the accounting related to the transaction's message sender remains consistent and accurate.

Once this very exciting batch of work gets consolidated in the next few days, Jango expect that this V4 fork of Juicebox protocol can be deployed on Optimism and Ethereum testnets by the end of the week. After that, we will be able to use it as the core protocol dependency for the Revnet contract, the Defifa contract, the 721Delegate contract and the Croptop contract. All of these applications will also be launched on testnet for their final testing shortly after that.

Then we will carry out comprehesive testing in the December, while at the same time turning our attention to the web clients such as revnet.app and defifa.net, which will all be integrated into their respective testnet deployments to allow us to try out and test for any possible bugs.

There is another matter noteworthy according to Jango, the team has restructured the payment terminal architecture to facilitate a single payment terminal managing multiple token accounting contexts in the future. The Bananapus fork will be implemented with a vision for multi-terminal and multi-token accounting, catering to the needs of projects and multi-chain organizations.

Token Table Revnet Development Updates by LJ​

The TokenTable team was granted some funds to develop token unlocker contract and Telegram bots tailored to the use of project creators and contributors on Revnet, as outline in proposal Fund JuiceTable (TokenTable) team to co-develop with the RevNet Core Team, which has been approved by the DAO. The products are expected to be delivered in three sprints with the DAO's grants distributed accordingly.

LJ reported that significant progress had been made in the first sprint, encompassing the creation of the Telegram bot Figma wireframe, and feedback from the community has also been actively incorporated into the development. They planned to put more ideas into written form about Revnet shortly.

Nance Updates by Jigglyjams​

The Nance team is working on a new create flow, which will be ready early next week, anyone who has a new project and wants a Nance space for automated governance can reach out to the team. It would be ideal to have some real users to actively engage with and test out this product.

Banny Warhol Updates​

Jango introduced that the Banny Warhol channel in JuiceboxDAO's Discord server has realized a significant update. Now, users can engage with the Banny Warhol bot to create Banny-related images or inquire about the Juicebox protocol by simple providing relevant prompts or question.

Jmill, Genekogan and other Eden team members are in the process of transforming their generative art service into a platform capable of crafting characters for users. Initially they are starting with Banny as a prototype for this innovative transitioning.

What Jmill shared in the discussion better explains their vision in this venture, "We’re moving towards a self-service character system, with potential for a character to speak as, know about, and create visuals in the style of whatever you want. "

Jango thought that this is a tool of incredible potential. Beyond its applications in making images, project logos, or entertaining contents, it also has the potential to help shaping and expanding the concepts surrounding specific characters, such as that of our Bannyverse.

Filipv said that Stable Diffusion recently unveiled a new model of SVD (Stable Video Diffusion), if that can be integrated into Banny Warhol in the future, it might be able to deliver some very impressive results.

MoonDAO Updates by Jango​

MoonDAO was established on Juicebox protocol roughly two years ago. After their successful fundraising campaign, they aquired two tickets to space on a Blue Origin spaceship. In August of 2022, They managed to send a person into the outer space on the Blue Origin, which was a feat first done by a DAO.

Last year MoonDAO also held a contest of randomly drawing a winner of its Ticket to Space free mint NFTs, the winner, a MoonDAO member from China called Yan, won the second ticket to space. But Yan has not been able to get a visa to go to the U.S., even with the multiple efforts to help by MoonDAO for a very long period of time. Finally the community decided that they have to re-raffle the ticket and get another community member to take this trip to outer space.

MoonDAO is also working on a lot of projects, and they have close relationship with institutions like NASA. Pablo, one of the founders of MoonDAO, is very dedicated to their mission with the ambition to go to space and put a base on the Moon. At the same time, Pablo has been staying very close to the stuff that JuiceboxDAO is working on recently, and sharing some ideas from their perspective. In the town hall, Jango expressed his admiration for MoonDAO and Pablo for their persistence in pursuing their goals.

Juicecrowd Updates by Matthew​

Juicecrowd JC01 program had received applications from 35-36 projects by the time of this town hall. Matthew called on the community members to help spread the news and refer some projects they know to apply for this program.

Peel JuiceboxDAO contributors will be able to vote on the projects to help select which projects will qualify for the JC01 program. The Juicecrowd team will be working with the first selected cohort of projects, which will be launching their Juicecrowd projects on Nov. 17th.

Next week the team will hold seminars for one or two hours each day and invite the people in the first cohort to talk about how they are going to strategize their fundraising campaigns, launch their projects and promote them and get more visibility. Tjl, Brileigh and Matthew, and probably some other contributors will be sharing some information for crowdfunding by way of some kind of curriculum during that period.

After all the projects are launched, they will be running until Dec. 15 to compete for their fundrasing outcome. Top 3 projects will get awarded from the prize pool of 3 ETH.

Bananapus and Revnet updates by Jango​

The short-term roadmap is to get Mainnet and Optimism depolyments by the end of this month, which will likely be running on the testnets through the rest of the year, while the team will continue to write a lot of tests and documentation, make sure everything is good to go, and use these deployments in pseudo production environment.

Here under is the work expected to be done by next week, which will make sure that we will see the end of the month get us to a solid testnet deployment with everything running Revnets for this Bananapus experiment. That will allow us to run testnet implementations for anyone who is interested in framing their project as a Revnet.

Jango said the team used to be expecting a Code4rena audit contest for the contracts of V4 protocol, which would be a scoped updated fork of Juicebox V3 protocol. But as Code4rena had quoted us a cost of US$80,000 for this audit, it did not feel very worthy of doing it anymore. Instead we would be providing some incentives ourselves and invite auditors whom we are familiar with or folks from around the ecosystem who want to help review this well-written and well-tested set of repos, in order to get the project as tight as possible for a mainnet deployment after the holiday season.

Juicebox V4 Naming Updates by Filipv​

During the town hall on Oct. 17th, Filipv shared the updates for the naming scheme of V4 protocol, which will be the fork of Juicebox V3 protocol by the Bananapus project. Filipv provided some possible choices for the names and explained the reason about their re-naming, before making some simple polls in our Discord channel and let people make their choices and leave their feedback.

Last week, Jango met with Filipv to go over all the feedback from that town hall, and made some changes from it. In this town hall, Filipv were presenting the revised versions and asking for further opinions or reviews for them.

JBTokens​

When a project deploys the claimable token using JBTokens contract, which is the default implementation of that contract, those methods will be called with ERC-20 added to their names, like deployERC-20TokenFor(...), while references to other implementation will be called just token as in setTokenFor(...)

We are now making distinctions between tokens internally mapped and actual ERC-20 tokens by calling them unclaimed and claimed tokens respectively, which has been pretty confusing for a lot of people. Jango suggested that we call the unclaimed tokens as "token credits" which can be claimed as actual tokens at any time in the future, and call thoses actual tokens just "tokens" to clear up the ambiguity.

JBRulesets​

People seem to pretty widely support the idea of changing Funding Cycle to Ruleset, which is just a set of rules within a fixed or infinite length of time. So for example, we will be changing the JBFundingCycleStore to JBRulesetStore.

What is now called the discount rate, we will be calling it "decay rate", because it is like the decay of the issuance rate or the weight that issuance is based off of.

JBPermissions​

This contract is currently called JBOperatorStore, with which permissions can be granted to other people to manage the project or interact with the protocol on behalf of the project owner. It makes more sense to rename it to JBPermissions, but the operator term is still useful in names of methods such as setPermissionsForOperator(...), which will clarify things a bit better than setOperator(...).

JBController​

We are changing some things just to make it a little bit clearer. For example, reservedTokenBalanceOf reads the number of reserved tokens that are pending distribution, so renaming it to undistributedReserveTokenBalanceOf sounds more clarifying.

Payout Limit​

The idea of going from distribution limit to payout limit seems pretty widely supported, which expresses the maximum amount of ETH or whatever currency that a project can pay out from a terminal within one cycle.

Runway vs. Overflow​

This is a possible change that was still quite controversial in this town hall.

Jango thought that overflow is a fun Juiceboxy word, like a juice glass that overflows, and it conveys the idea that when something fills up, there will be excess and it overflows. But also a lot of projects read overflow as runway where projects have periodic payouts or pay obligations and whatever is left over is the project's runway. It's neat to communicate that a community of funders constantly has access to the runway, otherwise the project can make use of it, depending on how the project is configured.

Matthew felt that runway tends to give an overtone of how long a project can continue to exist, and it does not immediately have the meaning of the excess of project's payouts, whereas overflow do.

Filipv thought that runway feels easier to convey to people who are going through the create flow for the first time that they can have their payouts and everthing beyond that is the runway of the project. And if a project has a lot of extra runway, it can be redeemed by the community with their tokens. Also people conceive of runway as the future amount of funds that will be available for the project.

Terminals​

We are shortening the names a little bit for terminal, like from IJBPaymentTerminal to IJBTerminal, as the basic implementation for terminals are just supporting payments.

Because the V4 protocol will be deployed on multiple blockchains, a lot of the ETH terminology will need to be changed accordingly, such as changing from JBETHPaymentTerminal to JBNativeTerminal to go with the native tokens of those target blockchains.

Compared with JBERC20PaymentTerminal, JBERC20Terminal makes more sense, because there are other things can be done through this terminal.

JBERC20Token​

Currently this contract is called JBToken.

JBProjectPaymentForwarder​

This contract is currently called JBProjectPayer, which forwards inbound ETH payment to the projects. We think that forwarder makes a lot of sense in this case.

Hooks​

We were thinking of how to more clearly communicate the pattern of data source and delegate, which is something that has been confusing for people from time to time. In the polls in last discussion, people seem to think "hook" makes a lot more sense in many different programming contexts.

Data source is the function which provides data to the pay function beforehand, and delegate actually takes the action after the pay function or the base pay logic goes through. We decided to break these down into "pay data hook" which provides data and "pay action hook" which takes the action. And the same goes with redeem data hook and redeem action hook, etc.

The current Ballot is a contract that checks if the conditions are met before a funding cycle is approved, it can be defined with whatever behavior that is desired. We think that by putting these all in a framework of hooks, we can make it clear that people can write their own verions of these contract and extend the protocol easily. For this reason, "Ballot" will probably be called "Ruleset approval hook", and "State" which depicts the status of approving or rejecting can be better expressed by calling it "approval status".

Artizen Updates by Filipv​

There were around 75 projects that had gone through Aritizen and qualified for the Juicebox Project Accelerator Fund.

Filipv thought that there was a bit ambiguity in the rules about how the project would qualify for the fund. It would be nice to have projects meaningfully distribute the ownership or governance to their community through Juicebox in the future events.

The projects which have been coming in through Aritizen were mainly art project, it was really awesome to have them on Juicebox. But some of projects are already within crypto and have their tokens, a lot of them don't really have a strong need for using Juicebox at this point. So he suggested that we follow a stricter set of requirements for similar events like this in the future, so that project would more meaningfully make use of Juicebox instead of deploying a project and leaving it there.

But all in all, Filipv thought that things had been pretty great, and there were a good number of promising projects. He also thought that the Juicebox Project Accelerator Fund is probably one of the best grant spending we have ever done, there could be some pretty cool stuff that comes out of it.

State of $JBX by Jango​

On the town hall, Jango went through the article he recently wrote on his reflections on JBX, which can be found here.

Jango felt that with the Buyback delegate being installed, it was a good time to reflect on where we are as a community that has governance responsibilities and also manages a treasury provided by JBX holders. We had been using this treasury to do all the marvelous things, but every now and then we would need to stop and reflect.

Thanks to the patience of all JBX holders, the army that gets us where we are and pushes us forward, we managed to sort throught a lot of versioning work to allow us to really make these big strides from a protocol perspective. It will also take patience to understand where the user experience is, so as to have folks start projects, build their communities and determine what their community needs are.

We now have about a million US dollars worth of ETH in the treasury, with the payout cadence of around US120,000 every two weeks on the current schedule. We've accomplished a lot over the past few years, but we are in this moment of figuring out how to use this $JBX to really power us through to this next chapter of what we're now trying to get to, which includes projects like Bananapus, Revnets and Juicecrowd, etc. It's very much a continuation of our work, but we'll also have to figure out what levers we should renegotiate to really unleash the potential energy here.

In the blog post written by Jango, he reflects on the two value propositions of $JBX, a token that is backed by ETH in the treasury, and the token that governs JuiceboxDAO and all its assets.

$JBX as an asset ETH-Backed Asset​

$JBX gets issued whenever there are funding coming into the treasury, they can also be burned to get funds out of the treasury.

After the deployment of buyback delegate in October, inbound payment will be routed to buy back tokens from the AMMs until its market price catch up with the issuance rate, so that payers get a lot better yields in exchange for what they paid, and reserved token recipients now also have better incentives. But if investors want to get the best deal for JBX, they should buy on AMM instead of buying on protocol, because that way they will bypass the reserved token issuance.

Over the past period of time, we have been spending from the treasury, so $JBX is backed by less and less ETH in the treasury and the price floor has been somewhat dropping as we spend more.

$JBX as a Governance Token​

$JBX as a governance token has also seen a wild journey over the past few years, from not being a thing at all, to now having a very predictable cadence to conduct the cycles, participate and execute, which is a massive progress for us all as builders to get to where we are.

We also have a fairly sizable $JBX balance which has been sitting there mostly for the past while. It's our biggest asset apart from the ETH in the treasury. Jango thought that we could be a lot more creative with how we use this $JBX balance to empower the network to propel itself forward.

Jango's observations and Suggestions​

We've finished building a lot of the fundamental technology that allows us to facilitate this financial fabric in money in various ways. Jango thought that we are starting to recognize that we have to figure out how to grow very productively. At the same time, we have a responsibility to manage the ETH left in the treasury in a way that is productive to move us forward on this mission.

If we want to empower $JBX, we have to add to $JBX as opposed to reducing its bottom line. It's a tightrope walking, because both are important. We want to push forward and the work that we do needs our time, focus, attention or love to get it there. We have to find that balance, if we don't, the balance will be found for us.

He also suggested that we remove individual entities from the reserved rate and have more reserved tokens go to the treasury. Then everyone will have to play a similar proposal game, which is a lot more scalable than having individual entities on the reserved rate list.

Takeaway​

Jango thought that it was an opportunity to really think creatively as we move into the future. It might be a little bit of growing pains along the way, but that's normal.

Jango said that he would try his best to lead with proposing things along the way, trying to shape things and build relationships with outside investors and other communities so that there would be forward momentum from a financial perspective too.

Discussion about JBX's liquidity pool​

LJ asked what Jango's opinion was for JBX on the secondary market, since the current liquidity pool for $JBX was quite shallow. He agreed with Jango's idea of utilizing JBX versus just spending ETH from the treasury, but he thought that we should be also thinking about the secondary market for$ JBX, since an active secondary market might help driving in more attention and bringing more retail users to the platform.

Jango agreed that adding more liquidity allows for more price stability, but the prices on AMM are temporary and may fluctuate from time to time. He said that the price that we can really rely on is the price floor, i.e. the backing value for $JBX, everything else is just a consequence of the work we do in telling the story and making JBX a desirable part of either of value propositions mentioned before.

Crowdfunding for Medical Bills by Felirami​

Felirami recently launched a Juicebox project called Web3 Aid for Mom's Recovery, to raise fund for his mother who got seriously ill and hospitalized in ICU of a hospital.

On the town hall, he expressed his gratitude towards the Juicebox platform and those who had donated to his project. But he also said that he had been having issues reaching out to more people in order to get more help to pay the medical bills for his mother.

TJL said that as we were currently working on the problem of helping projects better tell their stories, craft more incentivizing reward, market and launch their projects, he invited Felirami to join the Juicecrowd Discord and offered to take him through the recent Juicecrowd 01 program. Hopefully Feliram might be able to take what he wants from an education perspective to improve his campaign and get more visibility.

Juicecrowd Updates by TJL​

Peel team identified that there were too many types of users for juicebox.money, which was causing a lot of complexities, so they wanted to see if they could come up with a product that counld better cater towards the crowdfunding users and ensure a higher level of success. For this reason, Peel team set out to build a more focused DApp for crowdfunding, which is now called Juicecrowd, to help bring in a higher caliber of quality projects and have a more holistic look at what a campaign actually is.

Peel really started looking at what makes a campaign successful from a holistic perspective, such as their story, their mission, their vision, the way their project is structured, how are contributors incentivized, how they are marketing. Together with the more tightly focused DApp Juicecrowd, they also kickstarted a program to recruit cohorts of high quality projects and help them with all the components of their crowdfunding campaign.

By the time of this town hall, they had successfully got 16 projects submitted to the JC01 program. They also extended the deadline of application by projects to Nov. 8th, in a hope to get around 20 projects to submit their application.

TJl expected that they would have a test project up and running by the following week, while the program will start in two weeks' time.

Also he praised Matthew and Brileigh for what they had done to get this program launched and projects applying for it, and Wraeth, Aeolian and JohnnyD for their great job to pull together the basic parts of the project page of Juicecrowd.

Juicecrowd Poster and Mint by Matthew​

Sage and Strath collaborated to make the poster for Juicecrowd 01 program, and this posted had been put on Zora for free mint. Matthew thought that we should keep trying different strategies to find a place on-chain for some of the art that gets made, instead of only being shown on our website.

Jango thought that the poster game had been incredible, and he sees Juicecrowd not only as a dedicated product for crowdfunding, but also as an exercise of setting time boundaries and pushing towards it, as well as making creative moves in promoting it.

Revnet Introduction by Filipv​

In the website that Filipv made for the simulation of Revnets, he recently updated the detailed introduction to what Revnet is and why people may want to create and make use of one. Filipv said that he would try to make this information as generally applicable as possible.

Artizen Project Updates by Filipv​

Last week a slight issue occurred with the front end while Artizen project was being reconfigured by its project owner Nene and Filipv, this error led to an unintended 100% redemption rate in the project's configuration of its new funding cycle.

To avoid any unexpected behavior in this project, a decision was made to archive this project and create a new Artizen project with the correct configuration to replace it. As the old project was configured with a duration of 101 days, the funds inside can't be retrived temporarily, Jango and Filipv decided to put forward their personal funds to the new project instead, and they will submit a proposal to get reimbursement from the DAO later.

The error has been mitigated with a PR created by Wraeth and JohnnyD, and the whole process of treatment of this issue written by Filipv can be found here.

Tjl would be meeting with Nene to go over the submissions for the Juicebox and Artizen Match Fund, and he would report back if there are any updates afterwards.

Bananapus Updates by Jango​

Jango said the V4 protocol, which is a fork of Juicebox V3 protocol by Bananapus, would probably be finished by the end of this week. The week after that, the contract crew will be in a mode of heavy reviews. After the reviews, he would expect a Code4rena audit contest be arranged for the Bananapus contracts.

Hopefully, by the end of November, the Bananpus project will be going live, at least on test nets first. Thanks to the reviews by Nowonder, 0xBA5ED and Dr.Gorilla, Jango said he was very confident about the contracts and their deployment in the near future.

Origin Ether Integration by Slagathor​

Slagathor from Origin protocol mentioned his interest of integrating their Origin Ether token on the back end of Juicebox. According to his introduction, Origin Ether is a yield aggregator on Ethereum mainnet, essetially a token backed 1:1 by both ETH and several LSDs(Liquid Staking Derivatives), and the collateral of their users would be deployed across a handful of protocols for yield, while the yield gets passed back to the holders.

Jango said that we were making the foray into multi-chain and going to support multiple tokens in a very scoped way, so hopefully in the near future we might be in a position to give Origin protocol some more straightforward path to integrate their tokens into Juicebox without needing any permission.

Bananapus Updates by Jango​

The fork of Juicebox protocol that will be used and deployed by Bananapus project is still under development in its GitHub repo. The most important PR will be the multiple funding cycle queuing, everything else will be out of convenience for integrators and multiple currency.

According to Jango, the V4 fork of Juicebox by Bananapus will be deployed on Ethereum mainnet and Optimism together, after they are tested in the respective testnets there.

The specific roadmap of Bananpus development can be found in Jango's proposal for grants to Bananpus project, which has been approved by the DAO in our last funding cycle.

The complicated part will be the rewards component of Bananpus. Jango thought that we could get it really tight and sensible, so that people can get paid as the networks that they are staking with grow.

Filipv said that the front end that is currently in the Bananpus GitHub, the bananapus.com repo, was originally meant to be a basic testing front end which allows interaction with the contracts for one project. If the Bananapus is used by many projects across multiple chains, the current design doesn't really scale for that purpose and we might need to develop something more robust.

Juicecrowd Updates by Matthew​

We now have a project applying for the Juicecrowd 01 fundraising program. This project is called Brume Wallet, which is aimed at developing a private Ethereum wallet with a built-in implementation of Tor protocol.

Matthew expected that we would see some more projects to submit their applications when it is getting closer to the deadline of this program, which was set as Nov. 1st, 2023.

He introduced that once they have received all the submissions by the deadline and chosen which projects would be in the cohort, they will open up the project creation flow to those selected projects. After all the Juicecrowd projects are made, they will be curated on the the Juicecrowd page.

Although the eventual goal of the Juicecrowd dApp is meant for a fully permissionless project creation, the team wanted to start with cohorts of projects. The idea is to to keep a very high quality of early projects that are using Juicecrowd, and the team will be giving all these projects a lot of support, guidance and making them as successful as possible, so that Juicecrowd can have an excellent track record of successful fundraising which hopefully will help bring it to a bigger audience in the future.

The projects that are going to be launched on Juicecrowd run in exactly the same way as they are created on Juicebox.money, except that the Juicecrowd project creation flow will be more simplified and tailored specifically to the needs of crowfunding. In terms of tokenomics, there will be no ERC-20 tokens issued, so contributors will likely receive an NFT to verify their contributions to the projects.

Matthew, Brileigh and Filipv also discussed about the possibility and potentials of having some kind of cooperation of match fund with different crypto organizations, or applying for grants with multiple L2 chains like BASE, Arbitrum or Optimism, etc. They agreed that it might be worthwhile to at least try to reach out and expand the operation of Juicecrowd to other L2s in the future.

Buyback Delegate Updates by Jango​

The buyback delegate has been deployed to the JuiceboxDAO project for some time now, Jango said it has been working great till this moment. He was going to make a proposal to fine-tune the parameters of the buyback delegate and add more liquidity to the relevant AMM pool.

If another project wants to use it, we could work with them to fit that together too. When all the revnets are launched in the near future, they will also have buyback delegate baked in automatically. So we will be expecting many more of it gets put into actual use.

Peel, our front end team on Juicebox.money, is also making good progress to display the actual token swapped from the AMM pool when buyback delegate is put into action.

Governor Contract Implementation Discussion​

Jigglyjams was wondering if there would still be some interest in using governor contract for the Bananapus project.

Jango said the current Bananapus Juicebox project is temporary and just to manage the development of Bananapus. Its governance was meant to be on-chain as an experiment of Revnets, which are unowned projects without need of governance.

But JuiceboxDAO is expected to receive a lot of $NANA token from the Bananapus Revnet after its launch, and these tokens will be managed by the JuiceboxDAO multisig. While this is not something to worry about in the near future, Jango expressed his interest in exploring the possibilities of on-chain governance with the $NANA holding by JuiceboxDAO in a long run. If Bananapus project works and JuiceboxDAO sit with a lot of $NANA tokens, something also needs to be done, by either distributing them out to $JBX holders, governing together or doing some kind of token swap thing.

Jango thought that the end game is certainly not six persons on a multisig carry out executions on behalf of the DAO, but rather the opportunity we get to play with an on-chain implementation of governance. The idea of locking the tokens for a long time and not having access, or making access more formal, makes a lot more sense in the post-multisig experimental direction. But he thought that Revnets will be the final goal to put our effors towards.

Juicecrowd Updates by Tjl​

During the time Peel team had been building our website juicebox.money, they noticed that in some crowfunding specific cases, projects tended to need assistance to get some traction after they were launched, while some of the features on juicebox.money weren't very relevant for those purposes. So Peel team created a new DApp named Juicecrowd for this scoped purpose of crowd funding.

With the deployment of this Juicecrowd App, they also launched a program called Crowd, which will accept submissions from cohorts of up to 10 projects at a time, help them create and polish their Juicebox projects, and support their propagation and give as much visibility as possible for an interval of 30 days, so as to help them get momentum and funded.

Shoutout to the Peel team for their great work in the past two weeks, to the efforts of Matthew and Brileigh for creating this Juicecrowd 01 program, and also to the support from Filipv.

Artizen Partnership by Nene​

The proposal of setting up a match fund between Juicebox and Artizen has been approved.

According to Nene, Artizen had launched the Season 3 competition of Artizen Fund, and they had over 50 projects qualified for the Juicebox Project Accelerator. The next steps would be onboarding those projects and help them create their Juicebox projects in order to receive their fundings from the Artizen Fund.

Tjl thought that this would be great for the ecosystem and bring in some art related projects, while at the same time establishing a relationship with Artizen. He expected that there would be many projects coming into Juicebox and kickstarting their fundrasing journey.

Nene introduced that all the funds would go to the Artizen's Juicebox project, before they are distributed to creators through their own Juicebox projects.

Also, Nene said that they would be launching their Artizen tokens through Juicebox protocol, and he was very excited to start distributing ownership and the Artizen funds to their investors and community.

Naming Scheme Updates by Filipv​

Our contract crew had been working on a few different updates to the Juicebox protocol for some of the L2 deployments of Bananapus project. The team had also been discussing about the probability of renaming some of the names within the contracts, because some of the terminology used in the contracts was a bit different from what we used on front ends and other places, which can be quite confusing for people who are coming into the protocol to develop or work on things.

Filipv gave brief explanations to some of the current names and made polls in the town hall to let community members to vote on the names they feel appropriate.

ERC-20 vs. IJBTokens​

Filipv thought that there had been a lot of confusion over the distinction between the internally mapped tokens which are tracked in the token store contract, and the actual claimed ERC-20 version of those tokens. He suggested that we call them all by ERC-20 tokens and use ERC-20 in all of the naming and references to these tokens, while accepting that this might be slightly misleading in rare circumstances.

Jango expressed his objection to this suggestion by the reasoning that the token don't have to be ERC-20s, e.g. an ERC-1155 can be wrapped up as IJBTokenERC20.

The context for this problem goes as follows. In V1 protocol, the internally accounted for tokens were called tickets, and the token store was called the ticket booth, to make a distinction with the claimed tokens. In the V2 protocol, we decided that ticket was confusing as people just considered them as tokens, so then the ticket booth was named to token store, unclaimed and claimed tokens were used to differentiate their different state.

Project Payer vs. Pay Relay vs. Payment Router​

Project payers are the contracts which forward funds to a project, for example, when ETH is sent to these contracts they will be forwarded in the projects.

Filipv supplied some possible choices as Pay Relay, Fund Forwarder, Payment Router, etc.

Issuance Reduction Rate vs. Decay Rate​

The Issuance Reduction Rate, which was formerly called discount rate, has not proven really accepted very widely.

Filipv thought that Decay Rate might be a good alternative.

Funding Cycle vs. Cycle vs. Ruleset​

We are now using Funding Cycle or Cycle to define a set of rules of a project, which will last for an infinite or finite length of time.

Jango thought that a Ruleset might be more specifically accurate for this concept, although it will be a departure from the way we currently talk about things a bit more than Cycle would be.

Ballot vs. Approver​

Ballot contract is a contract which looks at the upcoming changes made to a project, and then either approves or rejects them.

State vs. Approval status​

The status of approval or reject by the Ballot contract is now called state, which can be approved, rejected, pending and etc.

Weight vs. Issuance rate​

Weight is a term we currently use for issuance rate, which is just the number of tokens issued per ETH in each cycle. The justification for naming it weight in the contracts, from what Filipv understood, stems from the fact that weight doesn't necessarily correspond to an issuance rate, as the contract are pretty modular and people could use that number in other ways. But as it has only been used for issuance of tokens so far, so Filipv thought that we could use issuance rate to make it clearer.

JBProjects vs. JBProjectNFTs​

JBProjects is the name of the NFT contract which mints the administrative NFTs representing the ownership of Juicebox projects.

Operator vs. Admin​

The JBOperatorStore is a contract that allows addresses to grant permission to any other addresses to interact with the protocol on their behalf. Filipv felt that we can call them admins instead of operators, as those addresses receiving permissions are actually administrating on behalf of someone else.

JBDirectory vs. JBContractDirectory vs. JBContractRegistry​

JBDirectory is a contract that can be thought of as a mapping between projects, the controllers and terminals that they are using. Filipv suggested that we add contract in its name to make it clear that it's a directory of contracts.

JBController vs. JBProjectManager​

JBController is sort of like a surface layer contract that people directly interact with, and administers project rules and tokens etc. When people launch or reconfigure their projects, they will be interacting with JBController contract. The suggested alternative is JBProject Manager.

Distribution Limit vs. Payout Limit​

The maximum amount of funds that can come out of a project in a given cycle.

Payment Terminal vs. Payment Processor​

Payment Terminals are the contracts that administer the inflow and outflow of funds for any give project. When people pay a project or redeem from it, that's the contract they will be interacting with.

Overflow vs. Excess Tokens vs. Redeemable Tokens​

Overflow is the treasury ETH assets that a project has in excess of the distribution limit in a given cycle. With the upcoming depolyments of Bananapus on different L2s, the native tokens might not be ETH, but Matic, OP, ARB and etc, so it might be wise to call it excess tokens.

Refund Held Fees vs. Unlock Held Fees​

When projects withdraw their funds out of the Juicebox ecosystem, these withdrawals will be subject to a 2.5% Juicebox fee. Projects can select to enable the Hold fees function to keep the fees in their balance without them being automatically processed. If projects return those funds in a later time to their treasury via a add to balance method, those fees will be also be canceled out and available for use of redemption or payouts by the project again.

Process fees vs. Collect fees​

Filipv thought that when Hold fees are enabled, the fees remain in the project's balance the whole time, so from the angle of JuiceboxDAO, "Collect fees" will be more accurate than "Process fees".

Data Source vs. Data Provider​

Data source is a contract that provides some custom data when someone is paying or redeeming from a project. After the payment or redemption, the data source can optionally call a delegate, a contract that implements the delegate interface or defines a function to execute a certain custom functionality.

Delegate vs. Hook vs. Callback​

The contract that will be called by data source.

Revnet Simulation by Filipv​

Revnet is a concept that Jango and others have been working on lately, the idea is to set up unowned projects which have their parameters set in place ahead of time, and those projects evlolve over time according to these pre-defined rules. Also the buyback delegate will be deployed to route payments to AMM pools when situation requires.

It can be a little difficult to reason about how all the parameters work together over time, so Filipv developed a simulator which let people put in some of the parameters to check how the revnets will evolve with the simulation. The Revnet simulator is now available at sim.revnet.app.

With the suggestion from another community member Kmac, the randomness of purchase and sales can be made deterministic by inputting the same randomness seed on the Simulation field. So with the same other parameters, the charts will look exactly the same even on other computers, which make the replication of certain scenarios much easier.

Increase the Pool Deploy Day in Liquidity Pool section by pressing the up arrow in your keyboard, you can see the animation of how these charts change over time.

Filipv was thinking of adding an option to export or important all the parameters of this simulation, so that people send them to other people and make comparisons. He said he could start with JSON file compatibility in revnet.app, and it would be awesome if Nance or juicebox.money might also eventually have support for it. Jigglyjams suggested that except for the file import/export function, he could also consider the option of encoding all the parameters of a simulation into a Base64 URL, with which this simulation can be easily recreated.

Buyback Delegate by Jango​

The buyback delegate have been installed in the current funding cycle for Juicebox and it is working as intended. Whether someone is contributing to JuiceboxDAO, or some projects is paying their Juicebox fees when they are distributing funds out of the ecosystem, everyone will be winning here as they can now get more JBX in exchange for the payment they make, except for the ETH balance of JuiceboxDAO's treasury, which will not increment anymore when funds come in.

The power of JBX is in full swing at this stage. As the project looks to build momentum and volume, the role that JBX plays in motivating the ecosystem forward becomes more meaningful now.

The next steps would be to work with Juicebox.money to surface a quote in the payout flow, to make sure folks get the best possible token issuance. And there had been a few inquiries from folks about if they can install the buyback delegate on other Juicebox projects, we will keep monitoring these needs and hopefully keep tuning it from the perspective of both contract and users.

MEV Sandwich​

But if Juicebox projects distribute their payouts out of the ecosystem, which will incur 2.5% Juicebox fee and buyback delegate would route these fees to purchase JBX in the AMM pool, there will be an opportunity for MEV bots to sandwich the transactions and steal some value from them, unless the person who triggers this distribute call use some MEV blocking RPC in their wallets.

This is out of reason that the fees get paid into JuiceboxDAO without any metadata in the case of protocol fee payment, so we don't have an opportunity to specify the expected quote that the fees should resolve at, and instead the contract uses a TWAP (Time Weighted Average Price) oracle to look at the recent prices of the exchange.

There are two parameters that we can tune about this TWAP oracle. The first one is the TWAP window, e.g. 30 minutes or 24 hours, which means how far the buyback delegate will look back to determine the proper average prices that the transaction will be resolved at. The second one is the slippage tolerance from that average price that we can accept to deviate from the TWAP price.

With these two parameters, we can automatically determine the price that we expect. And then the difference between that expectation and the actual price can be arbitraged, which will be especially tricky for highly volatile or low volume token pairs. If the Juicebox fees that will be routed to AMM pools are of size like $10, $100 or $200, and the depth of the liquidity pool is around $30,000, the impact of the trades is very decent and the arbitrage opportunity is relatively small, MEV sandwich won't likely be happening. So long as the trades are small related to the liquidity in the pool, or the liquidity itself is increased by liquidity providers as what Jango has done recently, the chance of MEV sandwich will decrease over time.

Question on Distribution Bot​

There were some ideas floating around concerning whether we could run our own bot which would be looking throughout the protocol to monitor any distribution calls and try to distribute before a MEV bot can do.

Jango took the example of the distribution of payouts by JuiceboxDAO recently, which incurred a 1.94ETH Juicebox fee (And yes, all projects including JuiceboxDAO making outbound payments will be subject to a Juicebox fee). The total volume to arbitrage from this MEV trade was around $85,000, and the paid 1% liquidity fee which was more than $800. This activity would incentivize more liquidity providing actions to the pool, which will in turn decrease the opportunity to arbitrage.

We can also choose to build a bot and take advantage of the information asymmetry that we have, but Jango thought that we have more important things to do than that. As always, he was open to any proposals to fund this kind of effort if there is any interest.

Jango also planned to submit a proposal to JuiceboxDAO next funding cycle, suggesting that the DAO add more liquidity to this LP pool in order to lower the probability of MEV arbitrage when buyback delegate is in action.

Juicecast Update by Matthew & Brileigh​

Matthew and Brileigh released the new episode of Juicecast, featuring Peacenode from Seed Club, talking about Peacenode's role as creative director at Seed Club, how he helped to build the Seed Club brand, and how they are approaching the idea of branding through the creator-led lens.

Matthew also said that they were thinking of making some sort of partnership with Seed Club, so that we could get some folks from their network of early stage projects to come in and create a project on Juicebox. The information they want to convey with these series of podcast is to build bridges with other communities and leverage these relationships in the future.

Brileigh added that she liked the idea of cross community ecosystem, where, for example, cohorts of projects can maybe raise their funds and get their guidance in one platform, while later coming to Juicebox to manage their treasury, or use Nance for the governance of their community. Projects can start somewhere, but as they grow, they are free to use all of the different tools available, such as those offered by Juicebox, to further their development.

Bruxa from Thirsty Thirsty agreed that the partnership opportunity with Seed Club could be valuable for relationship establishment, especially around early DAO education, Revents and treasury building education. Jango also recognized the value of maintaining relationships through conversation in the form of podcast, even if these efforts might not pay off in a short period of time.

Nance Updates by Jigglyjams​

After the feedback from the temperature check of their proposal, the team has been working on some simplification of the Nance system, so that it can be easier to onboard new users or new communities.

Also they are going to implement a new proposal editor which will be a pure Markdown editor, to replace the current editor which has been doing a lot of converting between HTML and Markdown formats. The old editor seemed to have a few compatibility issues when proposal are viewed on other sites such as Snapshot.org, so they are working to refine that bug and make it better for proposal viewing.

Comments or feedback for Nance wll be warmly welcome, Nance team members including Jigglyjams, Twodam and Zeugh will all be keen to work on whatever things people are interested in.

Thirsty Thirsty Update by Bruxa​

Ongoing efforts have been made to continue creating more foundational structure in the Thirsty Thirsty community, especially around their TT tokens.

Bruxa had a pretty big proposal approved a couple weeks ago distributing tokens to compensate the time she had contributed to their community. They decided to make Oct. 20th an opportunity for other contributors in Thirsty Thirsty to do the same thing.

Bruxa also said that it had been a really interesting journey, to interact with so many cool people and products being built on Juicebox.

Ideas of Juicebox Merch by Matthew​

Matthew, Brileigh and Sage have been discussing about launching some NFTs that could be used to redeem for some Juicebox merchandises, as well as trying to finalize some high quality merchandise such as a hoodie, T-shirts, hat with embroidered designs, etc. They are thinking of bringing those to ETH Denver on February next year,

Matthew also introduced that they were trying to establish a partnership with a coffee brand to put Banny on some of their coffee bags, as he felt that coffee is lower in entry barrier because it's such a broadly appealing product and can be a very easy pitch. So coffee bags could be a starting point to put Banny onto some products.