Revnet and Bananapus Updates by Jango​

Revnet Create Flow​

We now have a prototype of Revnet create flow, people can play with all those scoped concepts of Revnets, such as Price Ceiling, Price floor tax intensity, Premint, Boost and Boost duration, etc.

After this create flow is getting more developed, Jango expected that their work would be more focused on the project dashboard on Revnets in order to make it multi-dimensional.

Also there would still be some ongoing efforts for data visualizations, which Jango thought would be more ready in next week and by then they would be embeddable everywhere.

Bnananapus New Repo​

In the Bananapus GitHub repository, we have a new repo which is a little more experimental with looser permissions. There is still some work in progress in the PR section of this repo, which Jango expected can be finished within one week and then folded into the main V4 repo in the Bananapus GitHub thereafter.

The Bananpus fork of the Juicebox V3 protocol will be deployed on multiple blockchains such as Mainnet, Optimism and others, which will be very scalable. It's an open opportunity to revise some bits of the V3 protocol, which includes the addition of ability to queue multiple funding cycles ahead of time at a project's deployment, rather than currently having to manually trigger those reconfigurations before each new funding cycle. So project owners can propose some kind of games by deploying projects with different rules automated for each cycle from the very beginning.

The economic model they will be using for Bananapus will not affect JBX directly. From a risk perspective, the Bananapus experiment can be carried out without putting Juicebox at risk. The Bananapus Revnet will pre-mint tokens committed to the outstanding JBX supply, and allocate them to the Juicebox multisig to be governed by JBX holders.

Buyback Delegate Updates by Jango​

The transaction of deploying the buyback delegate had been queued together with reconfiguration of a new funding cycle of JuiceboxDAO, and it would come into effect by the start of next cycle. Jango thought that it would start paying dividends right away for reserved rate recipients and projects that are paying fees to JuiceboxDAO.

It will really give us more confidence in JBX tokens and in the treasury that backs them, so that we can lean a little bit more onto JBX and take a more hands-off approach with the general issuance properties of JuiceboxDAO. Hopefully in the future, other projects can grow to this scale and make a similar use of this function.

Peel Updates by TJL​

Payout Table​

The payout table developed by JohnnyD from Peel had been implemented into the create flow of Juicebox. Project creators can now add their payout recipients, which can be either an Ethereum address or another Juicebox project, and specify their respective payout amounts under the limited payout model, or have those automatically changed to percentages under the unlimited model.

Juicecrowd Prototype​

Juicecrowd is a slimmed-down version of Juicebox, especially for people that are trying to crowdfund on Juicebox but understanding that the current project creating process is too complicated from a perspective of functionality for them to do whatever they want.

It's a simple fundraiser like Blunt without project tokens, but instead enabled with NFTs as possible rewards (optional) to contributors. Compared with the current Juicebox create flow, it also strips down the recurring funding cycles to a single cyle under the hood and replaces the complex multi-cycle payouts with just a simple withdrawal of funds.

The prototype of Juicecrowd has been put together by the Peel team, which can be found here. The Peel team will still be working to further improve this prototype in the near future.

Ideas on Patreon and Revnet integration by Jango​

Jango introduced that there are a large body of content creators on Patreon, and they are receiving monthly membership fees from their fans. He had been exploring about what it would take for those creators to keep using Patreon and route the funds contributed into Revnet projects, since Revenets are more deterministic and have a lot less obligations or implications with where the money could go.

He was also wondering if it would be possible to reward someone who pays a patreon through a backward process. By that, we can set up a middle service that takes in the patreon fees, applies them in the blockchain world, and sends the payers their shares of tokens.

Jango thought that a lot of people are comfortable with Patreon, which does a very good job of allowing people to contribute whatever they want. But obviously Patreon also has control of the money, they can block payouts and everything in between. It would be ideal if we can prototype for a few Patreon projects that want to integrate with Juicebox projects, and Jango was interested in figuring out how to run a middle service between bank accounts and blockchain accounts.

Jango admitted that there would be a lot of management, operation and points of potential failure in between when moving large sums of money is concerned. And he was trying to know more about the legal and logical implications of such a business model.

Also he was trying to investigate if there would be an option to hook into currently existing business models and services in the Web2 world, and have a broader go-to-market solutions for some of these ideas like Revnets. It would not be easy to get the activation energy to get projects that already have broad visibility to come and try it out.

Peel Updates by Tjl​

Tjl introduced that the Peel team was currently developing the focus front end for Juicecrowd, which is a more specific, Blunt style and Kickstarter-esque fundraiser. They had completely defined the project by the time of this town hall, and they would be testing and prototyping it over the next few days.

Artizen Introduction by René​

René is the co-founder of Artizen, which is a fund that partners with mission-driven brands to find and fund artists, scientists and all other kinds of creators to help boosting their organization's ecosystem or fueling their missions.

René introduced that Artizen is pivoted around the idea of allowing many different stakeholders to come curating projects together and collectivly providing funds to reward the most promising projects, making it a platform that is funded and curated by the Artizen community itself.

He thought that Juicebox would be a really wonderful partnership to work togerther with, both for his admiration of the product built by JuiceboxDAO, and also because of the fact that Artizen and Juicebox community have many aspects overlapping with each other. He felt that it would make a lot sense for both communities to pool our resources and help fund talented creators and encourage them to use Juicebox for fundrasing throughout the life cycle of their projects.

During the current funding cycle of JuiceboxDAO, René had submitted a proposal of Juicebox Project Accelerator Fund with the help of Filipv, in an attempt to launch a match fund between Juicebox and Artisen to support community-driven projects in Juicebox.

Bananapus Updates by Jango​

0xBA5ED had wrapped up the implementation for the staking delegate, the rewards component which allows folks to route tokens to stakers as well, and the tentacles component which allows stakers to bridge their tokens to other chains in order to collect staking rewards with a similar mechanism.

Dr.Gorilla had been cleaning up some tests for the 721 delegates, which is a pretty delicate contract. He would be up to the adjusting tests while the buyback delegate is going to be deployed to the JuiceboxDAO's project.

The contract crew had several pull requests open against the V3 contract repository, and these changes were made for the Bananapus fork and would not be a version pushed on the standard Juicebox protocol as it currently exists. We would be running this fork of Juicebox protocol as an experiment on Bananapus project.

The most meaningful changes was the one that will allow for queuing multiple funding cycles in the same block, so project owners can now deploy a project with multiple funding cycles established at its deployment, instead of having someone to execute a public transaction to implement each following cycle.

Audits for Bananapus​

Matthew wondered if there would be an audit for Bananapus once the development is finished.

Jango said that there would not be an audit for Bananapus fork of the Juicebox V3 protocol, which had already gone through a Code4rena audit last year, but he was expecting an auditing contest for the new Bananapus components, including Bananapus 721 staking delegate, Bananapus distributor and Bananapus tentacles.

The Bananapus V4 fork actually is a Juicebox V3 protocol all over again with mostly small adjustments, so Jango felt we should keep monitoring those adjustments and revisit them in certain intervals to see if they merit a formal audit. Generally he thought that the current Juicebox V3 protocol had gone though the process of getting audited and hardened for production, and we have established strong versioning protocols to get to this hardened state.

Jango also thought that the way to get to a trustworthy Bananapus experiment, would be to deploy it with good economics, so that if in the future it does develop legitimacy as a trusted fork, we can move forward with confidence and JBX holders can understand very well how the economics relate to this fork. But he stressed that any mission-critical experiments in the near future should probably still point to the Mainnet V3 implementation.

It would always be hard to say no to audits, Jango said. It takes some mental gymnastics to go yolo and see what happens. If we give something too much legitimacy at first, we will probably be confronted with odd things that happen when it's in production and least expected. Maybe it would be more ideal to make clear all the risks along the way, and we could put community resources to auditing and legitimize it when it's needed in the future.

Revnet Updates by Jango​

Jango introduced that the productization of Revnet had been coming along fairly nicely. On the town hall, he shared the updated prototype of a Revnet website, this prototype is using all real data and a Revnet contract which is an orchestrator of Juicebox contracts under the hood.

He had also refined some of the Juicebox contracts for deploying Revnets, which can be found in the Revnet Github Repository.

Filipv had been working on a more formal paper that describes the mechanism of Revnets, which can be found here. He encouraged folks to take a look at that file and provide their feedback, if there is any, to help improving the language of ths document.

Jango thought that it would be awesome to try figuring out how to communicate this concept out to folks who are thinking about operating a project, or looking for a way to actually monetize an open source endeavor or various other applications.

Jango also thought that it's very cool to be working on sereral of the APPs that are using the underlying protocol at the same time, and those APPs should stand to benefit from one another. As we push forward and learn from different use cases, it would be very interesting to find out which audiences gravitate to these different kinds of APPs.

Juicecast Updates by Matthewbrooks​

Matthew and Brileigh released the 31st episode of Juicecast, featuring Jess from Seed Club, which is a venture DAO funds early stage founders who are building crypto products.

They would also be releasing the next episode with Peacenode from Seed Club, to talk more about building the Seed Club brand and its graphics.

Updates from MoonDAO by Pablo​

Pablo, the co-founder of MoonDAO, joined our town hall and shared some of the recent updates of MoonDAO development. He introduced that they had been working on the network topology for lunar communications, which is a fancy way about how to route messages from the Earth to the Moon in a way that's true to the principles of Ethereum, in an incredibly neutral way that is more bottom-up instead of relying on a few key infrastructure nodes.

Pablo also expressed his gratitude towards Juicebox for helping them build their project and community by fundraising on this protocol, and he thought it was very cool to see all of the amazing things Juicebox help make possible.

Buyback Delegate Deployment Plan by Filipv and Jango​

The buyback delegate had been expected to get deployed during the current funding cycle, but the contract crew led by Jango decided against it out of an abundance of caution.

The development work of this contract had been pretty much finished, and contract crew had been reviewing and testing for edge cases for a while. Jango thought that the contract feels very good and super greenlit for deployment in the next funding cycle.

But, as the buyback delegate does have permission to mint arbitrary amount of tokens by design because it needs to be able to manage token supply, theoretically if there is an edge case arises unexpectedly, it could probably lead to a adversely inflated token supply. If we have redemption enabled at that moment, the inflated token supple might be used to redeem for the ETH in our treasury.

So Jango thought that it would be wise to turn off the redemption before the depolyment of buyback delegate, and he would submit a proposal to do so in the next funding cycle. After the proposal is approved and executed, we should be able to attach the buyback delegate to JuiceboxDAO treasury right away. The time line would be at the beginning of the funding cycle after next, i.e. roughly in three weeks.

Proposal of Juicebox Project Accelerator Fund by Filipv​

Filipv said that he and René from Artizen had put up a proposal of Juicebox Project Accelerator Fund, to launch a match fund between Juicebox and Artizen and in turn to support community-driven projects from creators at the frontier of innovation. If this proposal is approved, Artizen will match the funds that granted by JuiceboxDAO for up to 50,000 US Dollars. This Juicebox Project Accelerator Fund will be used for the funding of potential Juicebox project creators.

Also Filipv had been working with René on getting a governance token issued for the Artizen platform on Juicebox protocol.

This plan of partnership between JuiceboxDAO and Artizen was still open-ended, according to Filipv. He encouraged our community members to come forward with feedback or ideas to help shaping out this plan.

Bananapus And Revnet Updates by Jango​

During the town hall, Jango shared a Revnet website prototype.

According Jango, some of the data was still being hard-coded, but the basic contract was ready for deploying a Revnet project, and a basic web client was already work in progress.

The plan was to work with a six-week sprint, first deploying the Revnet site onto all testnets between Bananpus and Revnet, then after the testnets are tested and proved reliable, hopefully implement the deployment on Mainnet within this time frame.

Currently contract crew was working on the devops of Bananapus project, which was mainly focused on the experimental L2 deployments. Filipv was helping with some formal papers which would be used to communicate with a more academic audience. And Jango was working on some tutorials, as well as some video clips to explain the concepts concerning Bananapus and Revnet.

Jango thought that many people are interested in our development on L2s, and it will play a big role in the what Juicebox might be capable of in the future. We were now experimenting without involving the current Juicebox protocol on mainnet in case of any unfavorable changes, since we were really looking to stablize what we have had implemented, and allow Peel to play with the objective of creating more scoped front ends, which can be pointed to the L2 forks if our L2 experiments play themselves out and we gain more confidence over them.

Croptop Updates by Jango​

You can go the site of Croptop site and get to know more about this project. Or you can just download the dedicated Mac App for Croptop here, and follow the instructions below:

Recently, the team successfully built the aggregate Croptops, by which a Croptop aggregate page can aggregate feeds from many other Croptop hosted feeds, so that users don't necessarily need to host their respective feeds anymore. This feature allows for concentrated curation of contents within a community, which can be very helpful. Other than that, it also enables a user to post contents from multiple clients, such as PC, mobile or tablets and have them all aggregated onto one hosted site.

Furthermore, arbitrary RSS fees, whether they are posted on Croptop sites or not, can also be aggregated onto one specified Croptop site, which are greatly expanding the sources of contents for a community.

It is really starting to open up the capability of Croptop to curate content feeds in a way that incurs no fees or transaction cost, serving as a web client to host and broadcast those contents.

This project had already been deployed on Goerli testnet, it was waiting on Revnets' deployment so that it can move to production while having a governance-less and productive venue to accumulate fees collected from its network.

Buyback Delegate Demo by Jango​

If a Juicebox project is deployed with the buyback delegate, whenever there is a payment made to the project, it would route the funds either to mint new project tokens from the treasury, or swap for tokens from the AMM exchanges, or do both in some scenarios, depending on how the difference between interior issuance rates and market swap rates of that token will be, or wether there is adequate liquidity in the relevant liquidity pools.

Let's take the JuiceboxDAO treasury as an example, there will be three scenarios under which the buyback delegate will work.

1. When there are inbound payments made to the JuiceboxDAO project as contributions to the project, web clients like juicebox.money will pass the metadata, which is information such as the minimun swap amount out and the amount to swap with, to the buyback delegate as instructions to proceed with the swaping transactions.

2. When the funds are paid into the project as internal payments such as a fee, e.g. projects distributing funds out of the Juicebox protocol will be subject to a 2.5% protocol fee which will be paid to the JuiceboxDAO project, there will be no metadata passed to the buyback delegate in that circumstance. In that case, the buyback delegate will make use of a TWAP (Time Weighted Average Price) as an oracle for pricing to carry out the swaping trades.

   The TWAP has a few parameters that project owners can tune, as to how aggressive they want the oracle to suggest a price. If pricing turns out to be too aggressive and the actual swap ends up outslipping the TWAP suggestion, the contract will default to mint the tokens from the treasury instead of swapping on open markets.

3. If the funds paid into the project surpass the available liquidity in the AMM liquidity pool, web clients can split up the funds and use a portion of it to make most of the liquidity pool, while the leftover funds will be routed to the project treasury to mint new tokens.

Overall, this contract is fairly simple at its core, covering some pretty important edge cases and adding some flexible and powerful edge case features. It will definitely help people get more JBX when they are engaging with the JuiceboxDAO treasury, and perhaps can also work for other projects within this ecosystem in the future. We can definitely imagine buyback delegate as a very core part of any projects that scale up and want to offer its community the best token prices possible for payments coming into them.

On Regulatory Framework of Crypto Industry​

Please be noted that any discussions concerning legal affairs in this town hall are only personal opinions and do not constitute any investment advices.

In this town hall, our guest Rob, a securities lawyer who had come to share his thoughts on the Ripple case in our previous town hall, joined us again to share some updates of the legal cases relevant to the crypto industry, as well as some of his thoughts on these cases.

According to Rob, there were multiple government agencies which were looking at the crypto industry and thinking of putting it under their supervision. A very well known example will be the SEC, under the leadership of Chairman Gensler, had been relentlessly chasing after crypto world and trying to put most of the cryptocurrencies into the category of security. Also the CFTC (Commodity Futures Trading Commission) required that some of the tokens be regarded as commodities and therefore be subject to their supervision.

Rob shared two legal cases in the town hall, in order to shed some lights on our confusion and bewilderment about whether there is a regulatory framework to supervise this industry.

The Uniswap Case Implications​

This was a case where some plaintiffs sued against Universal Navigation Inc., probably the parent company of Uniswap, and the VC groups investing in Uniswap, with the claims that they had violated the Federal Security Acts, after the plaintiffs traded some scam tokens on the Uniswap platform and made loss. The plaintiffs thought that those token are securities and Uniswap in turn functions as an exchange of these tokens, and as they failed to find the issuers of those scam tokens, so Uniswap and VC groups, the developers of this exchange who also charge fees for using the platform, should be held accountable for their losses.

The judge of this case, Judge Failla from Souther District of New York, granted a motion from Uniswap and VC groups to dismiss this case, with the reasoning that there was no clear legislative directive to put these tokens under the purview of Securities Acts and the judge felt it a stretch of federal exchange laws to apply in this case. The legal opinion of Judge Failla can be found here.

According to Rob, the SEC had also been trying to broaden the definition of investment contract to put the tokens being traded under their purview, which they had been successful in a lot of different places. But he also thought that we were starting to see some kind of pushback from the courts, just like what happened in the Ripple case and this Uniswap case. The courts are not necessarily agreeing with some of the interpretations and positions made by SEC in these cases.

But generally Rob was quite optimistic about the result the this Uniswap case, where the judge ruled agaisnt Uniswap's accountability for just deploying codes. That might signify some kind of pushbacks or disagreement from the courts when SEC and CFTC were trying to put crypto industry under their purview.

CFTC Orders Against DEFI Protocols​

In the recent orders issued by CFTC against DEFI protocols such as Opyn, Deridex and ZeroEx, CFTC took the stance that those protocls, as they had control over their smart contracts, should be held responsible for the trading activities happened on their platforms. Rob expected that this might be something that the SEC and CFTC would be chasing in the future, in which case if an entity has control over a protocol, they might be considered liable for selling securities or providing exchange services for them, etc.

The Major Question Doctrine​

There is a very famous Chevron defense doctrine, which courts may defer to the opinions or explanations of some administrative agencies when the legislative delegation to these agencies on a particular issue or question is not explicitly defined.

On the contrary, the Major question doctrine is a principle of law interpretation, where courts will presume that Congress does not delegate to the administrative agencies some issues of major political or economic significance.

When agencies like SEC or CFTC want to vastly expand their power and authority to regulate giant swaths of the economy, the Major question doctrine might come into play where courts might rule that it's not up to an agency but rather Congress to decide if this agency is granted the power to do that, depending on whether this is a significant expansion of the agency's power, or whether the matter is related to a significant portion of the economy.

Rob also gave an example of how SEC was over-expanding their administrative power apart from what they are doing with crypto industry. SEC was trying to implement some climate change rules which require businesses to disclose their carbon output or greenhouse gas emissions etc. in the name of protection of investors. It probably would be a stretch of their delegated power.

The moves by these agencies, such as SEC trying to define most of the cryptocurrencies as securities or CFTC regarding them as commodities, might not be recognized as lawful delegation to these agencies. But we would have to see what the courts would allow in the future.

Legal Implications On UNAs​

Rob also brought up a recent Ooki DAO case, where the CFTC took the position that token holders, just by holding a token that had governance rights, should be considered as part of an UNA (Unincorporated Nonprofit Association). In many jurisdictions of U.S., UNAs are not recognized as a legal entity but rather an aggregate of individuals, so they don't have any ability to defend themselves in courts, and anybody associated with an UNA can be held with unlimited liability related to it.

Fortunately, there was a major push to actually give UNAs some rights and limited liability, which was the revised UNA model act. This act had been adopted by a number of juirisdictions in U.S. such as Nevada, Wyoming and Texas etc., where an UNA now for certain issues can be treated as a separate legal entity and its members will only have limited liability towards the UNA.

Rob thought that would be another major issue in the future that everyone should pay close attention to. If a DAO is taking a legal structure of an UNA, you can be regarded as a member by just holding the DAO's tokens which have governance rights. In California, members of an UNA may have unlimited liability to it, while other states like Nevada respects the limited liability for their UNA members.

Opinions about Retailism​

Rob thought that the Retailism concept that brought up by Jango was a very cool solution to a problem in the financial world, where big guys like wholesalers, VCs, investment banks, accredited investors, etc. had been trying to dump their bags to little guys, i.e. the retails investors. Projects operating under the retailism pattern will be very transparent to all participants, and retail extraction of small investors like mom-and-pops by those big guys can be avoided to a great extent.

Jango thought that the retailism concept works not only in terms of big investors versus small investors, but also in terms of a Juicebox perspective or even a legal perspective. The owner of a retailism project is a contract, opposed to a multisig, an individual or an on-chain governance entity, this concept eliminates the possibility of any changes to the project routine like funding cycle configurations, except for very few deterministic options.

These ownerless contracts can be designed in other ways, like proposed as interesting games, that solve the incentive problems between earlier investors who take on more risks and later retail customers, as well as those between early-on developers and later ones.

Jango also said it would be ideal if we could put together a product that can explain retailism, and refine the metaphors and components in a way that would be palatable for people who actually are looking to use it. We can start with the many projects that we've funded as a DAO and built them as creators, before extending to other projects into the future.

He thought that a big cloud over a lot of what Juicebox had offered during the past year was the legal uncertainty, which had been leading too much into the multisig style of project ownership, governance style of project ownership, or just one -dimensional pure fundraisers. There is always a messaging problem for a lot of what we are capable of. How do we create an experience that educates what's going on?

And then the legal uncertainty made the bidirectional Juicebox interactions very difficult to carry out with confidence. Oftentimes, if you have a great idea, this just adds on risks. The Juicebox toolset may prefer a more public and honest relationship between everyone involved.

It's exciting to get to a point where we're trying to refine the tools, and learn from the recent events to ship something that we're willing to take the risk on, and do so in a way that means well, hopefully with all interests involved, or at leat with most interests involved.

Buyback Delegate Updates by Jango​

The contracts of Buyback delegate are looking good, it's in the last phase of getting eyes on it to double check with last minute test, before we are going to attach it the JuiceboxDAO project.

If there's enough interest for this product, Jango expressed his willingness to do another line-by-line session to go over how it functions specifically.

It's very important to review the contract because it gives the power to mint arbitrary amount of project tokens on behalf of the people who pay the project, according to the rules set in the buyback delegate. Generally, this product is very delicate and deserves more caution to its deployment and use.

Jango said that we had been expecting to attach the buyback delegate first in experimental projects like Defifa and Croptop, so that we could have it battle tested before deploying it to the JuiceboxDAO project. But recently as the development of Bananapus and cross-chain interoperability is getting a more solid shape, we were yet to decide which network we should deploy Defifa and Croptop to. So we might decide to deploy the buyback delegate directly on JuiceboxDAO project, since it's feeling very good after days or weeks of edge case testing by the contract crew.

Revnet: Productization of Retailism by Jango​

Jango had shared his thoughts on Retailism and some relevant blog posts about it during town hall in July, which can be found here.

According to Jango, Revnets are a special configuration of Juicebox project that applys Retailism, which includes these following parameters:

1. A Juicebox project that has neither project owner nor payouts. When funds are paid into it, project tokens will get emitted back out in turn.
2. There is a reserved rate in this project which is called boost, and a funding cycle duration is callled generation.
3. The issuance reduction rate will be called entry curve in this case, which means there will be x% fewer tokens issued out when the network receives a unit of funds.
4. Exit curve, the redemption rate, which means the percentage of funds people can burn their tokens to access the funds in the treasury, while leaving some funds on the table for those who burn later.

A lot of experimental projects, such as Defifa, Croptop, Blunt or Bananapus, have very compelling concepts at their disposal, but they also need to figure out a destination to route the collected fees to fund the development, to the extent that their community sees fit, so as to foster the continous growth of the network as a whole.

Different from the model JuiceboxDAO is implementing its governance, where there is a regular reserved rate and the project is owned by a multisig to execute the decisions made from governance on a regular basis, the answer for projects like Defifa or Croptop lies in a less management oriented configuration with incentives for builders, investors and customers aligned, in order to ensure the growth of these networks, as people might not want to spend too much time to participate in the governance of these long-tail treasuries.

Here is the mechanism might work for these networks:

• Customers pay in fees, and they may have an immediate rebate of redeeming the tokens received to get some funds back. But if they hold their tokens and the network grows, the value of tokens will increase together with the network's growth.
• Builders can have their boost period to compensate their work in the establishment of this network, where a percentage of network's growth will be reserved and allocated to them. For example, if a project is launched with 28-day funding cycle and a 2-year boost period, the funding cycles keep rolling over every 28 days forever, only with a pre-set configuration to remove the boost two years from its launch.
• Investors don't need to worry about the whereabouts of the their money, since there will be no more future reconfiguration by project owners or multisigs.

We could balance these forces that make a project run in a trustless and permissionless way, and projects like Defifa and Croptop etc. could further instill and develop their own patterns on how to use and connect their revenue stream.

We were still trying to find out how to position this as somehthing useful for others to experiment alongside and create the horizon that we would be moving towards.

Demo of Retailism mechanics​

During the town hall, Jango showed a spreadsheet of Retailism Financial Modeling, where people can input their initial issuance rate, generation duration, entry curve and exit curve etc. to play with the mechnics and see how this model of retailism would play itself out.

Bananapus Gameplan by Jango​

In Jango's words, although Bananpus had been a bit confusing and technically elaborate, hopefully it could have a core essence that we can treat it as a neatly packaged box.

The development team had promised to experiment it as an L2 connect point on EVM chains, by running it on layer 2 chains like Optimism, Base or whereever we can to figure out how to reliably run it and test out the mechanism for cross-chain organizations.

For example, how can Juicebox, a protocol on L1 chain, also be launched on an L2 and help maintain a sense of financial community across all of the applications and across each implementation. Let's say we deploy another JuiceboxDAO treasury on an EVM like Optimism and issue its own tokens there. What does that mean for JBX? How do we create an affordance while leaning into the JuiceboxDAO fee collecting structure, as we need to support the body of work and grow it so that everyone such as builders, users and investors is involved.

We might be able to point a certain percentage of the project's reserved rate, boost in the context of Revnet, to another project on another EVM chain, not to the its owner but to the token holders, in order to allow networks to cross pollinate, which can be carried out either on the same chain or across different chains. For instance, if we deploy another Juicebox protocol on an L2, we can find a way for JBX holders to claim issuance from that L2 version of the protocol.

But this will be a very fragile operation as far as cross chain bridging and multiple tokens management are involved, so we might not want to do it directly on the JuiceboxDAO project, in case that might lead to some unexpected outcome and risks.

So we might deploy a fork of the Juicebox protocol in the Bananapus project, to experiment these cross-chain primitives including staking and bridging of tokens, management of multiple treasuries across various EVM chains, and also the Revnet networks based on the theory of Retailism, without compromising the stability and safety of Juicebox protocol itself.

In terms of the websites that will be used to interact with the Bananapus contracts, Jango didn't think it would be the responsibility of Juicebox.money to chase after the next experiment and bring that to commercial readiness right away, because the experiment is very risky and it's not worth the risks.

Jango said we might be making smaller and scoped sites which would play with these ideas specifically. For example, there would be a Bananapus website for the staking interaction and token bridging, where people can stake their tokens and get an NFT position to claim rewards and mint the Bananapus tentacles onto other chains.

Demo of Bananpus.com by Filipv​

Bananapus.com is a website serves to display the ongoing development of Bananapus, and also as a web client for users to interact with the contracts of this project.

On the town hall, Filipv demonstrated the web pages of bananapus.com which was still a WIP (work in progress), and explained the process of staking tokens and claiming rewards.

Bananapus project consists of three main components, Bananapus 721 staking delegate, Bananapus distributor and Bananapus tentacles.

Users can stake their ERC-20 tokens of a Juicebox project using the Bananapus staking contract, in return they will receive NFTs to represent their staked positions, which can be unstaked to retreat the original ERC-20 tokesns if the holders want to.

With Bananapus distributor contract, anyone can send ERC-20 token rewards to it and let stakers in the last step to use their NFTs to claim a portion of token rewards over time.

Furthermore, the NFT holders can interact with Bananapus tentacles contract to mint corresponding tokens of various L2s and bridge them over, so as to be eligible for rewards or other usescases in those EVM chains.

Networks of Bananapus and Revnets​

Context of Revnet networks​

During the town hall, Jango shared some of his thoughts of different networks, which would be created on the fork of Juicebox protocol by Bananapus project and running as Revnets across various EVM chains. His blog post to elaborate on the details of these networks can be found here.

The Bananapus project would try to deploy a fork of Juicebox protocol, and the networks that would be created and running on it will experiment their revenue management, token staking and rewards distribution, bridging and etc. across multiple EVM chains.

First, Jango went through the context of building networks on Bananapus with a Revnet model, emphasizing their goal to streamline the organizational and legal operations and expectations, and to make them more accessible to investors and customers.

Also he said that the desire to operate a project primarily through Revnets on Bananapus is not certain and not required, these Revnets can stand beside other forms of operations and even be led by their fans without the consent from their builders. But broad alignment will be important too, as the lack of legitimacy or planned revenue from builders may diminish an investor's confidence when choosing to support a network.

Lastly, Jango also encouraged our community members to acutally play with these new various networks and take a bit more active and meaning role as builders together.

Purpose of Bananapus​

Bananapus is a way for networks of token holders (Juice projects) to relate across chains and forks. Organizational money rails, modeled as tentacles.

Jango explained that Bananapus would be a Juicebox V3 fork, so it would be the same codes as the current Mainnet Juicebox protocol, with all the latest versions of terminals and controllers etc. And it would be depolyed on Ethererum mainnet, Optimum, Arbitrum, Base and other EVM chains, we would start with one of them and scale up from there.

And we would enable projects to cross pollinate by implementing the native staking-based bridge, and support them to queue multiple funding cycles in advance so that a project can be set in motion with multiple changes pre-configured along the way.

And there were also other considerations with this deployment of Bananapus, such as removal of functionalities that had been proved useful, integration of 721Delegate and BuybackDelegate, options to accept and store funds in ETH, DAI, USDC or other coins, and etc.

Purpose of Revnet​

Jango introduced that Revnets are a special configuration of Juicebox projects applying the logics of Retailism, with the 4 basic properties characterizing their launching and future operations, namely the premint, entry curve, exit curve and boost period. These basic properties help create a venue for decentralized networks for builders, user and investors to accumulate resources to further the growth of their respective communities.

The purposes of Revnets consist of productivity improvement and community participation, transparency and unobscured access to the funds, initiatives for existing projects like Peel and Nance to better guarantee the incentives and legal clarity for their communities, and the research and prototype means for traditional banked businesses.

Conclusion​

Jango felt very excited to see how the work would unfold. And he said there would be a proposal in the recent cycle to prompt more discussion about this among our community, so that we can make some decisions together if we want to support this experiment and how should be commit to it.

Jango thought that as a lot of us had been cross-pollinating across various ideas, treasuries and concept, we were all pacing towards a similar fun place to be where JuiceboxDAO's funds hopefully make investments towards those ends. Now that we had places where we can take risks more confidently and point revenues to, we could try to make moments of exploration into the wild.

It also felt a cool moment where we can call attention to existing projects continuously worked upon, and have a vision what folks are excited about, before we could go to pockets of both retail and VC investors to create relationship with them again.

Juicebox Merch Discussion​

Jango thought that we could consider sending a box of merchandises to our contributors in EU or Australia etc. , so that they can be distributed in more fine-tuned way in future events or conferences.

But we would also have to beware of the import taxes and customs declaration procedures if shipped by freight transportation.

Sage expressed that she would be happy to share the art files and the websites for making these merchandises, as well as a portion of the funds granted from the DAO, so that folks in different regions might be able to arrange locally and thus mitigating the shipping and importing cost across the world.

Filipv also suggested that it might be cool to upload the art files onto Github or somewhere else, and build a page on some print-on-demand websites, so that people can just order those merchandises from there directly.

Though Peel team had been recently pushing for our hackathon partnership with organizations like ETH Global or Devfolio, and there were some ideas to distribute these merchandises on upcoming events like ETH Istanbul etc., but as Peel team were still under their efforts to revamp some fuctionalities and designs of our front end, it might be more ideal to carry out our current distribution of merchandises, without having to wait for the accomplishment of this partnership.

Sablier V2 Interop Updates by Nowonder​

The Sablier V2 Interop is an extension being developed by Nowonder, it aims to help Juicebox project owners to attach a split allocator their projects, and add payouts of multiple token streams for their contributors, in order to realize fine-grained control over the distribution and vesting of those payouts.

Nowonder told us that Paul, the lead author of Sablier protocol, had come to help review the code base of Sablier interop, put in a PR with some changes, and refactored the imports in the contract, which reduced the size of this repository by a big extent and made its running more efficient. Paul also expressed his recognition towards this product of interoperability between Sablier and Juicebox by Nowonder.

And Nowonder said he would keep on developing and try to ship this prouduct soon as an extension to the Juicebox project treasuries, and see if any projects are interested in making use of it to distribute payouts to their new contributors.

As we currently didn't have corresponding front end UI to support the attachment of this extension in juicebox.money, Jango recommended that Nowonder could consider trying to implement the attachment to a Juicebox project through Etherscan or somewhere else similar first. When people start to use this product and interact with Juicebox protocol outside of Juicebox.money, it might leave the website in a state where relevant transactions might not be queried and properly reflected on the project page on Juicebox.money, which resembles a bug in the page and hopefully can be prioritized by Peel team to create a dedicated UI in the project page to help implement the use of this extension.

Matthew and Brileigh had released a new episode of Juicecast of their discussions with Paul from Sablier and Nowonder last week, which were mainly about the introduction of Sablier protocol and its interoperability with Juicebox protocol. According to Nowonder, the Sablier community was quite exited about this integration effort, and hopefully this could be a very good starting point for dev relations development among different communities.

Jango thought that it was very cool for this episode to bring other voices into our Juicecast channel. As for the interop extension by Nowonder, we might not want to develop strategies for its marketing efforts or its APP interface, until we have a product thesis or projects that are keen to leverage it specifically.

But this will provide a great opportunity to keep on building and researching, to look for potential interest in both communities to pursue more generic use cases. If there is any synergy or interest in the componentries of both Sablier and Juicebox protocol, there can be a very good excuse to build something and raise funds for both communities in the future.

Potential use case of Nance​

Jigglyjams had the thought of finding a way to create the business model of Nance project, which allows their users to pay Nance project to get their project tokens which will in turn be used as credit credentials for using the services of Nance. As there will be ongoing uses or subscriptions of their services, Jigglyjams was wondering whether there would be a possibility of using the Sablier token streams as a way of funding for Nance.

Jango thought that the current model of this Sablier interop will be a payout split allocator for projects to arrange their outgoing payouts, while the needs of Nance will be accumulating funds into a project from many different users, so it didn't seem that what Nowonder had been developing right now might automatically be useful for Nance.

Nowonder thought that it would probably work by setting a project like Nance as the recipient of token streams, and it would be a really cool idea since users now could use token streams to subscribe some services of a project and cancel the subscription by simply canceling those token streams . Jigglyjams agreed with him that this might be some kind of mechanics that our protocol is currently lacking for users to make payments continuously, which would be a great direction to research further.

ETH Global Partnership Updates by TJL​

Tjl said that they had been thinking about the partnership of hackathon events with ETH Global, and they had made some really good progress in this respect. But after some discussions among the Peel team, they came to the conclusion that, given the current challenges that are preventing us from finding the PMF (Product Market Fit), it might not be a perfect timing for us to implement the partnership with ETH Global right away, for the reason that currently we might be able to fulfill the needs of hundreds of devs from these events in a best possible way.

So Peel team were proposing a big change to our front end development, and Tjl called on community members to read the proposal by Peel team and share their thoughts and feedback for this matter.

Buyback Delegate Updates by Jango​

Jango had announced the depolyment of Buyback delegate last week. Right after that, the contract team thought of a small optimization which would improve the working logic of this delegate, so they decided to get back into coding and add this detail, before officially pushing out the delegate and suggesting people to attach it to their projects.

When people pay a project and expect the buyback delegate to work, this change allows them to specify a portion of the payment to be routed towards AMMs for swapping, while the rest to be allocated towards the project treasury and mint new tokens.

Originally, in a case of insufficient liquidity in the relevant token liquidity pool, the buyback delegate will skip the swapping operation altogether and route all the funds back to the project treasury to mint new tokens. With this update, it allows the delegate to get the most out of the liquidity pool first, while routing the leftover funds to the project treasury.

New Edit Cycle Page with JohnnyD​

During this town hall, JohnnyD shared his scree and compared the difference between our current cycle configuration page and the new page he had been working on.

For the old one, we had four main sections (Funding, Token, Rules and NFTs), which would expand to their sub-sections on the side of this page.

And in the new design, everything had been arranged into one single form, with different sections categorized into various fields.

And Peel team had reduced the original four sections to three sections of Details, Payouts and Tokens, while they were planning to take the NFT section out of this cycle configuration payge and make it a separate page. Also they had included a few links of educational content, to help project creators better understand the native concepts of Juicebox protocol during this process.

Also on this new cycle configuration page, once details are edited and changes are saved, there will be pop-up Review and Confirm window to specify all the changes, before users want to finally deploy the changes onto the blockchain.

At the moment of this town hall, this was still a feature under development, and JohnnyD called on our fellow members to try using it and provide feedback to Peel team. To try this new feature, you can go to the feature flags of Juicebox, enable the newCycleConfigPage and refresh on the settings page of JuiceboxDAO or other projects.

Tax Q&A with Zactt​

Zactt comes from TokenTax, he joined our town hall and helped answering the tax related questions from our community members. His opinions only represent his personal views and don't constitute any tax or financial advice.

Tax implications of gift cards​

When asked if buying gift cards with crypto has the same tax implications with selling a same amount of crypto, Zactt responded that the answer is yes. He explained that every time you make a trade of anything, you are actually selling something and buying something else. So if you use ETH to buy a gift card, essentially you sell ETH and buy US dollars, before putting those US dollars immediately into a gift card.

At a high level, selling or disposing of any crypto is a taxable event in most countries, which is definitely the case in the U.S.

Impact of different cost valuation methods​

Zactt also introduced that, when we were selling cryptos, the use of different inventory / cost valution methods may make very big difference in termst of taxable income / gains, which in turn would lead to very distinct tax amount.

He gave an example by assuming that we had bought three Bitcoin at three different prices sequentially, one at USD1,000, one at USD50,000 and one for USD10,000. If we sold one of the Bitcoin, we could have very different tax scenarios with different cost value methods. For example, assuming the current market price of Bitcoin was USD30,000,

• If we used FIFO (First In, First Out), then the cost would be USD1,000, and the capital gain was 30,000 - 1,000 = 29,000.
• While using LIFO (Last In, First Out) would make the taxable capital gain: 30,000 - 10,000 = 20,000.
• The third choice would be specific identification which tracks the costs of all specific items, and it would turn the capital gain all the way around if the highest cost was used: 30,000 - 50,000 = - 20,000.

If the assets were all sold in one time, the use of valuation methods wouldn't make much difference. But if not, the methods used would change the timing of these capital gains, and it would always be better to defer the taxes into the future.

Ordinary Income and capital gain / loss​

If people work for an organization and get paid in ETH or other crypto currencies, but they don't have the intent to sell those cryptos and rather hold on to them, they will have to report it as income and pay estimated tax within the same quarter. The tax will be calculated on the basis of the price of ETH at the time of its acquisition.

And if the ETH price drops in the future and they sell their holdings at a discount, the difference will be regarded as capital loss. And as capital loss can not be used to offset ordinary income, they will still need to pay income tax according to the original value of their income, while each year having only 3,000 quota of capital loss that carries over to offset ordinary income. But if they do have other capital gains, they will be entitled to offset them with their capital loss altogether.

For example, if you get paid 30 ETH and the price of ETH is USD3,000. You will owe the income tax for USD90,000 income to IRS within the same quarter that you are paid. If the price of ETH drops 50% and you sell it out at USD1,500, you will still owe taxes for USD90,000 income, but now you have USD45,000 realized capital loss.

For this reason, Zactt suggested that, if you are getting paid in crypto, and even if you really believe in the future of this project, it would be a smart thing to sell half of your income into fiat currency and set it aside to pay your taxes.

The due dates to pay your taxes quarterly in the U.S. are April 15th, June 15th, September 15th and January 15th of the following year.

Questions from EU based members​

We have a few EU based contributors wondering who they should invoice to when they get paid since the DAO is not an legal entity, and whether they should pay VAT as JuiceboxDAO doesn't have a clear jurisdiction.

Zactt replied that every country has their own rules, but he would suggest that they report their income to the government, assuming that they are self-employed as sole proprietors.

As far as VAT is concerned, he suggested that they research the VAT law in their own countries, and be more conservative when paying their taxes.

Sablier Interop Updates by Nowonder​

The Sablier interop contract developed by Nowonder is a split allocator that can be deployed as a part of funding cycle splits of Juicebox projects. When the split allocator receives payout in ETH, it will deploy splits of token streams as pre-configured in the project's funding cycle. Basically, it helps projects to allocate their payouts in one token to many streams of different tokens. For example, a project with ETH in its treasury can deploy payouts to multiple recipients with streams of different tokens, such ETH, USDC, JBX and etc.

It uses the same swapping logic that our buyback delegate is using, because Nowonder thought that it would be the best choice since those contracts had been audited and proven reliable. When the split allocator receives ETH from the payment terminal of a project, it will get a quote for the token that pre-configure in the project's funding cycle and route the ETH to swap those tokens.

And the interop contract supports all the Sablier types of streams, such as linear with duration, linear with range, dynamic with deltas and dynamic with milestones, which control the way that token will be vested to their intended beneficiaries.

Also Nowonder added a CI (Continuous Integration) to the repo, in case anyone interested in this project might want to work together on its development.

Finally, Nowonder said he would also show this project to the Sablier community, hopefully sparking some interest in Juicebox protocol and how it might be used in their community.

Matthew and Brileigh had recorded an interview with Paul, the lead author of Sablier contracts, and they talked about what Sablier is and the upcoming interoperation between Juicebox and Sablier that Nowonder is building. This interview covers a high level overview of what's being built and how it can be used with Juicebox, as well as serving as an introduction of Sablier to our community.

At the time of this town hall summary, Matthew and Brileigh had released this interview on the JuiceboxDAO Youtube channel.

Buyback Delegate Deployment by Jango​

Jango announced that we had deployed the Buyback Delegate contract after resolving some important little details. The only thing left to do is to attach it to a project and see how it play out in the wild.

Whether the incoming payments to a project get routed to an AMM to swap tokens there, or to the Juicebox contracts to mint new project tokens, will be affected by the current circumstances of the relevant liquidity pool.

Also it will also be affected by the way the pay function is called, either being called from the outside world from a web client like juicebox.money, or being called by another smart contract in the protocol.

In the case of being called from the outside world, the web client can pass to the buyback delegate the expected swap price and its slippage tolerance, which will be important for the trade to be executed in a reasonable range, otherwise the trades might be suject to MEV attacks from adversary players on the blockchain.

In the other case, where the pay function is called as a part of another operation, such as someone calling distributePayoutsOf which will trigger the payment of Juicebox fees, it will be impossible to pass in the quotes and slippage at the same time. So the contract crew had decided to use instead a TWAP (Time-Weighted Average Price) oracle to determine a reasonable quote and slippage range, to create the boundaries for these trades.

These were the two aspects our contract crew had tried to research very thoroughly, but it would be very difficult to do things very precisely in a testing environment. That is the reason why we would still have the delegate battle-tested in the open world, and try to fix any inefficiency from there.

The next steps will be some collaborations with the Peel team to figure out how to allow payers to specify the parameters of trades, or at least we will provide the quotes and average expected slippage in the front end in some way for them to make their choices.

The contract crew had written a library to allow not only clients to pass data to one delegate, but also Juicebox projects to attach to themselves multiple delegates, such as a buyback delegate and an NFT delegate, at the same time.

The buyback delegate should give a lot more price efficiency to everyone involved, including the reserved token recipients. If ETH funds are paid into a project deployed with buyback delegate and there is a better price on the secondary market, the project treasury will not take in the funds and mint new tokens correspondingly, but instead route the funds to the market and get the best price there before allocating the tokens between payers and reserved token recipients.

Alongside with the deployment of buyback delegate, there was also the payment terminal 3.1.2 deployed which fixed the Hold fees calculation error, and a 721 delegate update which uses the new metadata pattern to support multiple delegates attachment to a project, as well as the payment terminal 3.1.1 spec for passing data from a data source to a delegate.

Bananapus Update by Jango & Filipv​

First Governance Voting​

The Bananapus community had voted on their first governance proposal this week, distributing payouts to conributors who made their contributions to this project and updating the reserved rates for all the current contributors.

Working Mechanism of Bananapus​

Bananapus project consists of three main components, Bananapus 721 staking delegate, Bananapus distributor and Bananapus tentacles. They are going to work on Ethereum Mainnet and other Layer 2 chains respectively.

Mainnet - Step 1::

1. Token Issuance. Juicebox Project A accepts ETH and emits project tokens (Token A) in return, and Token A can be used to redeem a portion of ETH in the treasury if there is overflow. Project A operates exactly the same as the current ordinary Juicebox projects. For example, you can pay JuiceboxDAO project to get JBX tokens.
2. Staking: Now we will create a new project B next to project A. Project B runs with very fixed rules and doesn't have any project owners or payouts, it accepts Token A and emits tiered NFTs back out. These NFTs can be used for purpose of governance voting either on-chain or off-chain, and also can be burned to redeem Token A. This process is implemented by Bananapus 721 staking delegate. For example, you can stake your JBX tokens to get an NFT representing your staking position.
3. Staking Rewards: Project A or any other project can now route a portion of its reserved tokens to stakers / holders of NFT as staking rewards. This part is implemented by Bananapus distributor. For example, JuiceboxDAO now can allocate 10% of its reserved JBX tokens to be shared among whoever is staking JBX.
4. Vesting: The staking rewards are vested over a locked period of time. If a position is unstaked, any unvested tokens will be forfeit, allowing the project to share its growth with token holders who are committed over time.

Layer 2 Blockchain - Step 2 (in prototype) :

1. Token minting: NFT representing staking postion in Step 1 can be used to mint an ERC-20 token that will be bridged over to a specific Layer 2 blockchain. This is implemented by Bananapus tentacles contract. For example, NFT of staked JBX can be used to mint the OPJBX up to the same amount of JBX staked for this position, which will then be bridged over to Optimism blockchain.
2. Staking: The OPJBX can be staked with a Bananapus 721 staking delegate in the JuiceboxDAO project on Optimism, just in the same way as what's happening in Mainnet.
3. Staking rewards: Now JuiceboxDAO project or any other Juicebox projects on Optimism can route a portion of their reserved tokens to OPJBX stakers via the Bananapus distributor contract deployed over there.
4. Vesting: same as in Step 1.

Instead of having one organization that exists and issues its identical project tokens across all these networks, and all of which are redeemable for one single project token supply balance, a project can have smaller treasuries on various respective different chains, and have tentacles for any number of chains. Anyone can deploy their own network of cross-chain operations, and there is no permission needed.

We will use Bananapus's project token $NANA to demonstrate a full end-to-end example in the next few weeks. All the components are ready, they just need to be tested, and supported with nice UI to help smooth out the process.

This mechanism can scale to any number of interactions across any number of chains, because one JBX staked position can be used to create many tentacles respectively for various L2 chains. But in order to unlock the staked Mainnet JBX, stakers will have to return all of their tentacles, essentially destroying everything in order to access the original JBX again.

Juicebox Merch by Sage​

Sage's proposal to produce and distribute Juicebox Merch is currently under Snapshot voting. The goal of this proposal is to distribute Juicebox merchandises, such as stickers, hats. T-shirts etc., on ETH NYC in September to help propagate Juicebox ecosystem.

And Sage also thought of sending any leftover, or holding 25% -30% to people who are not able to attend the ETH NYC event. Jango suggested that we can send them out in batches to someone, so that when they go to conferences or events, they can hand them out from there.

The grants that Sage was applying from the DAO is USD4,000, and Sage was planning to include all the distribution cost so that basically people can get the merch for free in stead of having to pay for them.

Jango and Sage both agreed that it would be a good idea to do a simple vote and let the community choose some designs that will be put on the merch. And any ideas or suggestions about the designs of merch will be warmly welcome.

Peel Updates​

Rich Text Editor Demo by Tjl​

This is a feature that has been requested by many projects, for more customization and control over the project description. With this new feature, project owners can edit project description with Markdown formats, images and links, etc.

Hopefully this feature would help strengthen project's About section and give owners more freedom in providing detailed infomation about their projects.

Currently there were still some bugs in this feature, Peel team would fix those problems and deploy this new feature once everything was ready.

New Payouts Table Demo by JohnnyD​

At present, if the project owners want to edit someone's payout, they will need to go into a separate modal to adjust the numbers of that payout.

JohnnyD had been working on the new edit cycle form lately, and he had made a new payouts table to help editing the payouts more conveniently. Owners can edit everyone's payouts directly from the table without needing to open a modal for each payout again.

This will be easier for project admins to know exactly how much is going out of the treasury, and more importantly, the actual amount of Juicebox fees incurred with these outward payments will also be updated simultaneously with the editing of payouts.

Hopefully this new payouts table will give people a much better idea of what's happening with the distribution limit and the Juicebox fees that will be incurred with the payouts.

Peel team was still working to get this table to production, after some more reviews and tests to make sure it is functioning well as expected.

Create Flow Education Sneak Peak by Tjl​

Peel team had been putting quite some efforts into overhauling the create flow with user's education in mind, and Strath had been the one responsible for this work. Realistically the goal is to let people create a project from start till the end without needing to look too much to the contributors team for support or help, making the create flow as self-serving as possible.

Obviously one of the biggest challenges in this respect is about how to let the native Juicebox concepts, one of the hardest things to comprehend, play into the create flow much more intuitively and easier to understand along the way.

Peel team also introduced a few thigs to help increase project quality.

Firstly, when users click to create a new project, there will be a splash screen that gives them some tips to create a project, etc.

The team is also introducing the drafts, so that project creators can go back and forth without launching a project or having to reconfigure before all the details are finalized.

And more importantly, there will be a little educational panel on the right hand side of the create flow page, which will be fully collapsible if users feel that they don't need this kind of information while being well aware of the choice there.

Keyp Integration and Fiat Checkout with Peri​

CupOJoseph, the founder of Game Wallet, is going to launch a project on Juicebox to sell his Gameboy wallet cartridges as a hardware wallet. At this moment, the Game Wallet has got about 10,000 people on their waitlist, while the project team is still finalizing some details, one of which being the ability to pay not only in Ethereum, but also in fiat as well, so that the project can be open to a wider audience.

Peri, who is the person mainly responsible for the support of this Game Wallet project, said that there are currently two important components in this upcoming project.

The first one, also the main problem for Game Wallet is concerned with the fiat checkout integration, as right now payment to a Juicebox project is still limited to ETH. The integration that Peel team is building right now is to make use of POKO platform, so that when users are paying a project, they have the option to transfer to an embedded form to check out with fiat. The working theory behind the scene is to buy ETH on payer's behalf and automatically transfer them into the relevant Juicebox project.

But the dilemma here is that, we will still require payers to have a crypto wallet connected to the project, so that we can have a place to send the project tokens minted from the payments. This in turn give rise to the second important components of this project. We're going to integrate with Keyp, which is a service that allows users to authenticate with an email adress and create an account to be allocated with a crypto wallet address. With that integration, when users click the connect button on the Juicebox app, they will have the option to use between a standard EOA wallet or the Keyp wallet. The Keyp wallet will work totally the same with a normal EOA wallet, including sending transactions or checking balance, etc.

Tjl thought that we could further discuss the possibility of making these integrations generic for all other projects to use, also there might be some other unforeseen potentials on the horizon for us to explore in this respect.

Hackathon Partnership Discussion​

Tjl introduced that the Peel team had been reaching out to some hackathon companies and platforms to talk about the possibility of coming into a partnership with them, in a hope to get some hackathon projects onto the Juicebox protocol and help them raise funds to further improve their development.

He said that we had come into verbal agreement with both ETH Global and Devfolio, to run a trial partnership during the period from mid September to January. If we get it right, we coud become more hackathon tooling oriented with constant projects coming in from developers.

Mieos said that the WAGMI team is thinking about how to make sure that we use the hackathon events as great brand moments to propagate Juicebox not only in terms of technicalities, but also through its cool Juicebox culture, vibe and art.

Jango suggested that other members of our community in the broader ecosystem could contribute to these efforts as well. He also saw an opportunity to create alignment and collaboration throught various events, such as presence and active involvement of our contract crew in hackathons, and partnerships with other communities.

He also took Thirsty Thirsty, a community that arranges more food and beverage oriented events, as an example to get inspiration of how we move into these hackathon worlds and physical land, how we can encourage a cross-disciplinary ecosystem emergence, following and supporting Tjl's efforts.

Jango thought that it had been pretty clear that the Banny is definitely a top-of-funnel phenomenon, especially with our experience and the feedback from the pay delegate hachathon we ran last month. But it takes time to really grok how it can be useful and how we might lead the way.

Buyback Delegate Updates by Jango​

We now have a buyback delegate version that will be easier to deploy and attach to a project. Our contract crew is now piecing together the accompanying contract that will be generic for any project to initialize from.

The metadata standard for the 721 delegate is now complete. Our contract crew will work with the front end team on how to pass metadata to delegates or the pay functions under the new standard, which will help projects attach multiple delegates to their projects and pass information to them cleanly so that a project can have both buyback delegate and 721 delegate attached.

The team aimed to have everything deployed by the end of this week, but it was definitely worth more time to address some of the final trade-offs, between getting things baked in forever from the beginning and allowing for granular control over time.

Now we are just left with a few of these concerns which are mostly risk management related, but generally everything is looking good and Jango felt excited to deliver this product very soon. It feels like so many potentials are unlocked with this delegate and we will see them come to fruition over the next couple months.

Hopfully we would have a really tight spec for Juicebox.money to follow if it wants to integrate with new stuff sooner rather than later.

Jango thought that JuiceboxDAO would be ready to take on buyback delegte as soon as it's proven reliable. He was grateful to everyone that accompanied and voted on the proposals to get the termials to their most robust state.

Bananapus Updates by Jango​

Jango thought that we would probably have some prototypes in the upcoming weeks. He would be very stoked to see some prototypes that people can play with the soonest, because he thought that would be increasingly relevant part of Juicebox's future, especially as we started to get into hackathons and people had the option of launching projects to get paid in them. We need to make sure that people can do so on cheaper chains and not be locked there.

The beauty of Bananapus is that we are basically creating options for projects to start on a particular chain and then they can evolve easily around the ecosystem. This is a very flexible patten. As it's pretty abstract to most folks, Jango expressed his willingness to continue explaning the working mechanisms of Juicebox protocol in the Solidity Sesh video series, hopefully helping people deepen their understanding and try out their ideas.

He also hoped that the dev efforts of Bananapus would end up merging really nicely with the convenient wallet connection and fiat checkout mentioned earlier during this town hall that Peel had been building. Certainly this will be a longer term effort, but he insisted that we shoud continue exercising that muscle of grokking what that means for the whole ecosystem.

Although he thought that Mainnet is always going to be the place where the larger pockets of experiments happen, but we definitely need the protocol to extend past mainnet for things to really improve and get accessible, and we are inching towards a place where people can start off in cheaper environments with real tradable volumes and then over time take up multiple footprints across chains, which sounds very exciting.

Sablier Interop Updates by Nowonder​

Nowonder's proposal to integrate Sablier with Juicebox had been approved by the DAO lately, in this town hall, he expressed his gratitude towards our community for allowing him to work on this job.

The Sablier interop is basically a split allocator that allows project owners to deploy Sablier Stream to distribute project tokens to people in a granular manner over time.

According to Nowonder, the major use case of this integration lies in where project owners want to onboard new contributors, while not being too sure whether they deserve the payout. Project owners can issue streams of token to new contributors and cancel those streams if the work doesn't turn out to be satisfying. Basically his main point is encompassing everything under a single contract, the split allocator contract, which will also be an admin panel and a user interface for people to withdraw from their streams. Both project admins and users can interact with the same contract for their respective purposes.

Another feature that Nowonder was thinking of adding to it is either an ETH reserve or a project token reserve, which would allow project owners or their operators to add new streams even if they aren't instantiated when the allocator is deployed in the very beginning.

Jango thought that this looked sound and great for prototyping to really leverage the opportunity. It would be cool to introduce more about Sablier to our community, and Juicebox to theirs, as well as how in the future the tool Nowonder was going to build would be worthwhile for projects to try for themselves.

Jango also suggested that we consider making a Juicecast episode or some coverage on Juicenews, in order to support and inspire in both directions in a consistent manner. He thought that a large part of the next sequence of the Juicebox project as a whole essentially lies in the integration with all these other communities.

Nowonder and Matthew both agreed with this idea and expressed their willingness of making a joint effort to produce a Juicecast episode.

And Nowonder also announced his plan to build a split allocator template, for the purpose of dev documentation so that somebody could understand how to start writing tests and forge for a split allocator of their own.

Juicecast New Episode by Matthew and Brileigh​

Last weekMatthew and Brileigh had released a new episode of Juicecast, featuring the NFT influencer DeeZe.

And they were also planing to do a Twitter Space with The Dapp List next Wednesday. The Dapp List is almost like an index and a curated selection of Dapps in the Web3 world, where Juicebox is also curated. They are going to talk on this Twitter Space about how Juicebox works and how people can make use of it.

Jango acknowledged and appreciated the efforts of the Juicecast team, i.e. Matthew and Brileigh. He thought that the Juicecast channel now feels warm and consistent, finding a rhythm and groove that listeners really enjoy. Jango also extended his thanks for their capturing various works, including encouraging developers to record content and then managing the post-production work afterwards.

Jango thought that there had been a lot of insightful and educational content created that goes unnoticed due to everyone being busy working with their own projects. He encouraged cross-disciplinary collaboration from our community to contribute to Juicecast channel.

Visibility Updates by Matthew and Brileigh​

Solidity Sesh Series New Episode​

Matthew and Brileigh had been producing the new video series of Solidity Sesh, together with our contract crew Jango, Dr.Gorilla, Viraz and 0xBA5ED, to introduce parts of the Juicebox protocol, about its specific contracts or the architecture of the protocol itself.

The first episode of this series was released last month, which was about the buyback delegate contract and the working mechanism of it.

Today they published the second episode, Payment Terminal Inheritance Structure, to introduce the inheritance structure of payment terminals and how the uses can build their own payment terminals for a specific ERC-20 token.

Jango introduced that the Solidity Sesh was inspired by folks who had been trying to build stuff on Juicebox protocol. For example, the new episode of inheritance structure got its inspiration from Nicholas's questions during his development of the project NFTs for Juicebox.

Hopefully this session will be a start of our efforts to help people understand more about the Juicebox protocol. Any feed back or specific requests to this series will be very welcome.

Juicecast New Episode​

They were currently working on the production of the new Juicecast episode featuring a NFT influencer DeeZe. This episode of Juicecast had been released at the time of this town hall summary.

Nance Sign-up Form Demo by Jigglyjams​

During the town hall, Jigglyjams demonstrated the create flow of a new Nance instance which was still work in progress, and he called out for thoughts or feedback on this prototype. This was supposed to help other Juicebox projects to implement their governance process, making Nance a generic governance tool available for use in the Juicebox ecosystem. With this, projects should be able to unfold their governance procedures from drafting proposals, Discord community temperature checks and Snapshot voting with project tokens, etc.

The preliminary process of creating a Nance instance will be:

1. Users need to authorize to add the nance-bot into the Discord server that they have admin permissions.
2. Then they can choose a channel for nance-bot to post new proposals to, where community temp checks will be taking place.
3. Also users can link nance-bot to their Snapshot space as a member, so that it can automatically post on their behalf the proposals passing temp check to the Snapshot page for the next voting phase.

In this create flow, users can name their own Nance space, put a custom prefix to proposal IDs, and link this space to an existing Juicebox project. And a calendar of governance is also available to check the different phases of governance cycles with a starting date specified by users.

Jango suggested that maybe someday in the future Nance team can think of some iteration where users pay and mint tokens from the project of Nance, and then use those tokens as credits for their usage of Nance's governance services.

Also he thought that maybe Nance can work more intimately with Juicebox.money website, probably even consider integrations with the project create flow, so that project creators can easily plug their projects to a governance system. Jigglyjams agreed with that, and said that he had been contemplating with the idea of a community starting off from a Snapshot and Discord server and launching their Juicebox project from a community proposal voting with the help of Nance.

Finally Jango mentioned the possibility of making use of Nance in those forthcoming retalist projects like Defifa and Croptop. These projects will be unowned and without any project owners, while a certain percentage of reserved tokens will be vested to a multisig for an initial duration of time as incentives for founding members.

Payment Terminal Migration and Governance​

In the end of this town hall, Nowonder raised a question about whether the payment terminal migration needs to go through the governance process before it is executed.

Jango explained that the way the protocol works is that anyone can deploy whatever contract they want without needing to ask permission from JuiceboxDAO. But if they expect the DAO to make use of the new contract or they want to get refunded for the expense of deployment, they will have to submit a proposal to that effect and get the approval from the DAO.

The migration of payment terminal is just a process of adding the new payment terminal to the contract library. As long as it adheres to the interface, anyone can call the migrate function. JuiceboxDAO doesn't need to give permission for any other projects to make something new up and move their things over there.