Ripple Case Discussions and Q&A​

On this town hall, we had a guest, Rob, a securities attorney, to come over and share his thoughts on the recent Ripple Case which was considered to have great implications on the cryptocurrency 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.

Introduction of the trial results​

Rob thought that one of the main reasons for the SEC being quite hostile towards crytocurrency stemmed from the concerns that sales of garbage tokens to retail customers might result in lost of their savings and make them "ward of state" which incurs burden to the state.

In this trial, the SEC sued Ripple Labs and its two senior leaders as engaging in unlawful offer and sale of securities in violation of securities law, and the judge Analisa Torres ruled that Ripple's sales of XRP to institutional buyers were considered as securities, but XRP itself is not a security.

The judge also distinguished three categories of sales.

• Institutional sale, to large investors like VCs, hedge funds, etc.
• Programmatic sales, which were made through digital asset exchanges to retail investors.
• Distribution of tokens to employees or partners.

While the institutional sales were regarded as securties and in violation of securities law, the judge ruled that the programmatic sales to retail investors were not against the law, because buyers couldn't tell if they were buying directly from Ripple Inc. or from a secondary seller. And because the buyers didn't know who they were buying from, they couldn't reasonably expect profits from Ripple Inc, so the these kind of sales didn't pass the Howey Test as being securities.

The judge also ruled that the distribution of tokens to employees or partners didn't pass the Howey Test either, because there was no exchange of money involved.

If we take Judge Torres' opinion on this literally, it seems like tokens might be able to be issued by being put in a liquidity pool in AMMs like Uniswap, instead of being sold directly from a corporation or its issuer. Since people don't know for sure who they are buying from, the token doesn't meet the requirements of being a security.

Programmatic Distribution of Tokens​

Jango was wondering if we could have a clear definition of the programmatic distribution of token, and if it's just a general term that has more layers of interpretation underneath.

Rob responded that in the legal opinions of this case, a programmatic distribution equals to a blind bid/ask, where you don't really know who's on the other side of the equation.

And he thought of a permissionless decentralized cryptocurrency more as a bearer asset , instead of a contractual right that a court can rule over its ownership. So Howey Test can't be applied here unless there's an exchange of money and a reasonable expectation of profit from the managerial or entrepreneurial efforts of others.

Even the SEC had admitted the secondary sale can't be defined as investment contracts. It doesn't make sense from a legal perspective because people just can't automatically be contractually bound for buying something from other random people.

Legal Implications on Juicebox Community​

Jango said this was a very interesting case to us, since we had spent a lot of time building these open protocols that have hard-coded contractual locks set in different ways. He thought that a lot of what we did was open-ended and could be expressed in various ways, and each way might have different implications from a legal perspective.

Now in Juicebox ecosystem, we have projects where their owners can make edits over time depending on how the parameters are configured, and also projects that are ownerless and running itself as an independent entity besides the will of the people involved. There are lots of ambiguity and probable forthcoming questions with regard to different setups.

Rob thought that we might still need to wait until this case runs through all these legal procedures, when legal opinions of judges finally be turned into the law of the land.

Global Implications of This Case​

LJ asked for Rob's opinios on whether this case would have some more effects from a global perspective, as people on Juicebox or other platoforms in Ethereum might be based in other jurisdictions. He wondered if Rob think this case would be called for action in those other jurisdictions, esp. those more crypto-friendly like Dubai, Singapore or Hong Kong, etc.

Rob thought that this case might probably help to ease the geoblock by some companies on American participants, which had been set due to the uncertain regulatory landscape and government's hostility towards crypto.

He didn't think other jurisdictions like Dubai and Hong Kong would likely look to the U.S. for what to do next. Also the Howey Test is a very very American style, and other jurisdictions might not agree with this interpretation of laws. They might probably be structuring their crypto policy based on their onw interests.

Possible Impact on DAOs​

Kenbot from StudioDAO was wondering if this trial would have any impact on the DAOs, and Rob said this case might make it harder for DAOs to defend themselves against regulatory agencies, esp. those with limited resources.

And for the UNA (Unincorporated Nonprofit Association) that many DAOs like to take as their organizational structure, it may help in limiting the liability of its members, implementing some kind of governance, and even appointing a manager and hiring legal representation.

If the legal opinions of Judge Torres become the law of the land someday in the future, DAOs may be able to issue their tokens by selling to institutional clients and filing for a private placement exemption before even letting those institutions do the secondary sales, while also distributing the tokens as incentives to their contributors or partners, etc. It seems to be an easy way of proceeding with a token launch.

Impact on Designing Treasuries And Decentralized Projects​

Jango said that it would be interesting considering from the point of view of designing treasuries that are trying to renegotiate pre-programmed relationships between all kinds of internet parties. In the case of blockchain, it's intermediated by a pre-agreed upon set of rules.

He thought that it might be tempting to only create things following the model of the Ripple case because it has provided some sense of clarity. However, he thought there would still be plenty of room for creativity and exploration, and various kinds of expressions for these relationships to play out.

Rob added that this was a very well litigated case by a very influential judge, so we might be able to take it as a fair notice of laws concening whether a certain token should be considered a security.

Migration to Payment Terminal 3.1.1 by Filipv​

The proposal to deploy buyback delegate for JuiceboxDAO had been approved by the DAO last week. The first step in the execution of this proposal woud be to migrate the payment terminal of JuiceboxDAO from 3.1 to 3.1.1.

This new version of payment terminal fixed a few bugs and optimized gas usage, while also introducing a Juicebox membership fees on redemptions when the redemption rate is set at lower than 100%.

On the town hall, Filipv executed the switching of payment terminals successfully in real time.

Hold Fees Calculation Error Postmortem by Filipv & Jango​

We had a medium severity error in the hold fees calculation on the JBPayoutRedemptionPaymentTerminal3_1, which was discovered during the fundraising campaign of the project Legend. This project had the Hold fees enabled and transferred the raised funds out for an auction. When the funds were returned back to the project for full refunding after the auction, a discrepancy occurred due to a erroneous calculation of the payment terminal, which resulted in a slightly lower refunding than the expected 100%.

Filipv had published a postmortem on this issue to explain in detail the reason of this error and the remedy to it.

By the time of this town hall, Jango had created a PR to update the payment terminal to 3.1.2 to fix this bug. Filipv suggested that project owners should avoid using the Hold fees feature before the new version of payment terminal 3.1.2 is deployed.

Buyback Delegate Updates by Filipv & Jango​

The audit report for buyback delegate by Code4rena was expected to be published very soon. After some last improvements and updates that needs to be made to the contract, hopefully the buyback delegate should be deployed within a few funding cycles.

Jango expressed his appreciation to 0xBA5ED for his great contributions in contract reviews during the last period of time, as well as to Viraz and Dr.Gorilla for their very foundational contributions to the open source set of protocol components.

Feedback on Documentation by Hackathon Participants​

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

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

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

A Runthrough of Hackathon Submissions​

1. Instant Swap Delegate​

Submitted by: Aeolian

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

Repo: https://github.com/tomquirk/juice-delegate-hackathon

Demo: https://goerli.juicebox.money/v2/p/1097

Team Juicebox project: https://juicebox.money/@etherfunkio

2. JuiceTable​

Submitted by: LJ

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

Repo (smart contract): https://github.com/boyuanx/JuiceTable

Repo (frontend): https://github.com/jbettenc/juicetable-interface

Demo: https://youtu.be/XFwiadWq0YI

Team Juicebox Project: https://juicebox.money/v2/p/540

3. JBStraws (Merkle Root Whitelist)​

Submitted by: nowonder

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

Repo (smart contract): https://github.com/simplemachine92/JBStraws-Contracts

Repo (frontend): https://github.com/simplemachine92/JBStraws-Interface

Demo: https://juiceystraws.vercel.app/example-ui

Team Juicebox Project: https://juicebox.money/v2/p/542

4. JUICYBONUS​

Submitted by: Meme Man

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

Repo: https://github.com/Narwhal8/galactic-brain-delegate-just-trust-me-bro

Demo: https://youtu.be/dyB58nUyAkk

Team Juicebox Project: https://juicebox.money/v2/p/539

5.DominantJuice​

Submitted by: Armand

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

Repo (smart contract): https://github.com/Starmand6/dominant-juice-hack

Repo (frontend): https://github.com/electrone901/Dominant-Assurance-Juicebox

Demo: https://dominantjuicebox.netlify.app/#/

Team Juicebox Project: https://juicebox.money/v2/p/543

6. JuiceboxDataSourceAggregator​

Submitted by: weaver

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

Repo: https://github.com/calcifer11/JuiceboxDataSourceAggregator

Team Juicebox Project: https://juicebox.money/v2/p/544

Thoughts on Front End Support in JBM​

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

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

Buyback Delegate Proposal Introduction by Jango​

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

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

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

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

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

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

Dev Oriented Videos and Juicecast by Matthew and Brileigh​

Buyback Delegate Introduction Video​

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

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

New Episode of Juicecast featuring Nicholas​

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

EthCC Guide by Bruxa​

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

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

Retailism by Jango​

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

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

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

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

Retailism​

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

A Retailistic View on CAC and LTV​

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

Modeling Retailism​

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

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

Retailism for Devs, Investors, and Customers​

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

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

Peel Updates and Demo by Tjl​

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

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

Juicebox 2nd Anniversary Reflection​

Development history​

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

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

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

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

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

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

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

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

L2 Deployment​

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

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

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

On the Upcoming Year​

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

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

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

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

"Year of the Dev"​

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

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

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

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

ETH Waterloo Updates by Nicholas​

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

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

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

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

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

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

Delegate Hackathon Updates by Jango​

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

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

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

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

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

Bananapus Demo by 0xBA5ED and Jango​

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

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

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

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

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

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

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

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

Buyback Delegate Updates by Jango​

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

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

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

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

Legal Template Library by LJ​

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

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

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

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

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

Croptop Template Updates by Jango​

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

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

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

Defifa Updates by Jango​

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

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

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

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

Use Case Video by Matthew and Brileigh​

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

State of Crypto Philanthropy by Bruxa​

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

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

Peel Updates by Tjl​

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

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

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

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

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

Juicy Picks Poll by Aeolian​

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

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

ETH Shanghai Meetup Updates by LJ​

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

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

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

Speech at ETH Waterloo by Nicholas​

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

Nance Updates by Nicholas​

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

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

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

Croptop Updates by Jango​

Jango and Livid had done a lot of work to make the Croptop template support posts of audio, video and Markdown formats, so that now users can post whatever snippet of content on their ENS websites and have them all linked back to their Juicebox treasuries.

They had worked a lot in CID (Content Identifier) to make sure the content was being correctly displayed and funneled into minting process.

During the town hall, Jango showed us a website created with Croptop template but not yet pinned to an .eth domain, and demonstrated how to post and mint these contents of different formats onto a Juicebox project.

Jango had been playing with some treasury design stuff recently for both Defifa and Croptop, which had in turn led to his reflections on where JuiceboxDAO's intitial treasury design started, what were some learnings, what were some things to take into consideration moving forward, and what were the experiments Jango was eager to try. Jango wrote down his thoughts in the blog post Treasury Design Reflections on his personal ENS domain website.

In the blog post, Jango proposed some treasury designs he thought would apply decently well to projects like Croptop and Defifa. But he also thought that this design was still up for discussion, so he ecouraged folks with doubts or curiosities to come forward and share their ideas, so that hopefully we could make a better design in this respect.

Jango gave an example of a possible treasury design for Croptop in this town hall.

This Croptop Publishing Network project will collect 5% fee when anybody posting on this project using Croptop template. $CPN project token will in turn be issued at a ratio of 1,000,000 / ETH with a decreasing cadence of 4% each following cycle (28 days). 10% of total $CPN issuance will be reserved to a multisig for two years, with a reconfiguration to remove this reserved token allocation scheduled to start two years from now. Also a 70% redemption rate is set so that $CPN holders can choose to claim their share from the treasury anytime if they want. Ideally a buyback delegate will also be attached to the cycles so as to guarantee payments will always get $CPN at its best price available.

Then the project ownership will be thrown away, or essentially be given to a wallet that doesn't have access to make further changes to this project. It will be an experiment to check if we can figure out enough incentives to have $CPN distributed to developers who are keen to manage this project. It is a setup that leaves the bulk of the treasury unmanaged, which means folks have certain guarantees when contributing to it, and ETH in the treasury can serve a particular purpose and everyone is playing by similar rules.

At that point, Jango hoped that "devs can dev, community can community and network can network" without too many isolated concerns and interest is equally aligned throughout.

Ideas of ETH Shanghai meetup by LJ​

LJ introduced that he was planning to host a Juicebox meetup during ETH Shanghai for Juicebox Chinese community from Jun. 26 - 30. His plan for this event were as follows:

1. Host a IRL happy hour, and submit a proposal to the DAO for financial support;
2. Organize workshops with some other DAOs that are buiding public goods, discuss about juicebox.money and how people can use Juicebox to raise funds, as well as the governance improvement of existing Juicebox projects.
3. Put Juicebox's logo on some merchandises (like T-shirts).

Peel Updates by Aeolian​

Latest work by Peel team:

1. Bookmarked projects by Peri. On a project page, users can now click the bookmark icon to save the project to their account for future convenience.

2. Improvements to the Safe page of projects by JohnnyD. If a Juicebox project is owned by a multisig, there will be dedicated Safe page for this project on Juicebox.money, so that people can check any queued transactions or the history of transactions.

3. Revamp of project page mainly done by Wraeth.

4. Thanks to Aeolian, Juicebox.money now supported the new JBTiered721Delegate V3.3 contract (NFT rewards), new project would be created with this new version.

Juicecast New Episode by Matthew and Brileigh​

Matthew and Brileigh had been on the DAO Talk interview hosted by Frission from Tally, to talk about Juicebox, about working in a DAO as contributors, about decentralized media, and about making content for DAOs.

Also they invited Tommy and Frission from Tally over to the new Juicecast episode, to talk about their views on the future of onchain DAOs. This new Juicecast episode was released shortly after our town hall.

Buyback Delegate Updates by Jango​

According to Jango, Dr.Gorilla had been working on some of the touchups after the Code4rena audit and Jango had also made a review on this work. Things were looking great, as soon as our contract crew went through all the questions found in this audit, the buyback delegate would be ready to use for Juicebox projects, and anyone can propose for the DAO to use it.

Jango was looking forward to using it in a few more experimental treasury designs, but he was not in a rush to put up a proposal for JuiceboxDAO to make use of it in a short period of time. Although he was definitely exited to try it in production, Jango also said he would be pretty conservative about this delegate, because it is a very big component that carries out some important functions.

Jango also believed that it had the potential to bring about significant changes to contributor operations, fee paying operations and investor operations, due to the way it work in the reserved and outward token issuance.

Defifa Demo by Kmac​

Defifa project had made some progress recently, and the team was starting to run some small games to make sure that the mechanics of the protocol and the front end UI would be working as intended, and hopefully get some feedback from users as well.

In the Town Hall, Kmac invited the audience to play a simple chicken-shit-bingo style game that he ran with Defifa.

Aeolian recently joined the Defifa team and helped improving some front end stuff and updated the codebase with a few libraries.. Most of the original codebase had still been those started and evolved by Blaz and Devian in the early stage of this project last yea, and their technical components under the hood were quite different from those being used on juicebox.money.

And according to Kmac, the NFTs are all dynamically generating SVGs that will reflect some information about the game, such as number of times they have been minted, and the different phases that the game evolves into, which means the state of the game will always be represented in each NFT in real time.

This SVG development had been carried out mainly by Jango, and Kmac was working to push it one step further to accept artwork uploaded by users, so that the NFTs would have custom artwork on one side, and full onchain SVGs reflecting the state of the game on the other side.

They wanted to get to a place where the game would be reflected inside the NFTs, so that no matter where people look at them, either from their wallets or makets like OpenSea, they can get a glimpse of the current phase of a game, or the NFT's backing value if the game is over and distribution is done.

And also according to Jango, the attestation process that they were about to try out for the Defifa project was based on a Governor Bravo contract, which Jango had been refactoring to make it more Defifa specific and lean. He thought that maybe this component could be reused, if other folks had similar game mechanics they wanted to implement as a state machine.

Buyback Delegate Audit Updates by Dr.Gorilla​

The audit contest of Buyback delegate on Code4rena had ended on May 23rd. According to Dr.Gorilla, the full process of auditing had not been finished yet. Our contract crew had reviewed the findings, acknowledged or disputed them accordingly, and Code4rena had yet to publish the final audit report at the moment of this town hall. By far, no bugs of high severity had been found, and only a few medium severity ones and some gas optimizations had been proposed to our contract crew.

Dr.Gorilla said that he had started implementing what was in need of improvement, expecting to get it done by end of this week.

Metadata Refresh Demo by Nicholas​

The Juicebox cards was a project which allowed users to mint an NFT to replicate the metadata of a Juicebox project and stay updated with its changes. This project was developed by NIcholas, and was now working at Juicebox.cards, but it was not yet finalized because there was still some work in progress as he needed to rewrite the contract to implement some more things.

Nicholas had been working on a Juicebox metadata updater. As the metadata of a Juicebox project is generated onchain, its values change over time. But when these NFTs are shown on OpenSea or other sites that relying on OpenSea, their metadata won't be refreshed real time, but rather with their cache stored in OpenSea. This Juicebox metadata updater helps updating the metadata of these NFTs on OpenSea so that the metadata shown there are always up-to-date.

Also Nicholas launched a fundrasing round on Blunt, to check if there would be enough interest in generlizing this product for all other 721 projects on OpenSea.

Delegate Hackathon Callout by Filipv​

Filipv was coordinating with Austin Griffith from BuidlGuidl to host a new hackathon on Juicebox. The plan was to make use of the leftover funds in BuidlGuidl's Juicebox project from their last hackathon, and some grants that Filipv had the thought of applying from JuiceboxDAO for support, and to implement this event as a joint effort of JuiceboxDAO and BuidlGuidl.

This hackathon is aimed at building new Juicebox delegates and/or data source for the use in the Juicebox ecosystem, and the draft game plan of it can be found here.

In the Town Hall, Filipv called out that folks with ideas about funds delegates or data sources can come forth and share them in our Discord.

Croptop Updates by Jango​

The development of Croptop had been close to its final stage, things were really starting to shape up, and Jango were eager to wrap it up and see how it unfolds.

To try to play with the current version of Croptop, you may go to croptop.eth and follow the steps there:

Jango introduced that there were a Fork button at the top right corner on any site that is running with Croptop template. By clicking it, people can try to start using Croptop to post and mint contents onchain in a decentralized way in the following steps:

1. Choose the chain that you want to deploy your project. Right now, it will be only available on Goerli testnet, but Ethereum, Polygon and other L2 deployment will be coming soon.

2. By click the "Make a new Juicebox", there will be a shortcut to quickly launch a Juicebox project, where people can pay you to record content onchain. You will need to set the name and symbol of the NFT collection, as well as the owner of this Juicebox project. And the Minimum price, Min total supply and Max total supply are the boundaries set for posting on your project. When people post specific content on your project, they can set their own parameters for prices and supply, but those parameters must fall within the boundaries set originally by you, the project owner.

   

3. Next step will be giving permisson to Croptop contract to post on your Juicebox project on your behalf, as an operator. After deploying the project in the step before, you can get its project ID and fill it in so as to give Croptop contract the permission to post NFTs on this project.

   

4. Last step will be optional, setting the addresses that can post to your Juicebox project via Croptop, and also the category of NFTs that will be allowed to be posted.

   

Right now, we were still using the Planet App to implement this Croptop fundraising initiative, but Jango said we would soon have a dedicated Croptop Mac App, which should be more straightforward and easy to use.

So if you're on a Mac and you want to make use of your ENS name to run a personal fundraising site, this is going to be a really good way to tell stories about what you're working on.

Defifa Updates by Jango and Kmac​

The Defifa team had been planning to host a tournament for the NBA finals, but their plans had been delayed quite a few times, mainly due to a lack of devs taking care of the front end stuff. Jango was very grateful for Aeolian to show up recently in Defifa and help cleaning stuff up, which made a tournament for NBA finals very likely now.

According to Kmac, the Defifa code base had got a total refresh and the create flow finalized with the help of Aeolian, giving the team the ability to actually go discovering some games in a light way. Their first goal was to set up a few self-hosted tournaments, making sure that everything is working fine before the create flow is officially open for public use.

Jango reiterated that the cool thing about Defifa is that, we don't really need an official oracle to define the games for us, but in stead we can make whatever rules and distributions that we want, allowing for some very cool and creative outcome.

Peel Update by Tim​

There were two major work projects underway in Peel team at this momentl: the project page revamp and the project settings improvement.

For project page revamp, Peel was starting on a new trajectory in terms of project page layout and what could be done, as well as introducing some new features such as a cart to support adding multiple NFTs or collections.

And for project settings, there was already a delegation page live on the project setting home page, which was an easier navigation page. Peel had split up some items in the settings and made them more user friendly and easier to navigate.

Next, they would be focusing on the revamp of Cycle configuration and payout components in the project settings page.

Project NFT Theme and Juicebox Cards by Nicholas​

Project NFT Theme​

Nicholas developed a TokenURI resolver contract a little while ago, which lets project owners to tweak the metadata of their projects, or totally replace the project's default metadata by setting their own custom resolver. This function had been officially integrated into the project settings on Juicebox.money website, and now available to use for all project owners.

Juicebox Cards​

Nicholas also wrote a Juicebox project cards contract, an ERC-1155 NFT contract that lets users mint an NFT replicating the metadata of any Juicebox project and keep it in their wallets, making it possible for them to stay updated with any changes of that specific project.

Nicholas had been absent from this Town Hall, so he asked Matthew to concisely introduce this product in the town hall, and help calling out people to go to the Beta site of Juicebox Cards and give it a try. Any feedback on that would be highly welcome.

Juicecast Updates by Matthew and Brileigh​

Matthew and Brileigh announced the release of a new Juicecast episode, featuring Livid from Planet, the App that recently Jango had been using to push his Croptop efforts.

In this episode, they talked about:

• How Livid had been building V2EX, one of the most active communities for Chinese devs;
• Planet, an open source tool helping people build decentralized ENS websites;
• Planetable Pinning, the project Livid created on Juicebox as the infrastructure of pinning services for decentralized websites;
• Croptop, an experimental Planet template that he helped developing in collaboration with Jango;
• Livid's personal passion about retro games and the game database built from Internet Archive.

Prop House and MCSA Updates by STVG​

STVG joined the Prop House Twitter space today, talking about the process of getting JuiceboxDAO's approval on the proposal to fund more Juicebox Open Rounds on Prop House. He was planning to host 3 more Open Rounds respectively on June, July and August this year.

And in the same cycle, he also submitted another proposal to sponsor T-shirts for water polo events, which had been approved by the DAO too. These sports events would be hosted by the non-profit Juicebox project MCSA created by STVG. He felt that the sponsorship on these events would help promoting Juicebox to people in real life, and also he expressed his gratitude to community members in supporting his proposal.

Defifa Demo by Kmac​

Defifa is a project that received grants from JuiceboxDAO to organize a game for the World Cup at the end of last year. The tournament game was highly successful. Following that, they also arranged a tournament for NFL playoffs in early 2023.

During this process, the team realized that the concept of creating tournaments should be accessible to the public, not just limited to their own use. This led them to explore the idea of developing a protocol and platform for creating money games and delivering an arcade-like experience.

Kmac took the lead in applying for grants with Seed Club and Base Ecosystem Fund. Additionally, they were preparing to submit a similar proposal to JuiceboxDAO in the near future.

During the Town Hall, Kmac presented the game flow of a Defifa tournament using an example game he created. This particular game focused on the top Spotify artists for June 2023. Participants could mint NFTs representing different artists to contribute to the prize pool. The distribution of the prize pool was designed as follows: 50% to the player who selected the most popular artist, 30% to the second most popular, and the remaining 20% divided among the third to fifth most popular artists.

The tournament followed a structured flow, consisting of the following phases:

1. Open ceremony: A minting phase where participants could mint NFTs of their choice. They had the flexibility to quit and receive a refund at any time during this phase.
2. Refund deadline: Participants had the opportunity to review the minting status of the game and assess their odds of winning. They could choose to leave the game before the refund deadline.
3. Kickoff: The game officially started, and the pot of funds became locked. Refunds were no longer permitted.
4. Final whistle: The game concluded, and all players came together to validate the final result on the blockchain. Based on the outcome, the funds in the treasury would be backing the winning NFTs. Those NFT holders had the option to either burn and reclaim the ETH or retain the NFTs and trade them in the market.

The Create Flow of Defifa​

During the town hall, Kmac provided a demonstration of the new create flow of Defifa, outlining the two steps involved in game creation.

1. The first step entails setting the name of the game, the duration for minting NFTs, the refund duration, and the start and end times of the game.

2. The second step allows users to customize the NFTs for the tournament, including setting their prices and allocating a reserved rate to a pre-defined beneficiary.

While the create flow was still a work in progress, Jango highlighted two noteworthy features in the contract that have not yet been supported in the UI:

• Distribution limit: This feature enables a percentage of the game's treasury to be allocated to a charity or another Juicebox project. Once the game starts, this allocation can be distributed, while the remaining treasury is utilized to run the game.
• Splits of reserved rate distribution: Users can designate a reserved rate beneficiary for each tier of the NFTs or each team of a competition. For example, a certain address could receive one out of every ten NFTs minted for one team, while a different address could receive the reserved rate for another team.

Jango expressed interest in exploring how the contracts work, how users perceive them, and the potential patterns that may emerge from their usage.

Furthermore, Jango emphasized that the artwork associated with the past two tournaments held significant value beyond the treasury backing the NFTs. These expressive playing cards could have a lasting presence in people's wallets, and it was exciting to consider how they could attach to emerging tournaments and amplify their significance.

Lastly, Jango mentioned that all the components on defifa.net should be compatible with juicebox.money, allowing users to play the game on either platform. As long as the platform recognizes the Defifa delegate and creates an adapter that can interpret the NFT view, cross-referenced games accessible from different front ends with standard interactivity and interconnectivity could become a reality.

Visibility Updates by Matthewbrooks​

Matthew and Brileigh were preparing to interview Livid, the developer of Planet APP and the Juicebox project called Planetable Pinning, for an upcoming episode of Juicecast. You can learn more about Planet at Planet and explore Planetable Pinning on Juicebox.

In addition to that, they will also be having discussions with the team at CryoDAO.

To provide more helpful resources, they had recently published several videos and blog posts with guides for various purposes. These valuable resources will be showcased in our upcoming Town Hall next week. Stay tuned for more updates and exciting demos!

L2 and Croptop Updates from Jango​

We had seen some great progress in the Bananapus staking component thanks to the efforts of both 0xBA5ED and Viraz. We would be excited to have an update in the upcoming week.

Regarding the L2 deployment of the Juicebox protocol, there had been a slight delay. The team had decided it would be more efficient to organize the repositories separately. This means the Juicebox V3 repository will remain as it is, while a new repository will be created specifically for multi-chain purposes. Once the new repository is up and running, we will proceed with integrating it into Defifa.

In recent weeks, Jango had been actively working on updates for the Croptop templates. Additionally, he had launched an experimental Croptop Publish Network project on Goerli test net, which serves as an unowned central hub for decentralized posting and minting of P2P distributed contents.

Meme Coin Fair Lunch with Blunt by Jango​

Blunt is a project that has been supported and funded by JuiceboxDAO to experiment some niche features of fundraising's first rounds. A Blunt round can be created with very tightly scoped preconfigured rules, such as a funding hard cap, funding target and a funding deadline, etc. For example, if a fundraising campaign doesn't reach its target within a deadline, a funding cycle #2 will be automatically configured to open the refunds for everyone participated in the Blunt round. If the fundrasing ends with success, then the ownership of this project will be automatically transferred to the pre-defined owner's wallet address, and the project will be operating onward, same as an ordinary Juicebox project.

Fair Lunch is a project that aims to help people crowdfund to create a meme coin in a fair and decentralized way. When funding is closed with success, the new meme coins and funded ETH will be used to start a liquidity pool on AMMs automatically at a proportion defined in advance, so as to ensure a fair launch of the meme coin, lunch served!

In the Town Hall, Jango demonstrated how to use Blunt to create a Fair Lunch funding round. When this fundraising ends successfully, then the ownership of this project will be transferred to, intead of a pre-defined owner. but the Fair Lunch contract, which will in turn schedule a new funding cycle immediately that allows owner's token minting and distribution of all ETH in the project's treasury to Fair Lunch contract. Then the meme coins will be paired with ETH at a certain ratio and added to a liquidity pool on AMMs.

From a pattern's perspective, we have this hook onERC721Received, which is the standard hook for ERC721s, and it will be used to detect when the project ownership on Blunt is passed to the Fair Lunch contract and trigger the actions thereafter.

There are two parameters to make a new fair lunch and describe a particular Fair Lunch contract, the Multipler and the Splits.

• The Multiplier sets the initial price that the tokens will be offered in the LP. A multiplier of 1 basically means mint exactly at the token/ETH ratio specified in the Blunt round to start the LP. A higher multiplier will make the token price better in the initiation of that LP.
• Juicebox Splits can be set so that as soon as the Blunt ownership is transferred and so are the raised the funds, some of the funds can be split off and routed to a list of beneficiary addresses, while the leftover funds will be used to kickstart the LP.

Croptop Contract on Planet by Jango​

Planet App is a decentralized solution for users to run their websites on ENS domains, they can locally host the contents which will be pinned to IPFS and referenced to an ENS through IPNS address. The contents are distributed through a peer-to-peer network without relying on servers or other centralized services. Once distributed and collected by other users, the contents will no longer be removable by their original publishers.

Croptop contract is a Planet template developed by Jango, to help make this a fundraising tool and let people post the contents onto a Juicebox treasury and make them available for minting as NFTs.

To try the Planet app with the Croptop template, here are the steps to be followed (only available in Mac right now):

1. Download Planet Mac app from here;

2. Create your own Planet by clicking "Create Planet";

   

3. Set Croptop as the template of the new Planet;

   

4. Right click the created Planet and copy IPNS;

   

5. Go to ENS app to edit records for your ENS name, paste the IPNS into the field of Content Hash and add a prefix of "ipns://" in front of it.

   

6. After the planet is propagated through the peer-to-peer network, you can visit your Planet with your ENS name by going a corresponding address like jango.eth.limo in the browser.

7. Go to the template setting and your can set the Juicebox project ID that images on your Planet will be posted and minted from.

   

8. Juicebox.money front end will soon support the Juicebox project owners to set the Croptop contract as an operator in the project's settings, to post NFTs on the project page on their behalf.

If you are interested in how to collect a image from an ENS website and post it onto a Juicebox project, please jump here to check what Jango and Livid introduced in our last Town Hall.

Though Planet allows people to host the contents distributed peer-to-peer, propagation in the peer-to-peer system might not very fast at this stage. Planet has a Juicebox project called Plantable Pinning which offers a central pinning service to make the propagation a lot faster, people can choose to mint NFTs on this project to have access to this pinning service.

Anyone who is interested to know more about Croptop is welcome to join the Croptop Discord.

Peel Updates by Tjl​

Recent work by Peel:

• Peri had been doing a lot of work under the hood on Apollo and subgraph and making a better developer experience and performance.

• New NFT contracts was live on Goerli testnet, they should be ready to be in production by next week, pending some collaboration with the contract crew.

• There had been a relatively big bug with Edit payouts section which turned out not being structured the right way, it had been fixed by JohnnyD.

• We now have a new ConnectKit wallet in our Connect section, to provide a much smoother UX, especially for people who don't have wallets. It looks really nice on mobile.

  

On the Town Hall, Tjl also walked us through Canny, which is essentially a tool that allows people to add a feature request idea or some feedback, and also allows people to vote on it. Peel team had been using this in front end work for a while. Nicholas suggested that we should expand this tool outwards and allow anybody in the DAO to post in Canny our updates, ideas or feeback. So, now anybody can come here to post their ideas or feedback, vote on them or add some comments.

It will probably be a very good way to get a temperature check on things that community members care about or are interested in.