71 posts tagged with "town-hall"

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.

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.